CC: me as I'm not presently reading cypherpunks (this was bcc:ed to coderpunks). On Sat, 13 Dec 1997, Adam Back wrote:
The required filter functionality is something like this in order of desirability:
Accept the SMTP session. Use an EHLO extension HASHCASH to say that this server expects hashcash. (Extended HELO is a method of specifying SMTP extensions (I think)). Accept the headers, and if a valid hashcash postage is not included, hand off to the real mailserver a site configurable bounce message.
I'm not sure this is doable. From what I've seen of the sendmail anti-spam stuff and the SMTP protocol, you can't just accept the headers and then decide whether not not to accept the rest; you either have to be able to (at present) a) reject the message before you receive it based on the FROM data (known spammers, bogus hostnames, etc); b) reject the messages before you receive it based on the RCPT data (anti-relaying: is the recipient at our site?); c) reject the message after you receive it. Obviously with spam, you'd like to be able to reject it before it takes up bandwidth. So, an extended protocol could require a CASH command from the client before DATA will be accepted. The client could generate the cash on the fly, or it could be grepped out of the headers. If you don't want to dink around with patching sendmail or whatever for an extended protocol, then simply use a system-wide procmailrc to enforce hashcash; procmail can generate bounces very easily (or rather, trick the MTA into generating the bounce for it). Or, make requiring hashcash a user-selectable option by having a publicly-available script which a user can have included into his .procmailrc by setting some variable.
This still leaves open the question of the user generating their own hashcash postage. Again this could be problematic for neophytes. One solution is to include a URL for a web page including a javascript hashcash generator -- this means that no new software must be installed, the user cut and pastes the generated hashcash into their message.
Two potentially simpler solutions: a) the client MTA could generate hashcash on the fly as needed (like it generates Message-IDs); b) a filter could be installed in place of the user's normal MTA which generates hashcash. The latter is probably better (easier to implement). For example, if the normal MTA is sendmail, then a fake sendmail could be installed which is just a nasty little script which parses out the recipients, generates a suitable hashcash token for each one, and inserts the appropriate headers, and then passes the message off to the real sendmail. My preferred means of spam-blocking right now is a barrage of tests for typical spams using procmail, combined with a reverse spam block. An ordinary spam block is an address munge where something is added to the address to make it undeliverable, so ordinary users have to unmunge your address before they can mail you, i.e. andy@neptune.chem.uga.nospam.edu. A reverse spam block lets you use your real address for posts but requires users to add something to your address to guarantee delivery. As my sig indicates, if you add +spamsucks to my username, various spam filtering features are deactivated. If I wanted to, I could bounce anything which didn't have the +spamsucks in it. The recipe I use also uses lists of "trusted" users (ones I don't do any spam testing on, so they don't need the password) and "spammers" (we don't spam test these either, we just make them bounce). Also will reject messages where I am bcc:ed (unless from someone trusted or the password was used) or on a huge visible list (again as before). It works pretty darn good. I hardly get any spam. Most of what I get bounces back to the sender with "User unknown". If the sender has a forged From, then this at least bounces there, or to the site's postmaster, who will likely take some action (but not complain to me because I don't exist). If the From was completely bogus, then I get the bounce, but that doesn't happen too often. I use this same system for the return address of the cracker remailer (anon@anon.efga.org) and it works pretty well, though as of late I am munging the return address for all USENET posts a la mail2news_nospam@anon.lcs.mit.edu (which has been hugely effective); you're not supposed to reply anyway... I would like to modify the nymserver so that users can set a reverse spam blocking password, but just haven't gotten around to it. I'm pretty sure it can be done, though. Andy Dustman / Computational Center for Molecular Structure and Design For a great anti-spam procmail recipe, send me mail with subject "spam". Append "+spamsucks" to my username to ensure delivery. KeyID=0xC72F3F1D Encryption is too important to leave to the government. -- Bruce Schneier http://www.athens.net/~dustman mailto:andy@neptune.chem.uga.edu <}+++<