Keith Brazington schrieb:
> On Tue, 22 Feb 2005 17:47:11 +0100, exim-users@???
> <exim-users@???> wrote:
>
>
>>To avoid this and have the mails deferred as long as one of the demons
>>is down, I implemented the kind of tri-state logic that was given before
>>on the list for sender verification (ok/bad/unknown). Since this is not
>>the most beautiful solution in my eyes, I wonder whether there is
>>another way to achieve the same goal. How do others on the list tackle
>>this situation?
>
>
> Using Unix sockets to connect to SpamAssassin gives me the required
> defer if SpamAssassin stops running. Exim debug output shown below
>
> processing "warn"
> check spam = exim:true
> trying server 127.0.0.1, port 783
Are you sure, you're using unix sockets? This looks like a tcp socket to
me. But I'm not that familiar with unix socket, so I could be wrong. I'm
using tcp sockets myself. And my log entries look slightly different
from yours. See below.
> LOG: MAIN PANIC
> spam acl condition: warning - spamd connection to 127.0.0.1, port
> 783 failed: Connection refused
> LOG: MAIN PANIC
> spam acl condition: all spamd servers failed
> warn: condition test deferred
spam acl condition: warning - spamd connection to 127.0.0.1, port 783
failed: Connection refused
spam acl condition: all spamd servers failed
Warning: ACL "warn" statement skipped: condition test deferred:
<= external@??? H=external.test-extern.org [192.168.2.100]
P=esmtp S=1167 id=421CB497.6060305@??? T="test internal user"
=> internal@??? R=smart_host T=smtp_incoming S=1198
H=internal.test-intern.org [192.168.2.98] C="250 OK id=1D3zk4-000H8p-MM"
I removed the time and message id entries for better readability.
As you see, my mail is accepted, even though spamd is down. The warn
statement with the deferred spam condition gets skipped, which is in
perfect conformance with the specification.
Are you sure, you defer because of the deferred warn statement? If so,
how do you do that? To achieve the behaviour I want, I have to
workaround like this:
warn
condition = ${if > {$message_size}{MESSAGE_SIZE_SPAM_MAX} \
{false}{true}}
set acl_m9 = 1
spam = nobody:true
set acl_m9 = 0
set acl_m3 = ${eval:$acl_m3 + $spam_score_int}
defer
condition = $acl_m9
With the malware condition, things get a bit more tricky and the
tri-state logic comes into the picture. If I could make "malware" return
true every time, just like "spam" can do, I could use the more simple
1/0 check of above. Otherwise I'll have to stay with the tri-state logic:
warn
condition = ${if > {$message_size}{MESSAGE_SIZE_VIRUS_MAX} \
{false}{true}}
set acl_m9 = 1
demime = *
malware = *
set acl_m0 = 1
set acl_m9 = 0
warn
condition = ${if > {$message_size}{MESSAGE_SIZE_VIRUS_MAX} \
{false}{true}}
!malware = *
set acl_m9 = 0
defer
condition = $acl_m9
Patrick
