We're seeing a fair number of blank messages, probably caused by buggy
viruses or probes from infected machines. I've been having a look at this
in a bit more detail (from the point of view of rejecting these messages)
and it showed up some anomalies in the way Exim handles the message size.
(1) The S= field in the logs indicates the message size after Exim has
altered the headers, in particular the addition of a Received: line but
also submission mode changes, addition from ACL warn verbs, and other
rewrites. This can be a little confusing.
(2) However $message_size only tracks the data received from the network -
it isn't used to produce the log line. Thus it can be used in the
post-DATA ACL to reject blank messages, which is useful.
(3) When Exim delivers a message, it re-computes $message_size from the
stored headers (which include receipt-time changes). This is reasonably
comprehensible. Later delivery-time changes to the message size are as
documented.
I suggest the following changes:
(1) Exim should log the message size as received, in addition to or
instead of its size after alterations by Exim. I don't mind whether
this replaces or augments the existing S= field. Any opinions?
There should also be an improvement to the log documentation in section
48.6.
(2) The documentation for $message_size can be improved slightly. I
suggest:
> When a message is being processed this variable contains its size in
> bytes. Exactly what is included in this count depends on the stage of
> processing:
>
> (1) In a MAIL, RCPT, or pre-DATA ACL, $message_size contains the size
> supplied on the MAIL command, or -1 if no size was given. The value may
> not, of course, be truthful.
>
> (2) In a MIME or post-DATA ACL, it contains the size of the message as
> received from the network, excluding any alterations made by Exim.
>
> (3) At routing and delivery time, it includes receipt-time changes to
> the headers, such as the addition of the Received: line, submission mode
> fix-ups, additions from ACL warn verbs, and other rewrites. It does not
> include those (such as Envelope-to:) that are added to individual
> deliveries as they are written.
> (4) However, there is one special delivery-time case: during the
> expansion of the maildir_tag option in the appendfile transport while
> doing a delivery in maildir format, the value of $message_size is the
> precise size of the file that has been written.
>
> See also $message_body_size, $body_linecount, and $body_zerocount.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
