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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] Microsoft takes over British Telecom, (continued)
- Re: [Asrg] Microsoft takes over British Telecom, t.petch
- Re: [Asrg] Microsoft takes over British Telecom, Alessandro Vesely
- Re: [Asrg] Microsoft takes over British Telecom, Steve Atkins
- Re: [Asrg] Microsoft takes over British Telecom, Paul Smith
- Re: [Asrg] Microsoft takes over British Telecom, Steve Atkins
- Re: [Asrg] Microsoft takes over British Telecom,
Paul Smith <=
- Re: [Asrg] Microsoft takes over British Telecom, Steve Atkins
- Re: [Asrg] Microsoft takes over British Telecom, Alessandro Vesely
- Re: [Asrg] Microsoft takes over British Telecom, Douglas Otis
- Re: [Asrg] Microsoft takes over British Telecom, Alessandro Vesely
- Re: [Asrg] Microsoft takes over British Telecom, Douglas Otis
- Re: [Asrg] Microsoft takes over British Telecom, Paul Smith
- Re: [Asrg] Microsoft takes over British Telecom, Paul Smith
- [Asrg] Authorized forwarding, was Microsoft takes over..., Alessandro Vesely
- Re: [Asrg] Microsoft takes over British Telecom, Douglas Otis
- [Asrg] MTA Authorization/Authentication, John Leslie
|
|
|