I do not know why MUA vendors would support other desired new protocols for
free in past and not SenderKeys. If SenderKeys really stops forgery, and
users want it, then I would expect demand = supply as always in economics.
What I find most amusing about this whole argument is that he argues
it's a flaw in SPF that it "requires" SMTP AUTH, which is already widely
implemented.
No that is very myopic to say that embodies my whole argument against "-all"
being widely adopted for SPF.
finger is widely implemented but is almost never used now.
If you consider "used" instead of "implemented", your "widely" becomes a few %
at best.
I challenge all of you, if you can get just ONE major consumer ISP (one of the
Top 10) to put "-all" in it's SPF records, then I will eat my words. Certainly
if SPF "-all" is mainstream then you can get on of Top 10, then BrightMail.com
has 7 of top 10 major ISPs. Overture.com has majority of top 10 search
engines, etc..
Then he pitches a system that would require everyone's MUA
to be updated to support a SenderKeys protocol that doesn't even exist yet.
You do not understand there is a big wide ocean between a user's cost to
download something (they do that often as evident by download.com success), and
getting users to understand and follow highly technical restrictions have to do
with terms such as "IP" address and "mail servers". SPF with SMTP AUTH not
just as simple as make a few settings in email program and forget it. There
are many ongoing issues that have to be considered depending on the users
pattern of use of how he accesses the internet, travels, use of email address
in web forms, webmail, etc... I think you are not even beginning to summarize
those possibilities and interactions with your assertion that SMTP AUTH is
"implemented".
With SPF not "-all" then users do nothing. SPF is very efficient. With "-all",
that big ocean problem occurs.
With SenderKeys the upgrade of the MUA is for dummies. Just download it and
forget it.
Thanks,
Shelby