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.
