Dick St.Peters wrote:
Do you seriously believe that RfC 1123 got 5.3.6(a) right ?
Absolutely! There are thousands upon thousands of people
getting their mail by 5.3.6(a) forwarding.
I certainly hope that they get their mail, I've no issues with
"replace old RCPT TO by new and go" ;-) Keeping the MAIL FROM
as is is the problem. Not for the folks forwarding their mail,
but for the general mail architecture, because final receivers
are essentially forced to accept arbitrary MAIL FROMs if they
wish to accept the forwarded "5.3.6(a) keep as is" MAIL FROMs.
The real question to ask is whether now, some 17 years after
1123 was adopted, it's time for an update. Arguably yes.
That's what SPF tries in an admittedky sneaky way: Changing
the mail architecture by decree is a non-starter, that leaves
only this voluntary opt-in approach with some 551-effects for
senders with an SPF FAIL policy.
at the time 1123 was published, it was unquestionably right
IBTD very strongly. It was right to remove source routes. It
was right to specify lists (5.3.6(b)) and gateways as they did.
But it backfired.extremely, years later, that they didn't get
it right for 5.3.6(a), indirectly causing the old MAIL FROM to
degenerate into some kind of "bounces to" for this case.
it remains in force as a standard until formally updated.
The formal approach doesn't catch it. Formally it would be
okay to use "accept and bounce" strategies: That's how it used
to be, it was a good strategy: Always try to deliver / forward
first, the mail must flow, and if it doesn't work out you can
report the error, with regrets.
Anybody trying this approach literally today will be in serious
trouble, "formally" correct or not, it's net abuse in a system
where the majority of Return-Paths are forged.
Not completely unrelated, in an uncoordinated effort Stuart and
I have just rewritten major parts of three Wikipedia articles:
http://en.wikipedia.org/wiki/Sender_Policy_Framework
http://en.wikipedia.org/wiki/Sender_ID
http://en.wikipedia.org/wiki/E-mail_authentication
The latter are only my fault if they're incorrect ;-) I hope
you (all here) like it, otherwise please fix it if it's wrong.
It also covers what we just discussed, but I tried to write it
a bit more from a wannabe-NPOV, no curses about 1123 5.3.6(a)
Bye, Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com