spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Design bugs in v=spf1

2006-09-19 15:07:42
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
More email gets validated every day with SPF than have ever been
validated with the PGP (all variations), PEM, S/MIME, etc. combined in
the history of their existence.  They have filed in the market to
become a general usage standard.  They have useful special-use cases,
but they are not worth break the pre-DATA advantage that SPF currently
has.

SPFv3 w/ DKIM/PGP support doesn't have to break pre-DATA processing of 
envelope-data policies.  E.g., "v=spf3 pgp:blah mx -all" can very well 
yield a "Pass" pre-DATA.

We will know that it is time to start another revision of SPF when
people who have not participated in SPFv1/SenderID start coming in and
saying "I like SPF, but it needs to do <xxxx> too".  This isn't
happening.

I think you're misconceiving the e-mail security market.  It doesn't work 
like users or domain owners standing up and saying: "I need <xxxx> to make 
my e-mail secure!"  It's almost entirely a seller's market.  In this 
market most buyers don't actually know what they really need because most 
problems are below their threshold of consciousness.  Yes, most domain 
owners know the problem of sender address forgery, but they aren't aware 
that anything could possibly be done about it.  They have simply grown 
accustomed to the low SNR.

The only buyers who could consciously ask for new features are essentially 
the big ESPs (and perhaps other large infrastructure organizations like 
banks) who have been forced to deal with abuse problems on significantly 
large scales.  And not even they have come up with the right "questions" 
until a few years ago.

It is people who like creating new stuff that want to create a new
version of SPF.  If you want to create new stuff, find something other
than a new version of SPF.  At least for the next several years.

Excuse me, and not wanting to be rude, but it's not just _your_ lawn, so 
please stop telling me to keep off it.

My motivation isn't to play around but to push SPF forward so it allows 
senders to express their _real_ policies.  No doubt, protocols are not 
software, and if it was just about a number of nits such as "ip{4,6}:" vs.
"a:", then no one would be talking about SPFv3.  But these real-world 
policies include significantly more than just IP-address-based outbound MX 
authorization, and it's hardly a mistake to reflect that in another 
revision of SPF.

It will certainly take at least another year until a specification for such 
a revision could reach a semi-stable state, but if we wait "at least for 
the next several years", this "something other" will be filling that gap 
anyway, now that the sellers have begun to learn (and buyers to accept) 
that RFC (2)821 & co. are not carved in stone.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFEGnYwL7PKlBZWjsRAkJRAJ4jGXarxT6vEWh0wbCVW/XRLUFEcwCfecTr
7Umb2vgJIP7rjTF3NqQ69Ho=
=5Z3r
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>