On Oct 23, 2011, at 2:16 PM, Paul Smith wrote:
On 23/10/2011 17:09, Steve Atkins wrote:
On Oct 23, 2011, at 7:39 AM, Alessandro Vesely wrote:
On 21/Oct/11 19:07, Steve Atkins wrote:
The bigger issue is that you shouldn't care about SPF failing. An SPF pass
provides somewhat useful data, an SPF fail means absolutely nothing.
Wasn't it supposed to mean "reject"? IIRC, that was the difference
between setting -all (as irtf.org does) rather than ~all or ?all.
That's what it's proponents used to claim, yes. But it's unfixably broken for
that purpose. The only reason you don't see serious mail problems for
anyone unwise enough to use -all is that almost nobody pays much attention
to SPF for rejecting email.
How is it 'unfixably' broken? Just interested.
it seems to me that the only reason it's 'unfixably broken' is that people
are using it without really understanding what it's doing. If all MTAs
rejected all mail that failed SPF checks, then they'd soon get the problems
fixed. Remote users having to relay via a specified submission server is a
trivial problem to fix (AFAICS), and incorrectly specified SPF records (as in
the BT/MS case) deserve to cause messages to be blocked (IMHO)
(SPF is certainly not that useful as an 'anti-spam' mechanism, but it seems
to have the potential to work reasonably well as an anti-spoofing mechanism,
which makes it considerably harder for many spammers)
Mail forwarding is one common cause of failure. If you're sending mail to
someone at @ieee.org and they forward it on to their @aol.com account, and you
and AOL decide between you to enforce SPF -all then that mail will be
undeliverable - and there's no way either you or AOL can predict that.
Mailing lists is another similar cause of SPF failures..
A third, which is a lot more common and complex to resolve than you'd expect,
is organizations simply not knowing or not controlling where their mail is sent
from. There've been cases both for SPF and ADSP ("SPF for DKIM") where one
group within a company put out a restrictive policy based on their beliefs of
where mail was sent from, and it all fell to pieces when employees got kicked
off mailing lists when mail appearing to come from them was delivered from the
mailing list manager and rejected due to auth failure, or where internal
monitoring email sent from servers (cron, even) was silently discarded.
Combine that with SPF being pretty much ineffective for "anti-phishing" (which
is what people actually mean when they say "anti-spoofing" or "brand
protection") and you end up with it being not very useful as a negative
assertion.
It's interesting to compare SPF with DKIM and ADSP. In many ways DKIM+ADSP is
the domain-based version of SPF. DKIM is the positive assertion half ("If this
mail is DKIM signed / passes SPF then you know that you can trust that the
sender is who they claim to be") while ADSP is the negative assertion half ("If
this mail is not DKIM signed or fails SPF then you should reject / discard the
mail").
The positive assertion is always valuable: it's difficult for "bad" mail -
where by "bad" I mean mail that appears to have been sent someone you trust,
but it isn't really from them - to "pass" SPF or DKIM. The negative assertion
much less so as it's pretty common for "good" mail to fail SPF or ADSP.
(I did some back of the envelope testing of ADSP as an anti-phishing /
anti=spoofing measure, and based on my inbox it was worse than flipping a coin
for each email, based on both false positives and false negatives).
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg