spf-discuss
[Top] [All Lists]

Re: Opening Debate on SPF vs. SenderKeys

2004-08-20 18:49:06

In any case, this is not the major case, because how many times has your  
address been forged recently?

Well actually, I get a fair amount of mail from my own address as well as  
randomly generated users at my same domain name.  If both of these were  
blocked as forgeries that would be a significant difference.


That is priority for spammer to try (because it gets past many whitelists) and 
trivial to filter.  You do not need SPF of SenderKeys for that.

Filter all email from yourself.  If you need to send email from yourself, then 
use a tunnel password, send to secret address which forwards back, or some 
other simple mechanism.

Your blacklist should be told which other address are valid on your domain.



Once my address was being used as the sender address for a bunch of spam,  
and I did receive about 700 bounces over the period of a week or so.


Yes that happened to me once months ago or perhaps it was last year.  And 
similarly it stopped.  I think the spammers found out that was not effective.  
I have not seen it since.


 It  
was frustrating and I was emailing different abuse(_at_)interbusiness(_dot_)it 

addresses, but I think it just ended of its own acccord.


If it continued, then you (and I) would have needed SPF or SenderKeys from 
perspective of a sender.  Mostly right now, SPF is needed by anti-spam 
recipients more than it is needed by senders.  The only senders who need it 
real bad are the corporations being phished.

This goes right back to my economic analysis of adoption...



You are defending SenderKeys with features of AccuSpam!

Not intentionally.

As I said, think of SenderKeys as:

1. No SenderKey header, then authority sends private key back to sender mailbox.

2. If MUA that reads the mailbox is SenderKey aware, then SenderKey is 
automatically enabled for sender.

3. Else sender reads a message explaining how to upgrade his MUA.

Simple.

Nevermind what the verifier does with the SenderKeys answer, just as we can 
nevermind what the verifier does with the SPF answer.  Verifiers see a 
SenderKeys header, they ask authority for public key, so they can compute the 
answer, just as they ask DNS for IPs in SPF so they can compute the answer.



 You should prefix  
these with "when used with AccuSpam...".  I don't need SenderKeys to get  
the benefits of AccuSpam, and I shouldn't need AccuSpam to get the  
benefits of SenderKeys.  If you want to merge the two ideas, perhaps this  
could be called AccuSpam+SenderKeys or whatever new name suits.


Correct.  I am trying to do that, it is just that I am being asked questions 
that lead that direction.

The degree and volume (not you) of misunderstanding and oblique accusation 
makes it somewhat difficult to respond in perfect orthogonality of AccuSpam and 
SenderKeys.  I am trying to make it clear they are orthogonal.


I wasn't being precise enough, I'll amend it: if the receiver uses  
SenderKeys, but the sender does not, the receiver is not protected from  
that user's spam.


Well in the same sense that if receiver does not use SPF, then receiver is not 
protected from that user's spam.

But bear in mind, that verifiers may use multiple algorithms and techniques to 
stop spam, just as they do now.  But agreed, this is orthogonal to SenderKeys, 
just as it is orthogonal to SPF.


 If the sender uses SenderKeys and receiver does not,  
the receiver is again unprotected from spam using that user's forged  
address (by SenderKeys).


Yes in the same sense that if we replace "SenderKeys" with "SPF" in above 
paragraph.


 Thus they have to fall back on their other  
anti-spam & anti-forgery solutions (AccuSpam or spamassassin).


Or SPF or ...  Yes agreed.  SenderKeys is just like SPF in this regard.


This is the same as SPF, though, you're right: both parties have to  
implement SPF (in DNS for senders and in the MTA for receivers).  There  
are fewer parties involved with SPF though, and they are more tech-savvy.

I think actually it is almost the same, except one big difference.

In SenderKeys, the sender has to upgrade his MUA.  In SPF "-all", the sender 
has to upgrade and/or configure his MUA in most scenarios (we can debate this 
okay to make it clear okay?).

In SenderKeys, some people have to establish authorities and these are tech 
savvy, just as the receiving MTA are done by tech savvy for SPF.

The difference is that for personal domains, the sender has to do nothing more 
for SenderKeys, but for SPF they have to do DNS configuration (and 
maintenance!) and they will very often not be tech savvy.

But the bigger difference is in the ongoing use.  With SenderKeys, the user 
just chugs along ignorantly with his SenderKeys enabled MUA.  Upgraded once and 
forget it.  But with SPF, the sender may change ISPs (need to update DNS 
record), change email programs (need to reconfigure for SMTP AUTH), change or 
buy new domains, etc..  All of these things require no ongoing maintenance with 
SenderKeys, as it is automated *FOREVER* once vast majority of MUAs are.

This ongoing cost is going to kill SPF as explosion of use of domains occurs, 
just as maintaining DNS will become more nightmare with the explosion of 
available IPs in IPv6.  SPF is fundamentally flawed for this purpose because 
the granularity of domains is actually more than the granularity of DOMAIN x 
IPs is more than MUAs looking into future.

As a said, SPF is perfect for solving phishing and for first line of defense 
(without "-all").  Widespread "-all" is impractical for many, many reasons.

Eventually we all will face that reality.  It is difficult to accept that SPF 
can not be the end all solution, but if we can get past that and we can start 
to apply SPF more aggressively where it is best and develop the solutions for 
the rest of the cases.

