On Thu March 31 2005 06:11, Arnt Gulbrandsen wrote:
2) isn't "bounces-to" a fairly good description of how most running code
treats the MAIL FROM address?
It's not only a description of how (RFC-compliant) running code
operates, it's specified in the relevant RFCs:
RFC 2821, section 3.3:
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
This command tells the SMTP-receiver that a new mail transaction is
starting and to reset all its state tables and buffers, including any
recipients or mail data. The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see section 4.2 for a
discussion of error reporting).
N.B. "used to report errors"
RFC 821, section 3.3:
MAIL <SP> FROM:<reverse-path> <CRLF>
This command tells the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers, including any recipients or mail data. It gives the
reverse-path which can be used to report errors.
N.B. the same wording "used to report errors"
RFC 788, section 3.1:
MAIL <SP> FROM:<reverse-path> <CRLF>
This command tells the the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers including any recipients or mail data. It gives the
reverse-path which can be used to report errors.
N.B. same wording. RFC 788 was the original SMTP specification, dated
November 1981. I.e., from its inception nearly a quarter century ago,
the semantics of SMTP MAIL FROM have been, and remain, the path by
which delivery errors are reported (with a minor evolutionary note that
routing is now discouraged as a normal feature, being reserved for
working around temporary DNS failures).
SMTP was preceded by MTP (the not-so-simple Mail Transfer Protocol) as
defined in RFCs 780 and 772. The same concept existed in MTP:
RFC 780, section 2:
The arguments to the MAIL command are a FROM path and a TO path. The
TO path is a source route while the FROM path is a return route
(which may be used to return a message to the sender when an error
occurs with a relayed message).
RFC 772 was a bit different:
MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF>
<sender> is a mailbox and <path> is a source routing list of
hosts and destination mailbox. If accepted, it returns a 354
reply and considers all succeeding lines to be the message
text.
RFC 722 was issued September 1980 and obsoleted by 780 in May 1981.
Frank, you seem to be living in MTP-land, stuck in late 1980. We in
the 21st century are talking about SMTP as it has existed since 1981.
I realize that you're trying to make a point about joe jobs, but we're
discussing the mail architecture as designed and implemented:
1. we need to accurately describe SMTP, not an early, long-obsolete,
short-lived version of MTP (except possibly as a[n] historic note).
2. it is a fact that the mail system has been abused, however we should
not let such abuse (dis)color the description of the mail system
architecture [*]
3. suggestions for something different from SMTP as it was in the
beginning and is now should rightly take place on the mail-ng
mailing list or in some IRTF venue, or at minimum in a separate
discussion from the description of the long-standing mail
architecture.
* You are welcome to author a draft describing which aspects of the
mail architecture are abused by spammers, but it is first desirable to
have a standardized description of that architecture, and that is the
topic of the current discussion.