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. -- <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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}} -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
