Re: [Exim] Should vacation messages go to reply_address or r…

Pàgina inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
A: Kai Henningsen
CC: exim-users
Assumpte: Re: [Exim] Should vacation messages go to reply_address or return_path
On 22 Aug 2000, Kai Henningsen wrote:

> > > Actually, it does, sort-of. The sender address appears in Return-Path:.
> >
> > Yes, it "may" appear there.....
>
> RFC 821 requires that this happens. It's a MUST.


Let's be very formal here. I believe that "Return-Path:" is a reference
to a header line. That is an RFC 822 object, not an RFC 821 object. RFC
821 requires <> in what it calls the "reverse path", which is the
envelope sender, transmitted by the MAIL command. It then says

            When the receiver-SMTP makes the "final delivery" of a
            message it inserts at the beginning of the mail data a
            return path line.  The return path line preserves the
            information in the <reverse-path> from the MAIL 
            command.


But it doesn't define exactly what it means by a "return path line", and
RFC 821 does not, of course, define the format of header lines. (And
that paragraph is not very prominent; it hardly shouts MUST at you.)

> Return-Path: is not a "legal RFC-822 conforming header"? Mr. Crocker would
> be very astonished to hear that.


If we are going to be picky, the definitions in RFC 822 seem to me to forbid

Return-Path: <>

as a legal RFC 822 header line. In the syntax definitions we have

     return      =  "Return-path" ":" route-addr ; return address   


So Return-path: has to be followed by a route-addr, which is defined as

     route-addr  =  "<" [route] addr-spec ">" 


So that's an optional route, followed by an addr-spec, inside <>. Now,
let's look at addr-spec:

     addr-spec   =  local-part "@" domain        ; global address


Nothing there is optional. Now, in RFC1123 they realized they had
forgotten something in RFC 821 and we find

         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.


We also find

         If there is a delivery failure after acceptance of a message,
         the receiver-SMTP MUST formulate and mail a notification
         message.  This notification MUST be sent using a null ("<>")
         reverse path in the envelope; see Section 3.6 of RFC-821.  The
         recipient of this notification SHOULD be the address from the
         envelope return path (or the Return-Path: line).  


But as far as I can see, there is nothing in there that changes RFC 822
to allow a route-addr to be just <>.

HOWEVER: in the draft for the revision of RFC 822, this flaw has been
fixed. It says:

         The "Return-Path:" header field contains a pair of angle brackets 
         that enclose an optional addr-spec.
                         ^^^^^^^^


Phew! So that's all right then. What everybody has been doing all along
is finally going to be blessed. However, no other header line is allowed
to contain <>.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.