[Asrg] SPF apologies

[Bill Cole]

Gordon Peterson wrote, On 1/27/09 6:34 PM:
>  > The reason that SPF is here to stay is that it is good enough 
> authentication for most of the mail that most receivers and senders care 
> the most about.
> 
> With all due respect, that's kind of like saying that you've developed 
> an airplane which will get the passengers there for 95 (or even 99) 
> flights out of a hundred...!

After all, we all know that a failed email delivery is as significant as a 
failed airline delivery...

I think a closer analogy is to airline scheduling. Flights get cancelled and 
people get bumped off of overbooked flights all the time. Probably more 
frequently as a percentage of passengers than the percentage of mail that is 
rejected (rightly or wrongly) solely as a result of SPF.


> The fact that SPF screws up on so many ENTIRELY ANTICIPATED AND 
> LEGIITIMATE cases, IMHO, makes it not viable, even though it works for 
> SOME mails, MOST of the time.

Objective reality disagrees with you. Use of SPF in non-harmful ways is 
fairly widespread, and there's not much indication of it going away. The 
willingness of MS to misuse SPF and SenderID to actively degrade the value 
of Hotmail addresses has spurred publication of SPF addresses and made the 
safe use of SPF more beneficial.

SPF is not viable as a direct anti-spam tool because it cannot be trusted 
generally to identify forged messages, and will yield derogatory results for 
mail that generally would be considered legitimate. However, it has 
demonstrated viability as a tool to exempt (quasi-)authenticated mail from 
known-good senders from error-prone filtering. SPF derogatory results are 
marginally useful (e.g. in heuristic scoring systems like SA.) The limits on 
is safe use have not been enough to kill it altogether and probably never 
will be. I am absolutely in agreement that it was a strategic error to push 
SPF to a formal RFC spec, but that is hindsight. SPF is not going away.

> Personally, I *strongly* believe that the best approach requires a mix 
> of techniques, 

Right, and SPF has carved out a niche in a layered system. It's a lot weaker 
than some people hoped it would be but it serves a purpose. We'd all be 
better off if people who should have known better had not pressed for 
publication of RFC's 4406-4408, but that's done.

> including (again) a combination of:
> 
>    1) fine-grained content criteria based upon the sender/recipient duple;
> 
>    2) a suitably restrictive default policy to apply to senders 
> previously unknown (or untrusted) to the indicated intended recipient;

Which is where SPF has entrenched itself. It is the easiest standardized 
mechanism for affirmative authentication of senders. It's not a general tool 
for identifying all forgeries, but it is useful and it is in widespread use. 
Ranting against its use is a few years late and not constructive, 
particularly when the critique is aimed at flaws that are avoided by the 
narrow uses that are actually common.