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
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'.
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.
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