Re: [exim] spam defer

On Tue, 8 Nov 2005, Ronan wrote:

> If SA cant be accessed at during the sata ACL check, can i defer the
> message

If you want to! There's the slight benefit that some hit-and-run
spammers won't bother to retry.

However, if this situation is arising frequently, then (if the mail
server is otherwise reasonably dimensioned) could it be that you're
allowing too many spams to get to that stage? Spamassassin is, in our
experience, the largest single consumer of resources in the processing
of a message which is finally accepted - if you can apply rules which
reject a sub-set of spams at an earlier stage, especially at the RCPT
phase before they get as far as sending DATA, then it can make very
significant savings on the mail server resource usage.

> or simply queue it until my spamd server is ready to accept it?

Once you've accepted and queued a mail for further processing, you can
no longer safely reject it (see "collateral bounces").

As a matter of policy, we don't care for the idea of dropping mails
automatically into a black hole: we want to either positively accept,
or positively reject.

> Should i be using the same approach with anti virus solution as
> well?

Our mailer does not pass anything without a satisfactory anti-virus
check - neither inbound nor outbound. If we had users who were doing
virus research, of course, we'd need to find a different policy!

Beware, though, that passing the anti-virus check does NOT guarantee
that mail is clean. We've had several instances where a new virus
started arriving several hours before either of the virus checkers[1]
received their template updates for that virus. They were only kept
out by virtue of the check on filename extensions (which itself is
irksome, and not really correct in principle, but effective enough in
practice), plus a check for a signature of MS executable content.

regards

[1] This problem is going to exist with any virus checker, so I'm
not intending any criticism of the ones that we use.