Re: Microsoft takes over British Telecom

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