- Previous message: mouss: "Re: Hiding internal IP address in bounce messages..."
- Maybe in reply to: Justin Piszcz: "header_checks question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Noel Jones (no email)
Date: Wed Sep 12 2007 - 17:39:03 EDT
At 03:57 PM 9/12/2007, Justin Piszcz wrote:
>On Wed, 12 Sep 2007, Noel Jones wrote:
>
>>At 03:36 PM 9/12/2007, Justin Piszcz wrote:
>>
>>>Agree-- however, there are some nice regexp maps out their
>>>compiled for anti-spam purposes
>>
>>Such as?
>
>A couple:
>
>#
># Malware Block List - http://www.malware.com.br
># List for Postfix MTA
># Generated at: 20070709224449 UTC
>#
># http://www.malware.com.br/cgi/submit?action=list_postfix
>
># t29.dk postfix header_checks regexp file, rev. 28c (2006-12-08)
>#
>#
># Maintained by Niels Callesøe (dk pfy) <>
># No patterns have been added since dec 2004. It appears AV vendors
>have either gotten the message
># or these filters are simply enough. However, if you do see any
>"virus warnings" that slip
># through, please send submissions to: . If you
>do not see your submission added,
># it is probably because it would already have been caught by the
>expressions below.
>#
># Usage (main.cf):
># header_checks = regexp:/etc/postfix/header_checks
>#
># To reduce clutter in this file, all discussion, attribtions etc have been
># moved to http://www.t29.dk/header_check_notes.php
The T29 header checks look reasonable, but performance could be
improved by wrapping the whole thing in IF..ENDIF such as:
IF /^Subject: /
... all the rules ...
ENDIF
This isn't so critical in header_checks since most messages have only
a few dozen headers, but still...
The MBL list is a little more troubling. As written, each of the
1200+ tests will be performed on every single line of every mail
(well, the first 50k of every mail segment). This will be a real CPU
hog. This could be speeded up greatly by using:
IF /(ftp|http):/
... all the rules ...
ENDIF
so that only lines containing ftp: or http: would get the full treatment.
Be cautious using DISCARD. If there is a false positive you'll never
know about it, and you can't undo it.
I would be especially cautious using DISCARD in a rule set that has
been known to have the occasional false positive. And there's no
argument not to REJECT mail that comes directly from a zombie, since
there will never be a bounce generated.
I've been using the MBL clamav signatures for several weeks now and
have yet to get the first real hit from them (although I did get a
load of FP's one day - fortunately I was able to release them from
quarantine).
-- Noel Jones
|
|
|