spf-discuss
[Top] [All Lists]

Re: Opening Debate on SPF vs. SenderKeys

2004-08-20 15:59:59

require MUA upgrades.  Consider this message, signed with PGP using
Windows Privacy Tools, all open-source despite that I'm using Outlook
2000.

... with SenderKeys, the ISP or personal domain user,
simply responds to a enticement e-mail

Enticement email = spam, sorry.

I get a different read on this algorithm; perhaps if I re-summarize it:

SenderKeys is like PGP in that messages are signed using public-key  
encryption.


Correct.



Additionally, if a message is not signed, the receiver can generate a free  
private key using his authority server for the sender address and mail it  
back to the user in the "enticement" email.  Its not mentioned, but  
presumably if he doesn't trust your authority server he could ignore the  
signature and send you an additional key (the SenderKeys docs mention that  
multiple signatures may be included with the message).


Correct.



If your MUA has already been upgraded, it should intercept this message  
and start using that private key to send emails automatically.  Otherwise,  
there will be a link in there telling you how to upgrade your MUA.



Correct.



Thus the problem is completely localized to the MUA, satisfying his  
apparent goal - to avoid changes on the server.


Correct.   Kudos on being so astute.  Thanks!


I imagine there would be a market among advanced computer users (someone  
who would install Windows Privacy Tools, maybe) who are using the email  
address and mail servers provided their ISP (e.g. joe(_at_)aol(_dot_)com) and 
are  
therefore unable to implement filtering etc. on the server-side.


The authority can also be a server-side filter, as AccuSpam is.

So the market is not limited as you state.



The implementation would have to be careful, however, not to repetitively  
send enticement mails to people who don't install SenderKeys, because  
SenderKeys will not be accessible to everyone.


This could be a simple link in the enticement to click "Do not entice me to use 
SenderKeys".

We do not need a Catcha hassle because the spammer won't get the enticement if 
he is forging a sender.


The SenderKeys overview mentions that you could configure it to only send  
the enticement if the user is blacklisted (as opposed to  
non-whitelisted).  I suppose this means that if you start receiving spam  
from a particular address you blacklist it manually; if it is a real user  
they will be forced to install SenderKeys in order to communicate (or is  
there a challenge-response backup?).


AccuSpam has a challenge-response backup for blacklisted addresses, as well it 
ages (removes from blacklist) so individual addresses are not the target of the 
blacklist.  An occassional forging of your address will leave no lasting 
footprints.  Only a sustained forging of your address could cause you to have 
to do a challenge-response, but then you've got bigger problems any way if SPF 
is not already protecting you.  You see I think people here failed to realize 
that SPF can be a first line of defense so you only do SenderKeys if you really 
need it (SPF not stopping forgery and you getting a hell of lot of forgery).

It is a market driven then.  We do not decide.  The users do.



 In the blacklist case, the  
'enticement emails' would be delivered as bounces I suppose.


What difference are you referring to between a bounce and an auto-response?

Then I can answer.  I think the challenge-response for blacklist case (remember 
AccuSpam does not challenge-response in non-blacklist case) is just another 
auto-response.  What are you getting at?


My suspicion is that this would become the most common use.  I used to use  
tmda and I have disabled its challenge-response mechanism because it is  
too confusing for novice users and blocks receipts, mailing list  
confirmations, and order confirmations from online services.


100% AGREED!!!  I hate CR anti-spam!  AccuSpam is not CR anti-spam.  It is CNR 
anti-spam.  See below for more on that.

No the CR are only sent in the blacklist case, and again these CR will also be 
saying that you can either do the CR or enable your MUA for SenderKeys for a 
lasting solution. Or click a link which says "Do not send me these 
auto-responses".

In any case, this is not the major case, because how many times has your 
address been forged recently?  Be realistic.  If you are being heavily forged, 
then you either need to do "-all" for SPF or SenderKeys.  AccuSpam does not 
care.  Either one will solve it and stop the blacklisting.  AccuSpam supports 
and uses SPF (sorry I forgot to mention that).

So if you do nothing and you are getting heavily forged, then you are going to 
blacklisted in Spam Assassin and other anti-spam also.  It is not peculiar to 
SenderKeys (or AccuSpam).

Forgery and errant blacklisting is one of the problem we are trying to solve 
with SPF and SenderKeys.


 In this  
mode, however, SenderKeys is not an anti-spam solution for the receiver,  
it just prevents impersonation when sending mail to other SenderKeys users  
and allows SenderKeys users to bypass the blacklists of other SenderKeys  
users.  Spammers can continue to bypass the system the same way they've  
been bypassing blacklists all along.


Incorrect.

SenderKeys stops the receiver from receiving the forgery.  Same as for SPF if 
"-all".

The performance of blacklisting is not the point of SenderKeys or SPF.  Each 
kind of blacklisting is different.  AccuSpam uses domain reputation 
blacklisting which is very effective (91% already).



Compared to tmda:


It appears you are comparing AccuSpam to a CR system and AccuSpam is not a CR 
system.

Besides, SenderKeys is not anti-spam, just as SPF is not anti-spam, they are 
both anti-forgery.

If you want to discuss the anti-spam side of things, just make sure we are not 
discussing SenderKeys then, just as if we were discussing how Spam Assassin 
deletes spam, we are not discussing SPF, even though SPF integrates with Spam 
Assassin.


- tmda only requires intallation on the receivers' side

Tmda is for anti-spam.  Same as AccuSpam for anti-spam.

