[119983] in North American Network Operators' Group
Re: SPF Configurations
daemon@ATHENA.MIT.EDU (Sean Donelan)
Sun Dec 6 17:56:53 2009
Date: Sun, 6 Dec 2009 17:56:05 -0500 (EST)
From: Sean Donelan <sean@donelan.com>
To: nanog@nanog.org
In-Reply-To: <20091204172504.30269.qmail@simone.iecc.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
