Re: SPF Configurations

[Sean Donelan <sean () donelan com>]

On Fri, 4 Dec 2009, John Levine wrote:
> than the other way around, believing that it prevent forgery, having
> redefined "forgery" as whatever it is that SPF prevents.  As the
> operator of one of the world's more heavily forged domains (abuse.net)
> I can report that if you think it prevents forgery blowback, you are
> mistaken.

Nothing can "prevent" forgery.  The forgers are going to keep making them. 
You can only try to make forgery easier to detect.  But you need other 
parties' cooperation to detect the forgery and react in some way.  Even if
you did stop one forger, i.e. prison; there will be plenty of up and 
coming forgers to keep making forgeries.

SPF, DKIM, PGP, S/MIME, DNSSEC, BCP38, sBGP, DRM, special paper and 
printing, wax seals, handwriting analysis, and so on; help cooperating 
parties detect particular types of forgery.  Assuming the cooperating 
parties actually want to.  Adding even more complexity probably isn't 
going to improve the degree of cooperation of uncooperative parties.

In practice, any security control will also affect something some 
"legitimate" party wants to do sometime.  And likewise, any security
control can be mis-implemented or mis-used.

In particular, what anti-forgery/security controls should network 
operators implement and check; and what anti-forgery/security controls 
should network operators not implement or check?  Are they better 
implemented and checked by the application/user instead?  Just as many 
people seem to get mad at ISPs when they do something, as get mad at ISPs 
when they don't do something.  And its often the same something.