Re: [exim] "Bad words" filtering

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] "Bad words" filtering
Richard Salts wrote:
> We're currently using a custom written smtp server that filters "bad words".
> I'm thinking that I'd much prefer using a generic MTA such as exim or
> postfix, my personal preference being exim because I think it's much more
> flexible. I'm just wondering what people think would be the best way of
> achieving this.
>
> I'd prefer to have the rejection at smtp time rather than generate a bounce
> and I was thinking a few possible solutions might work.
>
> a. acl_smtp_mime with mime_regex containing the "bad words" for things with
> the appropriate $mime_content_type. The disadvantage of this being that it
> only captures the first 32K and its CPU-intensive nature.
>


It might not even need the first 32K... You could do 'both' a) and b)

> b. Add the badwords into spamassassin rules and search $spam_report
> for matches on these rules. It is a bit of an abuse of spamassasin but it
> should work.


Not an abuse at all.

SpamAssassin is quite comfortable with the addition of custom tests. You'll just
need to keep an eye on what happens when you update it.

CAVEAT: A *great deal* of what SpamAssassin is default-capable of include tests
that Exim can make 'sooner and cheaper' - including, but not limited to,
essentially any form of off-box DNS or RBL checking, and White as well as Black
lists.

PLUS:

IF you have Exim perform those tests, then strip SA of running them. PLUS strip
SA of any valid but 'low yield' tests, AND those that are (also)
time/resource-hogs and/or might false too often in a shared-server environment
(SPAM BAYES?), you can have an Exim+SA combination that runs faster, lighter,
and is more attuned to the specific needs of your environment.

>
> c. Pipe the message through a filter transport. This is obviously my least
> preferred option as it will generate bounce messages after mail is accepted
> or effectively blackhole the message if the bounce is supressed.
>


Far better to do as much as possible *during* the smtp session.

Bill