On Jan 30, 2009, at 4:47 PM, Ray Dillinger wrote:

I have a disgustingly simple proposal. [Basically, always include a cryptographic token when you send mail; always require it when you receive mail.]
There is little effective difference between this an whitelists. If I only accept mail from people on my whitelist, spammers can only send me mail through three modes of failure:

1. They randomly pick a return address that happens to match someone on my whitelist. I think we can agree that this is rare enough that it isn't
                worth worrying about.

2. A spammer somehow finds pairs of people S and R, where S sends to R, and fakes S as the sender for spam directed to R. This would be a new mode of attack - spammers today just spurt out millions of messages based on very little information. Sure, someone *could* start this kind of attack - but it's difficult to get the necessary information to mount it, and it seems unlikely that it would make economic sense to spammers, who can live
                with tiny response rates because they can so cheaply generate 

3. This is a variant of (2) that actually does occur today: The spammer takes
                over S's machine and sends to the same people S sends to.  
                try to spread by this mechanism; they often succeed.  In 
principle, a
spammer could write a virus that simply sent the (S,R) information from
                the infected machine, though I don't know that they've ever 

Either a type 3 attack, or a type 2 attack where the information comes from invading S's, machine, can of course just as easily grab all the tokens
                on S's machine.  The solution proposed is that this will be 
                quickly, and the tokens will be marked as no longer valid.  But 
                really no different from R simply removing S from his whitelist.

Really, cryptography is a non-issue here. As long as S and R share some information - even S's address will do - that R can use to filter messages; and there is no cheap way to get large amounts of (S,R)-pair information; that information can be the key to a whitelist. (Some mailing lists do this: E.g., if you want to post to RISKS, you're asked to include the string "notsp" at the beginning or end of the subject line. This is public information, so a spammer could easily do this *if he chose to specifically target the RISKS mailing list*; but there's no way he can do this automatically on a mass scale. An individual could easily reach a similar agreement with anyone sending him mail.

Of course, the downside is that you can now *only* receive mail from those on your (logical) whitelist. That's fine in some cases, unacceptable in others. You can semi- automatically grow your whitelist by sending using some kind of challenge/response. For example, if you could send back the message with a note saying: "You're not on my whitelist, if you want to reach me resend this message with 'xyzzy' in the subject line." Spammers don't bother to look for such messages right now (though if you made this automatic enough, and enough people adopted it, they would have a reason to!) so they won't be able to sneak on your whitelist that way. However, many people writing to you won't want to be bothered - and automated mailings that you *do* want to receive and don't know the details of ahead of time (e.g., approval messages for mailing list requests you make) won't get through either.
                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to