ietf-asrg
[Top] [All Lists]

Re: [Asrg] Microsoft takes over British Telecom

2011-10-23 19:23:02
On 23/10/2011 22:43, Steve Atkins wrote:
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.
I thought most people did return-path rewriting for this case. If you don't do that, then you get undesirable behaviour anyway - eg if the AOL mailbox is full, you get a bounce message from AOL, even though you didn't send any messages to AOL at all.

Mailing lists is another similar cause of SPF failures..
Similarly, I thought return-path rewriting was standard for mailing lists. Especially ones which do VERP, but usually even in ones which don't - eg the return path on the message I received from you was "<asrg-bounces(_at_)irtf(_dot_)org>", not your blighty.com address. Therefore, it correctly passed an SPF test for irtf.org.

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.
This is the problem of people who should know better not understanding what's going on. If the company had a policy that all mail from their domain had to go through certain servers, and employees were sending mail through other servers, then they deserved to get kicked off mailing lists... Just as they would deserve punishment for watching porn over the work Internet connection, etc. If they had a policy that mail had to go through certain servers, and configured SPF for different servers, then they shouldn't be managing mail systems.

If 'SPF' and/or DKIM was standardised and rigourously enforced, then return-path rewriting would be de rigeuer as would people learning how to configure the mechanisms properly.

The problem is that for years email was virtually unregulated (open relays were commonplace 15 years ago) which is why it is now so widely abused. The only chance of cutting back abuse is to tighten things up. Saying that attempts to tighten it up are "fatally flawed" just because people can't be bothered to do things properly is dooming the whole system to failure.

Extra authentication and authorisation is necessary in email. However these are done (SPF, DKIM, a 'web of trust', trusted authority, or whatever) will need more rigourous configuration and management than there has been in the past. If we can't accept a requirement for more rigourous configuration and management, we may as well all give up now.

I would say that giving a 5yz error in response to an SPF failure would be a good thing to do (silently discarding would not be). Accepting an SPF failed message just means that any bad configuration/behaviour goes "unpunished" and defeats the whole objective of having the SPF protection in the first place. In most cases, the sender should prefer to know that there's a problem with their SPF/DKIM configuration (so they can fix it), rather than it to be silently ignored all the time. IME, people set up SPF because they don't want their email addresses to be spoofed, not just as a fun way to spend half an hour.

(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).

Is that just because it's poorly configured in many places? If so, then rejecting any failed messages will surely, over time, increase the effectiveness as people fix their configurations. Accepting them anyway will just keep the bad configurations in place. (i.e. 'Tough love')

Big mail providers are happy rejecting mail for any and all spurious reasons, why can't others be willing to reject mail for badly configured senders?


_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg