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