> > 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.
I'll jump in here since I asked a similar question yesterday (pay attention to the list Ronan!). The SA check is the last in the
list of acl data checks. All helo sanity, rbls, virus checks etc. take place first. We seem to have a strange problem with our
SA server between midnight and ~3.00am when it appears to stop responding to connection requests. We haven't got to the bottom
of what is happening on the SA server but on a general point (in our situation) it would be best to defer messages if the SA
server is down rather than passing them unchecked. Our current acl is -
warn message = X-Spam-Score: $spam_bar ($spam_score)\n\
X-Spam-Score-Int: $spam_score_int
condition = ${if <{$message_size}{80k}{1}{0}}
spam = nobody:true
What do we have to change to defer a message if we cannot pick up a spam score?
Thanks,
Clive McDowell
Information Services
The Queen's University of Belfast
