Idea for alternative hashcash/antispam implementation.
Jesper Krogh <[email protected]> Thu, 12 May 2005 11:21:02 +0200
| Newsgroups | gmane.mail.spam.hashcash |
|---|---|
| Message-ID | <[email protected]> |
Yes, this idea probably renders invalid since it involves a change to the smtp-protocol. It basically implements payment on mail directly in the smtp-protocol using hashcash: 220 mail.linuxnews.dk ESMTP Postfix EHLO test 250-mail.linuxnews.dk 250-PIPELINING 250-SIZE 10240000 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5 250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5 250 8BITMIME 250-HASHCASH-ALG SHA1 MD5 MAIL FROM: <[email protected]> 250 Ok RCPT TO: <[email protected]> 250-HASHCASH 3 SHA1 abcdefghijk HASHCASH SHA1 <string1> <string2> 250 Ok This shold be seen as a trivial "joint-force" of Greylisting and hashcash, but instead of paying by sending a 450 come back later you send a hashcash (client-puzzle). Greylisting is currently an exstremely effective way to stop spam at the moment since most spammers use broken MTA's and thereby don't redeliver the message. But as greylisting becomes more and more used, this picture is likely to change. Greylisting uses an internal database with auto-whitelisting etc. which easily can be used to setting the challenge sufficient low for "known entities" and imposing a significant load on "newcomers". The greylisting database records: (from,to,clientip) on all mail and the idea is that if a client matches a record, then it's quite more likely to be "ham" than "spam" since spammers change client and from-address often. The only negative thing I can come up with at the moment is that it requires an SMTP-protocol update in order to work. Jesper -- Jesper Krogh, [email protected], JabberID: [email protected]