Re: [exim] Refusing MAIL FROM:<> ...

Top Page
Delete this message
Reply to this message
Author: Ian Eiloart
Date:  
To: Dave Evans, exim-users
Subject: Re: [exim] Refusing MAIL FROM:<> ...


--On 7 August 2006 09:33:29 +0100 Dave Evans <davide-20060629@???>
wrote:

> On Mon, Aug 07, 2006 at 10:18:10AM +0200, Daniel Tiefnig wrote:
>> if a host does not accept the "MAIL FROM:<>" command. ... I'd
>> be interested in which RFC requirements exactly were "disregarded". I
>> couldn't find any references in RFC 2821 at least.
>
> RFC1123:
>
>       5.2.9  Command Syntax: RFC-821 Section 4.1.2

>
>          The syntax shown in RFC-821 for the MAIL FROM: command omits
>          the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
>          15).  An empty reverse path MUST be supported.


And, while 821 omits it, 2821 doesn't:


4.1.1.2 MAIL (MAIL)

This command is used to initiate a mail transaction in which the mail
data is delivered to an SMTP server which may, in turn, deliver it to
one or more mailboxes or pass it on to another system (possibly using
SMTP). The argument field contains a ....

The reverse-path consists of the sender mailbox. .....In some types of
reporting messages for which a reply is likely to cause a mail loop
(for example, mail delivery and nondelivery notifications), the
reverse-path may be null (see section 3.7).

This command clears the reverse-path buffer, the forward-path buffer,
and the mail data buffer; and inserts the reverse-path information
from this command into the reverse-path buffer.

If service extensions were negotiated, the MAIL command may also
carry parameters associated with a particular service extension.

Syntax:

      "MAIL FROM:" ("<>" / Reverse-Path)
                       [SP Mail-parameters] CRLF
...
4.5.5   Messages with a null reverse-path
....
    Implementors of automated email processors should be careful to make
   sure that the various kinds of messages with null reverse-path are
   handled correctly, in particular such systems SHOULD NOT reply to
   messages with null reverse-path.


I think it's easy to make the case that rejecting all null-sender email in
order to avoid some spam bounces is not being "careful to make sure that
the various kinds of messages with null reverse-path are handled correctly"
--
Ian Eiloart
IT Services, University of Sussex