Doesn't all this discussion prove that the interpretation of a protocol can
vary?
Therefore any attempts to use a "feature" that is disputed will probably end
up breaking some software
Regards
Chris
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of Eric
S. Raymond
Sent: Monday, December 01, 2003 2:42 PM
To: Yakov Shafranovich
Cc: ASRG; Dave Crocker
Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about
CallerID Verification)
Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>:
Whether the RFCs require a valid return address, or not, in
spirit or in
letter of the law, is something Dave Crocker and Eric Raymond, and
others, who worked on the original 821 and 2821 RFCs can tell us. But
the fact today is that no one is expected to provide a valid address,
and any system relying on this, will fail in some cases unless the
existing RFCs are changed.
The spirit of the law, at least at the time I was involved with
RFC2822, was certainly that the return address was required to be
valid. As for the letter...
Section 3.6.7 of RFC2822 says:
The trace fields are a group of header fields consisting of an
optional "Return-Path:" field, and one or more "Received:" fields.
The "Return-Path:" header field contains a pair of angle brackets
that enclose an optional addr-spec. [...]
The addr-spec is optional because it maty be omitted, as in daemon
bounces. RFC2822 continues:
A full discussion of the Internet mail use of trace fields is
contained in [RFC2821]. For the purposes of this standard, the trace
fields are strictly informational, and any formal interpretation of
them is outside of the scope of this document.
Thus, RFC2822 does not mandate that the address be valid. We are
referred to RFC 2821. Section 4.1.1.4 reads:
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system.
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
the message sender. When mailing lists are involved, this
arrangement is common and useful as a means of directing errors to
the list maintainer rather than the message originator.
I read this to mean that the Return-Path must, if present, be a
valid mailbox for a responsible person (note the MUST).
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg