21 May 2004 slamb   » (Journeyer)

Scott's Laws of Email Filtering. Amendments, anyone?

  1. Don't ever silently send email to /dev/null.

    (For bram, among others.) If you mess up your rules, you could drop important emails. You'll be unhappy, the sender will be unhappy, everyone will be unhappy. If you drop an email, let the sender know.

  2. Never send a bounce or reply to a suspected worm/virus email.

    The reason is simple: the address is usually forged. So if it is indeed a worm or virus sending it out, your bounce will go to some poor person whose mailbox is probably overflowing with these messages.

    Together with #1, the only option this leaves is to send a 5XX (permanent) rejection during the SMTP transaction. If it's a worm, it'll be connected directly to your SMTP server, so it will swallow the rejection and the address's real owner is never bothered. If it is a real person, their end of the SMTP connection will pop up a dialog box (if its a mail client connected directly) or generate a bounce (if it's an intermediate SMTP server). They know and can resend.

    The ones that are especially annoying to me are the challenge/response replies with two choices: "I sent this message and it's not spam" or "I never sent this message". I consider this quite rude. They're expecting me to filter their mail for them every time a mail is sent, instead of spending a little bit of their time to set up rules that would save me the trouble most of the time. (Of course, I always hit the button that will send the junk mail on to them; I'm not a turn-the-other-cheek sort of guy.)

  3. If you send automated email replies or forwards, filter likely worm/virus emails first.

    ...and then follow #1 and #2 with those messages, of course. Same reason as before.

  4. Keep your rejection messages polite.

    If an actual person is reading the rejection, you probably wanted to get the email. Be polite and tell the person how to get around the block.

If you follow these rules, you can be more aggressive in your filtering without too many consequences. For example:

  • I reject all messages with a subject line of "Thank you!". I'd like to think people might legitimately want to thank me from time to time. Perhaps they'd say so in the subject line. But the worst thing that happens is they get a polite reply asking them to change the subject line and resend. With a copy of the message included, should they not have saved it. It wastes a little bit of their time, but this is rare enough that I don't feel so bad about it.
  • I reject almost any MIME attachment that could be Windows malware. Even .zip files now. I politely ask them to arrange with me another way to send it. (Sending binaries through email isn't such a good idea anyway; it's indirect, and base64 bloats files by a third.)

richdawe:

mailman is the wrong layer to solve that. SMTP servers (Postfix, sendmail, qmail) can do some filtering based on the From: address. Mine is set up so that it rejects anything claiming to be from slamb.org unless sent from localhost or with SASL authentication. If gnu.org did the same, it would know the email from libtool@gnu.org is bogus.

And SPF, which you mentioned, could do the same across mailservers. I don't see a need for a mailing list-specific variant.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!