gnus: Hashcash

 
 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’ (SeeMail Headers (message)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 ‘(ADDR AMOUNT)’ 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 ‘(ADDR STRING AMOUNT)’ 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 (SeeAnti-spam Hashcash Payments).