"Frank Ellermann replied to Dave Crocker"
<extract>
one is supposed to learn from one's mistakes.
The mistake was RfC 1123 5.3.6 (a) after the elimination of
source routes in the reverse path: "the rest of the envelope
and the message body are left unchanged". Of course they
couldn't know how MAil FROM would be abused 15 years later.
</extract>
Yes, exactly. I came across that same phrase in RFC2821 the other night whilst
researching a response to Dave. I've not researched the life-cycle of this
phrase in earlier SMTP RFC/STD versions, but just taking the RFC2821 wording
it's actually rather bad news for SPF...
<quote>
.10 Mailing Lists and Aliases
An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery.
[Details for List model follow]
3.10.1 Alias
To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
</quote>
The point of this mail is to suggest that maybe the SPF community's attempts to
get an RFC right now are premature.
The problem being that the SPF 'solution' includes some implicit changes to SMTP
to make the solution viable, so the single would-be-RFC is trying to re-define
aspects of SMTP practice at the same time as it is proposing a solution.
Suggestion: We should first seek an RFC in which the weaknesses in / problems
with SMTP are fixed, then propose SPF as a solution which fits that amended
SMTP. If the Internet community does not first agree the changes, then it's
logically pointless proceding with the cure to the wrong disease.
There are three needed changes to SMTP which I can think of:
1) Fix the forwarding problem. Change RFC2821 sect 3.10.1 (cited above) to
read:
To expand an alias, the recipient mailer replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn. The return address in the envelope ("MAIL FROM:") MUST be
changed to be the address of a person or other entity who administers the
recipient mailer. The rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
2) Make explicit the role of the MAIL FROM entity as the entity responsible for
the submission of the envelope + contents, covering the 'unauthorised use of an
address is forgery' argument which SPF asserts.
3) DSNs (bounces) to addresses which have been proven to be forged MUST NOT be
sent, and the message with the proven-forged 'MAIL FROM' SHOULD be silently
discarded. In other words, this absolves the handlers of proven forgeries of
the SMTP 'deliver or bounce' contact commitment.
It wouls surely be easier to get SPF accepted if these three changes to SMTP
were first agreed.
Conversely, if any one of these three points were to be not acceptable to the
Internet community at large, then there would be no point in further promoting
SPF.
Chris Haynes