Steve wrote, at 06/23/2009 04:21 AM:
> Silly question. Currently I have Postfix using Spamassassin as a content
> filter thus;
>
> smtp inet n - - - 10 smtpd
> -o content_filter=spamassassin
> ...
> spamassassin unix - n n - - pipe
> user=spamd argv=/usr/bin/spamc -f -e
> /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>
> It's nice and dandy but could this be changed to filter and reject at an
> SMTP level rather than after accepting the message?
I use spampd (Spam Proxy Daemon) to do this:
http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm
It doesn't look like it's being developed anymore, but I continue to use
it with latest versions of Postfix and SpamAssassin.
I believe you can also use amavisd-new as a before-queue content filter,
but the documentation strongly discouraged it the last time I looked.
> I'm only running a small server with a few mails per minute - so it's
> not going to kill it.
Then you're a good candidate. I doubt if it scales well to large volume
sites.
> I can block at SMTP level with Postfix native Body Filter.
Actually, I use a header_checks rule:
/X-Spam-Level: \*{5,}/ REJECT
It works very well, and I can adjust the number in relation to the
default SpamAssassin required_score. I highly recommend leaving
required_score at the default of 5 and only adjusting individual rules
as needed. The collective wisdom of the SpamAssassin devs has served me
well, for the most part.
> The reason I ask is this bounce;
>
> ...
> <[email protected]>: host mail.varna.net[217.145.80.1] said: 550 5.7.1
> Blocked by
> SpamAssassin (in reply to end of DATA command)
> ...
Whether you use a milter or a before-queue content filter to reject
during SMTP, be sure you have implemented as many low-cost measures
beforehand as possible. Processing by SpamAssassin always represents a
relatively significant resource hit, so try to limit it to the few
messages that survive the gauntlet of other, cheaper, techniques.
