On Tue, 2009-06-23 at 08:51 -0400, Jorey Bump wrote:
> 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.
It looks really interesting. I like this "spampd ... acts...as a
"transparent" proxy server. That is, it never actually takes
responsibility for the mail at any point. Instead, the origination and
destination mail servers speak directly to each other. If a failure
occurs within spampd (or SpamAssassin) during a transaction, then the
mail servers will disconnect and the sending server is still responsible
for retrying the message for as long as it is configured to do so"
>
> 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 don't like amavis-new. I spent a year at Barracuda and they use it in
their 'spam firewall'. It's one of the most troublesome parts - but that
could come down to their front end MTA and how it works with it.
>
> > 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 don't think it would. Not unless you use some serious hardware and run
lots of processes. That said, the cost of hardware is now relatively low
and it's looking more attractive.
>
> > I can block at SMTP level with Postfix native Body Filter.
>
> Actually, I use a header_checks rule:
>
> /X-Spam-Level: \*{5,}/ REJECT
I looked at this myself and asked 'hang on, what if I put a header
filter in for X-Spam-Level'. I assumed (and that is all it was) that it
was not fed into the content filter until *after* Postfix had accepted
the whole message. ? ? If that is the case and it tried to bounce this
I'm not entirely sure of the carnage this would create. I'll have to
play with it as this looks like to easy and obvious to miss!
>
> 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;
> >
> > ...
> > <ia...@varna.net>: 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.
>
>
