spf-discuss
[Top] [All Lists]

Re: Opening Debate on SPF vs. SenderKeys

2004-08-20 11:58:52
Strengths of SPF and SenderKeys
=========================

I was hoping others here would go directly into substantively comparing which 
scenarios SPF and SenderKeys are more viable than each other.

Since that has happened yet after > 25 posts in this thread I started, I will 
try to nudge the discussion in that direction if possible.

So far (and my viewpoint is open to change from discussion), I see SPF and 
DomainKeys as the most efficient solutions to stop all forgery from dedicated 
domains, such as ebay.com, wellsfargo.com, etc. that are victims of phishing.  
This is because for example in SPF, the protected domain can be marked as 
"-all" (assuming the corporation creates another domain for it's employees who 
are not restricted to use corporate mailservers), which means one can very 
efficiently block all e-mail for that domain not coming from the approved mail 
servers.  Although DomainKeys has an apparent advantage in forwarding 
compatability, SPF probably wins on efficiency of sender adoption (DNS setting 
only) and SMTP processing.  So thumbs up to SPF.  We need SPF!

However, for personal and small organization domains, as well as for ISP 
domains, it is not going to be practical to get them all to declare "-all", 
because of the varied use of email.  Imagine the personal domain owner having 
to coordinate with his ISP or Host to setup a way to SMTP AUTH on the server, 
having to upgrade and configure his email program to interface with the type of 
SMTP authentication supported by his ISP or Host (there are several flavors of 
SMTP authentication, e.g. POP before SMTP, etc.), then having to fight with 
ISPs that block ports or other incompatibilties that are bound to occur with 
moving to authenticated SMTP (which I think is highly underestimated because it 
involves two extremely variant variables- clients and servers).  Besides the 
forwarding complexity of SPF (SRS) would give DomainKeys the upper hand in 
terms of end-user complaints in this wider market, 
 but DomainKeys is more effort for senders to adopt (more than simple DNS 
change).

You can already see an implied admission on SPF website FAQ, that SPF will 
struggle to get personal and small organization domains to declare SPF records 
(not even mentioning the impossibility the majority of them will ever be marked 
as "-all), so instead they advise a heuristic that assumes a close relationship 
between MX and A records, which I find to be unthinkable given I own 100s of 
domains and the MX I use from my client MUA is never related to the A record of 
the domains (also just think about people who own 100s of domains...you think 
they can manage that SPF complexity nightmare?):

=======
http://spf.pobox.com/faq.html#guess

"Mail::SPF::Query provides a best_guess method, which pretends the domain had 
declared "a/24 mx/24 ptr". This is remarkably good at detecting unforged 
messages from domains which have not yet implemented SPF. It helps reduce false 
positives."
=======

Whereas, with SenderKeys, the ISP or personal domain user, simply responds to a 
enticement e-mail and upgrades his email program (MUA).  The upgrade might even 
happen automatically (as part of an OS upgrade) before the user ever sees an 
enticement e-mail, because I only know of one email address in all the ones in 
my businesses that ever received bounces due to being forged-- forgery is 
(luckily) not yet that widespread, so if we act soon, most users will never 
know they were being forged.  And compatability with servers is assured, 
because SenderKeys expects no changes in SMTP usage.

So I view SPF and SenderKeys as complementary.  They each solve a different 
problem.  I think SPF is actually more important initially because the phishing 
of big corporate domains threatens to undermine the use/trust of e-mail for 
corporate communication.

But SenderKeys is more important long-term, because until we can know with 
certainty that a spoof of an ISP domain is forgery, then we can not do better 
anti-spam than assign an additional probability to the e-mail that fails SPF.  
With SenderKeys, we can delete the forgery with higher confidence.  And 
spammers are not doing too much existent forgery now, but with domain 
reputation anti-spam like AccuSpam, they will be forced to.

So my philosophical summary is that SPF is important for corporate dedicated 
domains (server MUA), it gives a probability metric of forgery for ISP domains, 
it will have very low market penetration for personal domains and we need 
SenderKeys to take over the rest.  SenderKeys will be more effective 
anti-forgery solution for any human sender who uses a client MUA (email program 
instead of a server) and uses his/her email program with freedom and without 
the constraints and complications of dedicated mail relays and complex 
forwarding "From:" address munging.

-Shelby Moore
http://AccuSpam.com