Josip Rodin wrote:
> Hi,
>
> I want to do this:
>
> warn message = X-Exim-ACL-envelope-sender-verify: failed ($acl_verify_message)
> !verify = sender/callout=60s
>
> ...and that's all good, *unless* it defers, in which case I get no header :(
>
> Adding defer_ok makes the warn verb not run at all, so I get no header
> either.
>
> The docs for add_header (added in 4.61) don't seem to imply any difference
> in this regard.
>
> What exactly do I want to do here instead of the above? :)
>
> Perhaps something like:
>
> accept !verify = sender/callout=60s
> set acl_m7 = true
> ...
> warn message = X-Exim-ACL-envelope-sender-verify: failed ($acl_verify_message)
> condition acl_m7 = true
>
> ?
>
This example wroks, but is NOT a sender verification.
All you should need to do is make that substitution and adjust the header and
logging text:
===============================================================
# DATA_6: IF header address NOT syntactically correct THEN warn.
#
warn
!condition = ${if ge{$acl_m0}{2}}
!condition = ${if ge{$acl_m1}{2}}
!verify = header_syntax
set acl_m4 = ${eval:$acl_m4 + 1}
set acl_m8 = ${eval:$acl_m8 + 1}
add_header = X-Trash: RFC Violation - malformed headers
log_message = D6 $acl_m3 Trashmarked. RFC2822 syntax violation
================================================================
The other !conditions and set acl are side issues - left in place just to
illustrate that you can do 'other things'.
NOTE:
warn, deny, accept verbs have different rules for when they exit the case
structure.
So, too with !condition = condition =
Sequencing appropriate to each class of verb is very important!
Bill
