Richard Seabrook wrote:
> I'm really looking to reject spam at SMTP time, using
> 'smtpd_proxy_filter' (before-queue) rather than the usual
> 'content_filter' (after-queue).

I'd *strongly* recommend not doing it like that; dspam can take more than a few
seconds to scan (and longer under load), so you are risking timing out the
remote SMTP session (which will mean you will just get the same message sent
again and again).  You won't buy yourself much in the way of preventing spam
entering the system in the first place, and you can just dump the quarantine on
a daily basis unless someone complains that they are missing a message.

In addition, dspam is not intended to be used as a input filter; its strength
lies in the asynchronous training (false positives would never get delivered and
you _will_ lose legit mail).  If you want to use a global filter, SpamAssassin
is the way to go, since it is based on fixed (well, updated) heuristics, rather
than statistical training (though it has that too).

> It's for an anti-spam relay, with no local users and a global group.
> After it's done, it'll hand mail off to our final destination mail servers.

No reason you can't do this with a content-filter style appliance (using a
global group).  This is basically what I am doing (though I am using individual
training).

John

Reply via email to