There actually was wisdom in the original SMTP (as proved by the fact that 
email is most popular application in the world).  You should be very careful 
not to break it.  I think it is better to keep the freedom of SMTP and fix the 
problem of forgery with SenderKeys like mechanism.


The only reason I am interested in SPF is to decrease my spam reception. 


Agreed.  Senders do not have much motivation, only receivers of forged spam do. 
 That is another reason why widesread SPF "-all" will not happen.

  
If I wanted receivers of mail to be able to ascertain that I was truly the  
sender of a message, I would use PGP.


Are you saying you do not like SenderKeys because you want your receivers to 
still have some doubt whether you are being forged?

Because the goal of SPF "-all" is to tell your receivers whether you are truely 
the sender (well within any possible sender on your IP which in all likelihood 
is true else we could not delete forgery on SPF "-all").  It is circular logic.


As soon as messages are blocked instead of being delivered with a security  
warning, you've converted an anti-forgery system to an anti-spam system;  
albeit by considering forgeries to be unwanted/unsolicited email.


You just wrote that you want to reduce your spam.  Wouldn't that include 
deleting forged emails?

Remember that SenderKeys is no different than SPF in that verifiers can decide 
how to dispose of a message.  SenderKeys verifiers can also be at the MTA and 
mark a message as "Security Risk" if you prefer.



- SenderKeys allows an address to be whitelisted only if its messages  
are
cryptographically signed

SenderKeys has nothing to do with the decision of what gets whitelisted.

Sorry, I'm using the word 'whitelisted' when perhaps I should have said  
'bypass filters' ?


Verifiers decide what to do with the SenderKeys answer, just as they do with 
SPF answer.  There is nothing special about SenderKeys in that regard that is 
different than SPF.



- SenderKeys can be installed without adminstrating a server (except the
authority server, perhaps)

Yes but much less authorities needed as compared with SPF DNS records.

I think the operation of the authorities deserves some elaboration.

They seem to be responsible for:
1. Deciding what to do with unsigned messages

No.  Verifiers do that just as they do with SPF.

2. Providing private keys & authority urls to SenderKeys users

Yes.  Think of authority as the DNS databases for senders instead of domains.  
And SenderKeys has a mechanism for automatically configuring the MUA of a 
sender from an email from an authority.

3. Backing the authority URL in some way (website?)


Or certificate as mentioned in the Overview.  Or simply reputation, since 
verifiers (e.g. Spam Assassin, AccuSpam, SourceForge projects, etc) will 
probably know who the popular authorities are.

This area of the specification is more open at this time to input.


- SenderKeys uses cryptographic signatures to identify the sender, SPF
uses the IP address of the delivering server

Correct.  Very important point because for example this is why SPF  
breaks forwarding and SenderKeys does not.

Perhaps you can elaborate on this point?

If I use forwarding to deliver mail (e.g. I delegate mail delivery to some  
other mail server) then I can add that mailserver to my SPF record.


As a sender yes you can do that.  But as a receiver you can not.  For example 
(and there are many, many others), some sender goes to a website submission 
form and sends you one of those cutsy messages "I like this web site, come 
check it out".  Or think of greeting cards, etc..

You and I might think that crap is spam, but there are 10 million AOL users who 
will mace with you with hairspray if you mess with their beloved hobbies and 
daily email fix.


If I use forwarding to receive mail (e.g. I have an external SMTP server  
relaying to internal mailboxes on seperate servers) then I can check SPF  
on the first server the mail arrives at.


As stated above, you can not know all the IP address of all the web submission 
forms that could forward you can email from a sender.


Is there some other kind of forwarding you are thinking of?

Yes see above.

Also a mailing list.  You and I might be savvy enough to add the mailing list 
to our DNS (what a maintenance headache), or some verifiers might whitelist 
mailing lists (but then they become open relays for spammers), but your average 
Joe User just goes to mailing list and sends and then wonders why (probably 
*SILENTLY*) half the list did not receive his email.

You want me to try to think of others?


In essense, AccuSpam is ...

not SenderKeys?


AccuSpam is the verifier.

SenderKeys is the specification of how authorities, verifiers, and senders/MUAs 
interopt.  SenderKeys gives great flexibility to what each of those do within 
the protocol of that interaction.


And I am saying it is going to very, very difficult to get "-all" for  
all domains.  Much better to have a sender granularity, since it is the  
sender that is most harmed by forgery of his address.  Realize that an  
ISP can not "-all" until **ALL** (every single one) customer has been  
confirmed to be using exclusively the mailservers of the ISP.

The sender is only protected from forgery when all receivers also have  
SenderKeys.


Ditto for SPF.


How is the ISP going to confirm that?

Here's a way: disable mail delivery; when they call to complain, explain  
how to set it up.  Users usually notice within a short time if their mail  
has stopped functioning.


That does not guarantee that Joe User does not go type his ISP email address 
into From: line in some free email webmail (e.g. hotmail, yahoo, or zillion 
others) when traveling without his computer.

With SenderKeys, the webmail will know it must check the sender's mailbox 
before sending.

With arbitrary website submission form, both SenderKeys and SPF fail.  I do not 
have a good answer to that one, because I do not think users will give their 
mailbox password to an arbitary website form.


Thanks,
Shelby