Re: An Anti-Spam Heuristic
"John Levine" <[email protected]>
| Newsgroups | gmane.ietf.asrg |
|---|---|
| Message-ID | <[email protected]> |
>Steve Atkins, I'm not Steve, but what the heck. >and discuss the concepts that I broached. A technical topic not mentioned in >that article specifically is the use of the sender's email address, recipient's >email address, and the date and time of the message event to seed or salt a >random number generator. It's clever, but since the fundamental problem with proof-of-work is that the bad guys can do more work than the good guys, the details of the work aren't particularly interesting. >reduce spam (2). It could be that your conclusion addresses one criterion (1), >while other criteria (2) and (3) could be achieved by increasing the >computational costs of sending and receiving emails. No, because the bad guys still have more computational power than the good guys. You could get rid of spam, but only at the cost of getting rid of all of the rest of e-mail, too. Effective anti-spam techniques have to be things that it's easier for good guys to do than for bad guys to do. This turns out to be hard. It also turns out to be subtle. For example, both good and bad senders can apply DKIM signatures to their mail, so signing per se is not an anti-spam technique. What makes them useful is that the signing identifiers can be keys into reputation systems that are designed to favor good signers. >Also, what might you think about discussions about versioning and advancing >email protocols, modernizing email-related computer networking protocols? SMTP has had an extension mechanism since RFC 1869 in 1995. There have been quite a lot of extensions proposed, some of which, such as pipelining and 8bitmime, are now universally adopted. Early definitions of SMTP had commands such as SOML and TURN that were found either not to be useful, or to have serious security problems, so they've been deprecated and eventually deleted. It's not exactly versioning, but the protocol has evolved somewhat. There have been a lot of proposals to "replace SMTP", but none have come anywhere near close to demonstrating sufficient utility to motivate people to bear the enormous switching costs from the existing deployed system. R's, John