Ian FREISLICH schrieb:
> Patrick Eisenacher wrote:
>
>>Clive McDowell schrieb:
>>
>>
>>>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
>>>
>
> P
>
>>>What do we have to change to defer a message if we cannot pick up a
>>>spam score?
>>
>>Hi Clive,
>>
>>you have to implement a tri-state logic, so you can differentiate
>>between ham, spam and a message that wasn't scanned due to SA outages.
>
>
> I think that a lot of confusion around this has been a result of
> just copying the slightly longer spam acl example from the
> documentation. This ACL is designed for using the spam condition
> side effects, not to make any immediate decision.
>
> I think that the second confusion arises because the following has
> been missed in the ACL documentation:
>
> "Except for the QUIT ACL, which does not affect the SMTP return
> code (see section 39.7 above), the result of running an ACL is
> either accept or deny, or, if some test cannot be completed (for
> example, if a database is down), defer. These results cause 2xx,
> 5xx, and 4xx return codes, respectively, to be used in the SMTP
> dialogue. A fourth return, error, occurs when there is an error
> such as invalid syntax in the ACL. This also causes a 4xx return
> code."
>
> Here's the bit of the content scanning docs relevant to this discussion:
>
> "The spam condition returns DEFER if there is any error while running
> the message through SpamAssassin."
>
> You can use this to achieve the desired effect with a much shorter
> acl set. All you need to do is set the required_hits to the score
> at which you want to reject the mail.
>
> deny message = This message rated as SPAM.
> log_message = SPAM message $spam_score
> condition = ${if <{$message_size}{SPAM_MAX_SIZE} {yes}{no}}
> spam = joespamtest
>
> The following log message was generated when I sent a test mail
> with spamd not running.
>
> 2005-11-09 07:07:05 1EZiAZ-000Jc8-W2 spam acl condition: warning - spamd connection to 127.0.0.1, port 783 failed: Connection refused
> 2005-11-09 07:07:05 1EZiAZ-000Jc8-W2 spam acl condition: all spamd servers failed
> 2005-11-09 07:07:05 1EZiAZ-000Jc8-W2 H=(ian) [192.168.0.24] F=<if@???> temporarily rejected after DATA
>
> If it gets past this ACL, the message was too big to be scanned,
> or it's score was below SpamAssassin::Conf::required_hits. You can
> use this data as the basis for further decisions.
Hi Ian,
thanks for pointing this out. I forgot to mention this. Of course this
is much more easy, but only works if you want to deny based on SA's
result. If you want to tag the mail for further processing, you have to
stick with the long version I posted, because defers in warn acl
statements pass the control flow to the next acl statement.
Cheers,
Patrick
