Stan Hoeppner:
> On 9/13/2012 9:59 PM, Chris Adams wrote:
> > I'm configuring Postfix with SpamAssassin, using Spampd as a
> > before-queue filter. I put "/^X-Spam-Flag: YES/ REJECT Spam detected"
> > in /etc/postfix/header_checks, and that works (spam is rejected during
> > SMTP as desired).
> >
> > However, it would be nice to _also_ keep a copy of the rejected messages
> > somewhere for later analysis. Either deliver them to a special local
> > user, hold in the queue, or whatever else is convenient. Is there an
> > easy way to do this?
>
> Before queue filtering is more expensive that post queue filtering.
That depends. The amount of memory/number of CPU cycles/etc to
examine a message is the same.
The difference is:
- With post-queue filters you have complete control over the number
of filters that can run at the same time, and you can use larger
time limits.
- With before-queue filters, the number of running filters can be
the same as the number of inbound SMTP sessions, and you have to
be sure that filters finish quickly. You can reduce the number
of running filters with "smtpd_proxy_options=speed_adjust", so
that Postfix receives the entire message before invoking the
filter; people have reported reductions in the number of filter
processes of 40%.
But this matters only if you really want to give a REJECT response
to the remote SMTP client.
Wietse
> It
> makes more sense in this case to simply accept all mail and forget about
> REJECTing what SA marks as spam. Run a post queue filter and save all
> spam to a spam folder with a procmail, sieve, etc, script.
>
> The only time a human will see the REJECT is on a false positive.
> Spammers don't look at rejects. So why bother telling a spamming MTA
> you rejected the message when you actually accepted it? This simply
> adds unnecessary expense to your mail transactions with zero benefit to you.
>
> --
> Stan
>
>
