Subject: [Asrg] SPF apologies

From: Gordon Peterson <[email-masked]>
Date: Tue, 27 Jan 2009 17:34:41 -0600

> 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...!

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.

Personally, I *strongly* believe that the best approach requires a mix 
of techniques, 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;

    3) following THOSE techniques, which by default will block virtually 
all worms/viruses and other evasions, then use SpamAssassin or similar 
to analyze the actual content of the message (which, after 
scripting/HTML/attachments/ActiveX and so forth are out of the equation) 
can probably do a pretty good job.

    4) additional optional content tests for familiar senders (familiar 
mastheads, sig files, or other familiar-looking authenticating content 
that recipient expects in mail from that sender).

If implemented intelligently, I believe this will provide the MOST 
safety, the FEWEST false positives, and give the recipient (the one who 
counts the most) the best feeling of control over their Inbox.

-- 

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Wed, 28 Jan 2009 12:00:36 +1200 (FJT)

It seems this thread is going into flamewar.

I think better leave it to "running code" and see which one become a standard because people just use it.

Also, what has been found by experience, is that the IETF is not very goo at creating new protocols but it is very good at taking a protocol and make it rock solid.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 28 Jan 2009 10:50:48 +0000

--On 27 January 2009 17:34:41 -0600 Gordon Peterson <[email-masked]> 
wrote:

> 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...!
>
> Personally, I *strongly* believe that the best approach requires a mix of
> techniques, including (again) a combination of:
>
> all worms/viruses and other evasions, then use SpamAssassin or similar to
> analyze the actual content of the message (which, after

 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...! Only this time, the airplane was designed by Heath 
Robinson or Rube Goldberg.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Bill Cole <[email-masked]>
Date: Wed, 28 Jan 2009 22:55:36 -0500

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

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

> 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:
> 

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.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jan 2009 15:20:44 -0800

On Jan 28, 2009, at 7:55 PM, Bill Cole wrote:

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

Bill,

There is now the Authentication-Results header that offers dangerous  
ways to reveal SPF results.  The draft defining the use of this header  
suggests, in so many words, that local-parts are not to be included  
unless local-part macros are employed.

Please be careful about misrepresenting what is achieved when an SMTP  
client has been SPF authorized by a domain.  Don't describe the  
authorization as having "authenticated" the source domain.  It is  
worrisome to contemplate the number of people who will be mislead and  
harmed by the many ways that this erroneous  conclusion can be  
exploited by those with access outbound servers.  Earning the status  
of Authentication should not be based upon a number of doubtful  
assumptions.

-Doug