Re: Opening Debate on SPF vs. SenderKeys

On Sat, 21 Aug 2004 06:59:59 +0800, AccuSpam <support(_at_)accuspam(_dot_)com> 
wrote:

> >  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?
For bounces, you typically have an empty sender address "<>" and the  
message says something along the lines of "Your message to <xyz(_at_)abc(_dot_)com>  
could not be delivered for the following reasons.  This is a permanenet  
error."
Auto-responses are sent from the person's email address, as if they had  
written the message.
Challenges are usually sent with a special reply-to: address that ensures  
message delivery.
It's not a terribly important detail which of these it is, I suppose.

> > 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.
>
> 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.
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.  It  
was frustrating and I was emailing different abuse(_at_)interbusiness(_dot_)it  
addresses, but I think it just ended of its own acccord.
> AccuSpam ...
You are defending SenderKeys with features of AccuSpam!  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.
> >  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".
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.  If the sender uses SenderKeys and receiver does not,  
the receiver is again unprotected from spam using that user's forged  
address (by SenderKeys).  Thus they have to fall back on their other  
anti-spam & anti-forgery solutions (AccuSpam or spamassassin).
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.
> 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.
The only reason I am interested in SPF is to decrease my spam reception.   
If I wanted receivers of mail to be able to ascertain that I was truly the  
sender of a message, I would use PGP.
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.
> > - 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.
TMDA doesn't detect forgeries, although it does have a "sender-keyed"  
address; you can give someone a secret email address which bypasses  
filters, but only when sent from their address.
> > - 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' ?
> > 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.
I suppose I threw that note in there to help explain the operation of  
SenderKeys more than to suggest it as a great alternative.
> > - 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
2. Providing private keys & authority urls to SenderKeys users
3. Backing the authority URL in some way (website?)

> > - 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.
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.
Is there some other kind of forwarding you are thinking of?

> In essense, AccuSpam is ...
not SenderKeys?

> 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.
> 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.
> I already said that AccuSpam ...
...is not what we are discussing ?

CU
Dobes