-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been thinking about SPF Unified and how it would be implemented. I've
also been thinking about the users of SPF Unified and what they would have
to do. Let me outline first what I believe are the strengths of SPF and the
reason why it is adopted by more than 100,000 domains.
(1) SPF is simple. Most people with only a casual understanding of SMTP will
get it.
(2) Deploying SPF records is extremely simple. You don't even have to
understand SMTP to publish. Putting the syntax together is easily handled
by JavaScript.
(3) Checking SPF is pretty easy. All I have to do is configure my MTA a bit
and add some code. That's it. The only decision to make is whether to throw
away SPF FAIL mail. Spam filters can add SPF and all kinds of fun things,
but I will never do it on my own.
(4) SPF is standard. Just as everyone knows that 4 quarts make a gallon, and
even schoolchildren are able to master that fact, SPF is easy to parse and
understand for people who understand some things about the internet. "mx"
is for mail servers for a domain. "a" is where you put specific machine
names. "ptr" is for including classes of machine names. "ip4" for ip
addresses and classes. "include" includes other SPF records. "all" means
everything else. And there are other, more advanced features. "+", "-",
"?", and "~" mean PASS, FAIL, NEUTRAL, and SOFTFAIL respectively. The
default is PASS.
SPF followed the KISS principle to an extreme. The result is that after
about 5 minutes of reading, or 2 minutes of conversation, people get
convinced that SPF will work. After they decide to do it, the
implementation is even easier. We spent more time talking about SPF at
Amazon than deploying SPF. It literally took less than 10 minutes to get
published.
Is SPF perfect? No. But perfect isn't what we're after. We're really looking
for something that is good enough to end spam. I believe SPF is good enough
for the authentication phase. The problems it has have already been worked
around.
Now, onto SPF Unified. All of a sudden, the simplicity is lost. Now people
need to familiarize themselves with the SMTP protocol to a level that isn't
generally necessary. They have to learn about a new algorithm - PRA - and
it's arbitrary ordering of headers. They have to figure out which way they
want to deply - SPF/HELO, SPF/MAILFROM, SPF/PRA, etc - and that is not an
easy decision to make, let alone even to understand.
Then on the checking side, they have to figure out what they will check for.
Do I have to check everything, or can I pick and choose? Which ones are
necessary? Which ones have security concerns? Which ones just aren't used?
I don't see SPF Unified as adding much to SPF. The problems of SPF do exist,
but they are so small that the solution is worse than the problem.
Perhaps someone here can persuade me that SPF Unified is the right thing to
do, but as it stands now, it seems way too complicated.
- --
Jonathan M. Gardner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBQes1BFeYcclU5Q0RAhSMAJ4hLTDnjRfA2nO+818Ay6TmXLdjvgCggkas
YYfkLzfNUoSnMkOmbXUtUnw=
=nYMi
-----END PGP SIGNATURE-----