9.16.4 Hashcash

A novel technique to fight spam is to require senders to do something
costly and demonstrably unique for each message they send. This has
the obvious drawback that you cannot rely on everyone in the world
using this technique, since it is not part of the Internet standards,
but it may be useful in smaller communities.

While the tools in the previous section work well in practice, they
work only because the tools are constantly maintained and updated as
new form of spam appears. This means that a small percentage of spam
will always get through. It also means that somewhere, someone needs
to read lots of spam to update these tools. Hashcash avoids that, but
instead prefers that everyone you contact through e-mail supports the
scheme. You can view the two approaches as pragmatic vs dogmatic.
The approaches have their own advantages and disadvantages, but as
often in the real world, a combination of them is stronger than either
one of them separately.

The “something costly” is to burn CPU time, more specifically to
compute a hash collision up to a certain number of bits. The
resulting hashcash cookie is inserted in a ‘X-Hashcash:’ header.
For more details, and for the external application hashcash you
need to install to use this feature, see
http://www.hashcash.org/. Even more information can be found
at http://www.camram.org/.

If you wish to generate hashcash for each message you send, you can
customize message-generate-hashcash (see Mail Headers), as in:

(setq message-generate-hashcash t)

You will need to set up some additional variables as well:

hashcash-default-payment

This variable indicates the default number of bits the hash collision
should consist of. By default this is 20. Suggested useful values
include 17 to 29.

hashcash-payment-alist

Some receivers may require you to spend burn more CPU time than the
default. This variable contains a list of ‘(addramount)’ cells, where addr is the receiver (email address
or newsgroup) and amount is the number of bits in the collision
that is needed. It can also contain ‘(addrstringamount)’ cells, where the string is the string to use
(normally the email address or newsgroup name is used).

hashcash-path

Where the hashcash binary is installed. This variable should
be automatically set by executable-find, but if it's nil
(usually because the hashcash binary is not in your path)
you'll get a warning when you check hashcash payments and an error
when you generate hashcash payments.

Gnus can verify hashcash cookies, although this can also be done by
hand customized mail filtering scripts. To verify a hashcash cookie
in a message, use the mail-check-payment function in the
hashcash.el library. You can also use the spam.el
package with the spam-use-hashcash back end to validate hashcash
cookies in incoming mail and filter mail accordingly (see Anti-spam Hashcash Payments).