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]