- tmda does not require senders to upgrade their MUA

Neither does AccuSpam.  But if TMDA wants to delete forgery with it needs 
either SPF "-all" or SenderKeys, just like AccuSpam and SpamAssassin do.

Note that without "-all", AccuSpam, TDMA, and Spam Assassin (and any other 
anti-spam) can assign perhaps a 90% probability of forgery but not 100%.


- 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.  Each 
anti-spam does whitelisting in a different way.  AccuSpam's method is very 
different than what you are describing.  AccuSpam lets the recipient decide 
what to whitelist.  AccuSpam is able to delete (currently 91% and rising) of 
the spam before it asks the recipient whether to whitelist.


- whereas in tmda you can tell them to use a sender-specific address to  
email you

I have already discussed the disadvantages of disposeable email addresses 
(irrelevant any way to SenderKeys only relevant to anti-spam discussion):

http://www.windowsbbs.com/showpost.php?p=179171&postcount=21


Note: If you are willing to upgrade the senders' MUA, then of course you  
could automate the process of acquiring a tmda sender-specific email  
recipient address; this would be functionally equivalent to SenderKeys  
except the message body would not be protected from tampering.


It would be Tmda and disposeable address specific and would not interopt with 
all possible verifiers who want to do anti-forgery.  Additionally, SenderKeys 
gives much flexibility to verifiers as to what to trust and how to combine the 
results from different authorities.  There is much room for people to add their 
own algorithms and value to the anti-forgery which might exceed what we could 
imagine. 



I don't aticipate that spammers will tamper - oh the horror!  I can just  
see a letter from my mother suffixed with a bunch of random words and a  
link to some maternal rape site.


LOL!  :)



Compared to SPF:
- with SPF, *(_at_)domain are taken care of, SenderKeys does individual sender 

addresses


If ALL users of *(_at_)domain can be verified to be ALWAYS doing SMTP AUTH on 
the approved mail servers, which I assert is impossible for an large ISP to 
EVER verify.



- with SPF, central administration is dealt with using DNS; SenderKeys  
include an authority URL with each key, and any user may have a keypair on  
any authority


Correct except that expect the market to give precedence to authorities of 
known stature and policies to be developed.

Multiple authorities might be more redundant than DNS, but I have no quibbles 
with SPF here.  DNS is okay.  Just can't use DNS for sender granularity so had 
to invent something else.


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


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


- SPF spreads by accompanying the old mantra "close open relays!" with a  
new mantra "close open domains!", SenderKeys spreads from person to person  
as the enticement bounces are read by non-users (these messages are  
automatically handled and removed by the SenderKeys software).


Or SenderKeys spreads by simply users upgrading their MUAs after seeing a new 
feature listed for the upgrade:

"Stops most forgery of your email addresses automatically".

You are pretty much dead on correct in most of your post, except you have big 
misunderstanding on this following final point:


I would give SenderKeys an overall thumbs down. MUA-based solutions don't 
gain traction.


That we can debate.  POP gained traction.  Without MUA traction (get all users 
to upgrade to latest version of their MUA and manually configure), how will you 
ever get SMTP AUTH?  Without SMTP AUTH, how will you get "-all" for SPF 
domains?  Without "-all", how can you detect forgery with 100% certainty with 
SPF?


Blacklist-based systems don't stop SPAM.


Here you are evaluating SenderKeys in terms of the authority's algorithm for 
when to auto-respond.  What you assume is that for example, AccuSpam is 
blacklisting individual addressses, which is not the case.  AccuSpam is 
counting the disapproval vs. approval ratio for a domain:

"STATISTICAL BLOCKING BY DOMAIN"

http://forums.speedguide.net/showpost.php?p=1384560&postcount=114

then if it is a spammer domain (one that sends > 99% spam from a probablistic 
metric ... not pure ratio), then it blacklists the entire spammer domain (e.g. 
gooddeals.com, a001.com, etc).  The statistics theory prevents blacklisting of 
domains that send some non-spam.

So the blacklisting of AccuSpam does stop spam.  In fact, 91% as of last 
measurement on average for all our users!  It will exceed 99% once we reach 
10,000+ users.

In essense, AccuSpam is (domain reputation) what people are hoping SPF will 
enable for anti-spam.  And I am telling you that SPF will not really help until 
we can say "-all" for all major ISPs and then ultimately for all personal 
domains, as spammers move their forgery to domains that are not "-all".

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.

How is the ISP going to confirm that?

Impossible.  There simply isn't any mechamisn in SPF to confirm that or to 
remind the user.  And what you going to do for users who upgrade their MUA (to 
SMTP AUTH) but can't figure out how to use it correctly?  At least with 
SenderKeys they upgrade their MUA and it happens automatically.

There are so many reasons, I could go on and on and on...


And 
whitelist-based systems block the most important mail - "Your order has 
been shipped" and "Please confirm your email address". 


I already said that AccuSpam does not do this.  AccuSpam is radical new 
invention called "CNR" - Challenge Non Response.

AccuSpam sends a confirmation (not challenge) auto-response to new senders (not 
yet on white or blacklist).  The sender is not required to do anything.  Then 
AccuSpam deletes (currently 91% and rising) of the spam by STATISTICAL BLOCKING 
BY DOMAIN as detailed above.  Then remaining email is shown to the user has a 
Daily Summary email which user can request any non-spam to be delivered to 
Inbox.

So it is impossible for AccuSpam to block legitimate email unless your domain 
is sending 99+% spam.


Thanks,
Shelby