Seth Dillingham wrote:
> I have the following in my acl_check_data:
>
> warn spam = nobody
> condition = ${if < {$message_size}{10K}}
> add_header = X-Spam_score: $spam_score\n\
> X-Spam_score_int: $spam_score_int\n\
> X-Spam_bar: $spam_bar\n\
> X-Spam_report: $spam_report
>
> # reject spam with high scores
> deny message = This message scored $spam_score points.
> spam = nobody:true
> condition = ${if < {$message_size}{10K}}
> condition = ${if > {$spam_score_int}{70}{1}{0}}
>
>
> This is working well enough, but I'd like to skip these tests under
> certain conditions:
>
> * if the sender is on the localhost
> * if the message wasn't originally sent with SMTP
> (I have scripts on the server which send mail to me
> by calling Exim directly)
That's inherent. 'normal' acl's only apply to an smtp 'session', which does not
occur when calling the binary. See also 'acl_not_smtp' for those.
> * if the sender is authenticated
>
We rely on a combination of 'negated' or exclusion conditions, then 'survivors
and/or 'inclusive' conditions for flexible steering that leaves a minimum to
chance, as in:
<the acl name>
# code_number (to find it fast with an editor) other comments
<the verb>
# one, none, or many 'exemption' conditions for early bail-out
!condition = <the localhost IP. Or a 'hostlist/!hostlist' for LAN>
!condition = authenticated
!condition = <arrival port, protocol in use ... yadda, yadda...>
.
.
!hosts =
# one, none, or many 'inclusive' conditions
condition =
hosts =
.
.
# followed by the actual test(s)
.
.
.
and use the acl's 'code number' in log_message and logwrites
for easier debugging.
> I'm a little fried after a solid week of trying to rebuild this
> system, and I can't seem to figure these out.
>
> If the answers are in the FAQ and I missed them, I'm sorry. I did look.
>
> Any suggestions?
>
General case above. Also keep in mind that match/bailout behaviour and overall
traversal is slighty different for deny-class verbs than for 'accept' and modify
accordingly, especially w/r associated smtp-time messages and log entries.
FWIW, we often set a flag in an acl_c or acl_m, from the Exim variable, test
that variable instead. Can make editing global changes safer.
That may be a tad less efficient than looking at Exim's own variables, but it
also has the advantage that an acl_m - or an acl_c copied INTO an acl_m -
survives the end of the smtp session and lives on in the queue until last copy
has been delivered.
Useful for steering router/transports long after the Exim variables have gone
away with the smtp session close.
YMMV,
Bill
