Chris Haynes wrote:
just taking the RFC2821 wording it's actually rather bad news
for SPF...
It's _old_ news that alias-expansion keeping the MAIL FROM does
not work for a "251 user not local" case, if the next MX tries
to match the sender policy for the unmodified MAIL FROM against
the IP of the forwarder.
As far as that's bad news it's worse for Sender-ID (see below).
I'm happy that I found a text explicitly saying "envelope RCPT
TO and MAIL FROM may be derived from the mail header", so that
wasn't only my imagination. I must have read RfC 1123 about 10
years ago, it was definitely not 733, and 821/822 don't mention
this. Maybe it also explains X-Authentication-Warning.
The point of this mail is to suggest that maybe the SPF
community's attempts to get an RFC right now are premature.
Google's funny "translator" has a comment for this idea:
http://purl.net/net/de2en/www.heise.de/newsticker/meldung/print/57001
the SPF 'solution' includes some implicit changes to SMTP to
make the solution viable
Yes, the known forwarder problem, and that's "only" a change in
relation to 1123 / 2821, it revives the original RfC 821 chain
of responsible senders. Also not "premature", in essence it's
the now already old RMX idea.
The same idea using 2822 headers is Sender-ID, patented or not.
And that requires more changes. And it won't get rid of the
backscatter to innocent bystanders.
the single would-be-RFC is trying to re-defineaspects of SMTP
practice at the same time as it is proposing a solution.
It's voluntary for the senders. If Dave loves his "errors-to"
feature all he has to do is nothing. Just don't publish a SPF
sender policy for domains used in MAIL FROM actually sent from
arbitrary IPs. Publishing "v=spf1 +all" is also possible but a
waste of time.
We should first seek an RFC in which the weaknesses in /
problems with SMTP are fixed, then propose SPF as a solution
That's obscure, what would it do ? "Note that MAIL FROM must
indicate the responsible sender address w.r.t. the domain of
the MSA. Also note that you must not change the RCPT TO to an
address with an MX unrelated to the domain of the forwarding
MTA, unless you also change the MAIL FROM to a responsible
sender address w.r.t. the domain of the forwarding MTA".
That's it in a nutshell, add "updates 1123, 2821". Mentioning
821 is unnecessary, 821 already covers this "new" behaviour.
If the Internet community does not first agree the changes,
then it's logically pointless proceding with the cure to the
wrong disease.
For another opinion see
<http://article.gmane.org/gmane.ietf.rfc822:11412>
And the disease is clear if you ever got a bounce for a mail
not sent by you. You could remove auto-responders, bounces,
etc. from the equation, but what you'd then have is not SMTP.
If the Internet community at large wants the freedom to use an
"errors-to" everywhere. and to let forwarders do whatever they
like, then SPF won't fly. no matter what the IETF status of the
SPF standard is at this moment.
[2821bis]
| 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.
Not for local aliases, but otherwise ACK. You only need it for
the "251 user not local" case.
2) Make explicit the role of the MAIL FROM entity
More for Dave, less for me. I already believe that that's the
case, like 750,000 domain owners if the MS numbers are correct.
3) DSNs (bounces) to addresses which have been proven to be
forged MUST NOT be sent
That's IMHO not correct. In this case the message should be
rejected. And the MTA trying to forward it should create a
proper bounce message. Spamming zombies SHOULD NOT create a
bounce message, but saying so is pointless.
the message with the proven-forged 'MAIL FROM' SHOULD be
silently discarded.
If we're happy with silently discarding mails then there's no
reason to do anything at all, let SMTP just die. Maybe I find
a Jabber client for my OS/2 before the last smtpd is killed.
Bye, Frank