After those recent freaking virii around , I'm trying to find a way to block them...
What's the best way to do this?
I want to avoid sending unnecessary bounces (specially because I'm the postmaster for a domain that has about 1300 users and lots of virii bounces dailly , which are almost driving me mad, so I want to avoid unnecessary pain to other domain admins) ...
It's much better to reject a virus (or other likely-to-have-forged-info message) during the initial SMTP transaction (when you know you're connected with the real sender) rather than bounce it (when you have to rely on the headers).
For these high-volume virii, I've been using the body_checks feature of postfix for a quick-and-dirty (but effective) block.
In /etc/postfix/main.cf body_checks = pcre:/etc/postfix/body_checks
In /etc/postfix/body_checks I then stick things like: /name="\w+.pIf"/ REJECT /ZGUuDQ0KJAAAAAAAAAB\+i6hSOurGATrqxgE66sYBQfbKATvqxgG\59sgBLerGAdL1zAEA6sYBWPXV/ REJECT
The former (change pIf to pif) might hit an innocent email (like this one if I'd said "pif" in that line) but I can't think of any legitimate reason why someone would need that string.
The latter is one line from the recent worm payload, which is the same regardless of the randomization of attachment names and types.
It's theoretically possible that a 'good' attachment might include the same line of encoding somewhere, but very very unlikely.
Doing this will put more load on your server (it needs to actually scan message bodies now) but seems to work well at keeping known nasties out without contributing to the 'bounce problem'. I should use better pattern matches to just stop any of a variety of annoying attachment types, but haven't had the time to design and test them yet.
I have a test system running with integrated spamassassin, but I'll probably still utilize something like this because it can reject virii earlier in the process.
