|Who's purpose is to catch and reject bogus antivirus warnings using postfix. You can find the main file here:|
|The antiantivirus configuration file can be considered public domain, and distribution is unlimited.|
|REJECT vs. DISCARD|
|For a thorough examination of this topic, I recommend reading the excellent discussion on the Linux-Elitists mailing list of whether one should use REJECT or DISCARD against bogus virus warnings and other nasties.|
|I personally strongly favor the REJECT approach, as I am a firm believer in not breaking SMTP standards. However, there's some good points made on either side of the Linux-Elitists discussion, and it is highly recommended reading. Of particular note is the following, quoting Karsten M. Self (with permission):|
|[on why REJECT is the Right Thing to do]|
- If the header data was forged, you've just shoved the problem one hop upstream. Closer to the source. - If that hop is in fact the _origin_ (direct transmission from infected host), you've Done The Right Thing, and that host sucks back its spew. - If that hop is a smarthost, and it's handling delivery at receipt, it turns around and tells the originating SMTP server "no go". Which is Doing The Right Thing. - If your reject was based on a misclassification of the content or condition, the person who's been unfairly stuffed by you: 1. Knows their message wasn't successfully sent. 2. Has a chance of identifying the reason why. - In the chance you're dealing with a not-quite-smart host that turns around and generates a nondelivery notice to a spoofed party: 1. It's Not Your Fault. 2. The not-quite-smart host is misconfigured. 3. The host can be identified as spewware on an appropriate DNSBL list, allowing Right Thinking People Everywhere (RTPE) to shitcan all spew originating from it. The host's admins might care to address that situation if it bothers them. It's a bit like the two approaches to warning messages in programming: - You can get rid of them by disabling warnings. - You can get rid of them by _enabling_ strict error checking, and fixing the bugs (or avoiding the bug-inducing conditions). I don't know about you & Mr. Waugh, but I strongly favor the second approach. Frequently, n00bs complain that there's too much pain involved in rooting out the errors. The proper response is that there's more pain involved in not doing so.
|I might add, that in the case of the bogus virus warnings (that the t29 header_checks file deals with), the chance of a misconfigured smarthost bouncing to an innocent third party is much less than with direct virusses, because in most cases anti-virus "bounces" have a From: address of [email protected], [email protected], [email protected] or somesuch at the site generating the bogus warning. This means that even if a bounce is generated, it will go to the administrator of the host generating the bogus bounce, not to a third party.|
|For example, look at this bounce message from a misconfigured MS Exchange/ScanMail setup:|
Return-Path: <[email protected]> From: System Attendant <[email protected]> To: "[redacted]" [redacted] Subject: ScanMail Message: To Sender, virus found and action taken. Date: Sat, 24 Apr 2004 00:48:59 +0200 X-Mailer: Internet Mail Service (5.5.2656.59)
You'll notice that this message is sent From: "System Attendant <[email protected]>", and has a similar Return-Path:, so had this message been caught by our ruleset and rejected with a 550 error message, that's where the bounce goes. And this is a good thing as hopefully, it will make them notice that their software is spewing unnecessary garbage.
In summary: DISCARD known virusses if you must, but virus warnings should be REJECTed.
|Most of the t29 header_checks file has been grabbed from somewhere else, formatted for use with postfix and added to this file. By far the biggest source has been Tim Jacksons similar rulesets, made for Spamassassin, which you can find here:|
Tim's Spamassassin file is more comprehensive than our checks, and also matches on a slew of body patterns. Some of these could be implemented with postfix (using body_checks) as well, but I am hesitant because of overhead and other issues. If you want the whole shebang, and have the CPU cycles to spare, consider his ruleset over this one.
Other contributors, from various sources, in no particular order:
I'll most certainly have missed something, so if you feel you should be listed here, please let me know.
Also, feel free to send any comments or gripes about this document to me.
If you're reading this, most likely you're already running postfix. However, have you noticed that version 2.1 was very recently released? If you're still running 1.x, or even 2.0.x, now is a good time to upgrade.
|If you are running postfix, but you're not an expert yet -- or you just haven't experimented much with filtering -- you'll definately want to have a look at Jim Seymour's guide to postfix anti-UCE:|
|Also, if you're using our header_checks file, but find that it doesn't catch enough, you may want to try Keld Simonsen's file, although if I were you, I'd change the DISCARDs to REJECTs. Of course, the other option is to simply submit your misses to me so I can make this file better. If you're wondering why I'm not importing his checks, it's because he has released them under the GPL (otherwise a good license for many OS things) which would require me to GPL this document too... and I find that much too restrictive for a plain configuration file.|
If you want to submit samples of virus-warnings that managed to slip past our rules, please send them with full headers to: |
Created on 2004-04-25, last updated on 2008-05-05. Niels Callesøe
valid html 4.01 Strict / CSS