White list of senders (challenge/response, greylisting)

If filtering is not effective, i.e. despite filtering lots of spam messages still find their way to one's mail box, a reversal of filtering may be considered. Instead of filtering spam out, one may define a white list - a list of addresses from which mail is welcome - and let through only messages coming from addresses that are on the list.

But what to do with messages coming from addresses that are not on the white list? They can be discarded altogether - a rather drastic measure that prevents any mail not only from spammers, but also from addresses one has forgotten to put on the white list, and from other people who might have legitimate reasons for sending mail, eg. encouraged to do so by some invitation on one's web site ("... if your are interested, send me a message.").

Such messages may be discarded but their senders may also be told how to include themselves in the recipient's white list, so that further messages are accepted without any obstacles. This idea has recently been named greylisting or challenge/response.

Timo Salmi, mentioned in filter incoming mail, proposes a sort of distributed white list, see Foiling Spam with an Email Password System. When a message comes from an unknown address, its sender gets a request to resend the message so that its subject line contains a given password. Messages containing the password in their subjects are let through. Messages without the password are put away, but their senders get the automatic request. The link above points to a more detailed description of the idea, and to a procmail script that implements it.

IMHO the idea has a drawback - it certainly prevents spam, but also forces all senders to put the password into the subject of each message they send to the user. To them, it might be annoying.

For Unix® and Linux hosts running sendmail, postfix, and possibly some other mail servers allowing so-called plussed aliases (mail server administrators may wish to see "plussed users" in their server documentation), it might be better to maintain a local white list that can be automatically expanded. When a message comes from an unknown address, its sender gets a request to send one empty message to an address that contains a sort of password provided in the request. Eg. a message from frank@dom1.net comes to john@dom2.com. The message is discarded, but frank@dom1.net gets a request to send an empty message to john+31415dzie@dom2.com, where 31415dzie plays the role of a password. The server (accepting plussed aliases) accepts the message as though it were for john@dom2.com, and the procmail script in john's home directory appends the sender's address to john's white list. From now on, messages of frank@dom1.com are delivered to john's mail box with no need for any passwords.

Such a white list may be accompanied by a black list formed out of addresses that were automatically appended to the white one, but john@dom2.com has decided not to receive any messages from them. A corresponding procmail script would then implement the following set of rules for a message that comes from an address:

• on the white list => put it into the mail box,
• on the black list => discard it,
• on neither list => discard it, and check the recipient address:
  • if it is john+31415dzie@dom2.com, append sender's address to the white list,
  • otherwise send a message to the sender with a request to use the address john+31415dzie@dom2.com just once.

• user's message goes to an addressee,
• an automatic reply comes back requesting the user to send an empty message to the addressee's plussed alias,
• the reply is rejected because its sender is not on the white list, and the request to send an empty message to the user's plussed alias goes to the addressee.

next