Date: 2004-06-02 19:23:00
Tags: email, unix
poor man's srs

I've been getting an incredible amount of junk bounce messages from email worms. These usually come from the worm sending a message with my email in the From field and a bogus address in the To field. The receiving mail server dutifully returns the message to me, as if I had sent it. I quickly got tired of manually inspecting and deleting these, so I set up a procmail rule to route them to a 'bounce' folder:

* ^Return-Path: (<>|MAILER-DAEMON@)

After setting this up I never really looked in that folder, so I would miss the possibility of receiving a legitimate bounce message (for example, if a message I actually sent was undeliverable for some reason). After reading about Sender Rewriting Scheme, I figured I could rig up something similar that would help (in a simple way, without implementing full SRS).

I changed my .muttrc such that the Envelope-From on outgoing mail is now

set sendmail="/usr/lib/sendmail"

I actually used a different word than foo above but I'm not going to mention it here. If an email worm were to pick up that address off this page, this whole scheme would be defeated. When setting this up you can use any word you want.

Then I changed my procmail rule to also check bounce messages addressed to my normal address:

* ^Return-Path: (<>|MAILER-DAEMON@)
* ^

In this way, only fake bounce messages that are addressed to my normal address (and are thus worm-generated) get shuffled off to the 'bounce' folder. Any bounce message that I legitimately receive as a result of a message I actually sent, will be addressed to instead, and will not be matched by the above rule. So, they will end up in my normal inbox as they should.

Initial tests show that this is working great. If for some reason a worm discovers the SRS-style Envelope-From address I am using and starts sending me fake bounce messages to that address, I can easily change it to something else.

Fighting spam and worm mail is taking up a nontrivial amount of my time these days, hopefully this will help reduce that time.

That's pretty slick.
[info]bovineone : Here are my anti-worm procmail rules...
I don't care about bounce messages, so I just do something simple like this:
    * ^Subject:.*(Undelivered Mail|failure notice|delivery failure|Delivery Status|Returned Mail|undeliverable|mail delivery fail)

To block those annoying auto-responders that tell you that you've supposedly sent them a virus, I use a rule like this:
    * ^Subject:.*(viruses detected|Virus Alert|Bug Notice|Infected Object|Virus Found|detected a virus|detected virus|virus was detected|virus detected)

And finally, I use clamav to filter out the messages with various worm attachments, instead of trying to manually cook up custom procmail rules for every new worm that comes along. If you install the clamav "freshclam" daemon, it'll automatically download new virus signatures from their central server.
    * Content-type.*multi
    * ? ( clamdscan --mbox --quiet - ; test "$?" -eq 1 )
[info]ghewgill : Re: Here are my anti-worm procmail rules...
Cool, I hadn't thought about using clamav because the worms aren't actually harmful to my FreeBSD system, but filtering them is nice. I just set that up and it works great.

I've found that checking the Return-Path (which is the Envelope-From) is more reliable than checking keywords in the subject. Procmail also has a ^FROM_MAILER magic search that should catch bounce messages too but I haven't tried it.
[info]bovineone : Re: Here are my anti-worm procmail rules...
^FROM_MAILER might be a little too agressive in some cases, since it will even match people who have email addresses of "" (see bug 3544).

clamav seems to be less CPU intensive than spamassassin, so you might want to ensure that you're running clamdscan before spamc if you're wanting to improve your mail throughput.
I started setting this up, but couldn't immediately figure out how to make qmail happy about Then I realized I didn't need to... all the crap email I've been getting isn't spoofing as it's from; it's using This means that the bounce message bounces and the email I'm getting is actually to So, I just added the following to procmail:

* ^Return-Path: (<>|MAILER-DAEMON@)
* ^

Ah right, I've got qmail set up to direct any unknown address to my account, except for mydoom's 47 addresses which go straight to the bit bucket.

Another way to write the procmail rule might be something like:

* !^

That should direct anything except bounces with your magic word to the badbounce/ folder.

I ended up with

* ^

Seems to be doing the trick well enough.
Greg Hewgill <>