Re: Handling of -all

----- Original Message ----- 
From: "David Woodhouse" <dwmw2(_at_)infradead(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, February 13, 2005 6:07 PM
Subject: Re: [spf-discuss] Handling of -all


> On Sun, 2005-02-13 at 10:25 -0500, Nico Kadel-Garcia wrote:
> > There's a booby trap here. "Should be delivered" is not the same thing as
> > "not rejected by SPF". SPF is not an *approval* method, it's a *rejection*
> > method. Any other filtering the recipients are doing can certainly still 
> > be
> > done.
> A cursory consideration of how things actually work will lead to the
> conclusion that in fact the opposite is true. SPF is _only_ safe to use
> in whitelisting; using it for rejection will reject valid mail, for
> normal definitions of 'valid'.
Then the "normal definition" is broken. SPF touches nothing that a domain 
owner has not decided to exert a policy over, so that mail's all just fine. 
If a domain owner decides to exert a policy, SPF follows it according to the 
wishes of the domain owner.
The one possible exception to this is standard "forwarding", or "mail 
reflectors". Those are badly broken, since the lack of authentication of the 
message being passed along is such that there is simply no way to tell an 
entirely forged message from an acceptable normal "forwarded" message.
Therefore the practice of standard "mail reflectors" or "forwarding" needs 
to go the way of the Dodo bird..
> > Every time we get into one of these "oh, gee, SPF breaks forwarding so it
> > should be modified to just pass stuff along" discussions we're wasting tme
> > and resources. The "MAIL FROM" line generated by email reflectors is 
> > broken.
> > Period. The technology needs to go away, or we will continue to face a
> > serious burden of decoding all the spam sent via forged email addresses 
> > and
> > bounce addresses, exactly thesituation SPF is supposed to address.
> An opinion not shared by many. You might as well declare that using your
> address in the 'From:' header when forwarding mail is also invalid, and
> expect the world to 'upgrade' to match that expectation too. That just
> isn't how the world works, though.
True, it's not widespread yet. But it's getting therre. The problem of mail 
forwarding and the fact that the mail forwarder does not get the bounce 
message and is unaware of the problem, and the problem of forgery going 
through forwarders or of forwarders being used to create an interesting DDOS 
attack are not going away simply because some users find it convenient and 
remember how to use it from 20 years ago.
We as SMTP maintainers need to encourage more flexible and powerful tools to 
manage mail forwarding *correctly*, bouncing back through the forwarding 
host rather than to the alleged original sender's address which is usually 
unverifiable at the recipient's end.
> > SRS and SES do a better job of handling such forwarding, and making the
> > machine and postmaster allowing the forwarding responsible for the bounce
> > message, as they should be because they're the one sending it.
> SES isn't strictly relevant to SPF except for the fact that it can work
> as a replacement for SPF, but without the flawed assumptions which make
> SPF so broken -- it works in the real world today even when forwarding
> is happening, so it _can_ be used for rejection without losing valid
> forwarded mail.
??? SES and SRS deal with a very specific set of SPF issues, passing along 
mail forwarding in a way that allows SPF to correctly exert the policy of 
the original message sender, or of the forwarding host, to email claiming to 
be from their domains. Their function is complementary to SPF for those 
hosts that feel the need to still permit forwarding.