Re: [exim] adding a header to a message in an ACL, even whe…

Josip Rodin wrote:
> On Mon, Nov 13, 2006 at 01:46:37AM +0800, W B Hacker wrote:
>> You've missed the *point*. The 'warn' verb *doesn't* 'get skipped'.
>>
>> It does precisely what it was programmed to do.
>
> I was using the term 'skipped' because that is precisely what gets logged by
> Exim, for example:

Ah, yes... Exim 'log-speak'.

>
> 2006-11-13 08:32:13 1GjWIe-0006bK-LW H=unicorn.laczpol.net.pl
> [193.24.220.34]:2930 I=[192.168.54.235]:25 Warning: ACL "warn" statement
> skipped: condition test deferred: all attempts to verify a sender in a header
> line deferred
>

If it had been truly 'skipped' the logger would not have known anything about it
though - least of all that it had tried to make a callout and 'all attempts..'
were deferred. 'condition could not be evaluated in the time permitted' is what
happened. It DID try.

'Skipped' would have been 'too tired, ain't trying no more callouts today'

;-)


>> Fixed timeout or defer, *neither* will satisfy a conditional if they
>> ultimately fail - regardless of why they failed:
>
> Okay. I wanted to use 'accept', but Andreas told me that won't work at all.
> Is there a verb that would do what I want?
>

Not just the 'verb' that matters as much as how hard-edged you want to be about
the condition.

Some percentage of sender verify callouts *will* fail, and on very legitimate
servers. Think major ISP's with separate 'pools', specialty Mailing list
servers, the paranoid with long banner delays, many 'half-broken' DNS.

My advice is twofold:

1) insure that *your* server supports a response to the sender verify of
*others*. That wins YOU credibility and helps traffic flow smoothly.

2) Rather than penalize on the sometimes unreliable 'fail' of a sender verify,
instead use the result of a sender verify *success* as 'positive' QC points.
Ex: Perhaps to offset a negative point for HELO mismatch, which are hard to
avoid when an otherwise-legit server HELO's as:

small-dog-named-lunch.kowloon-tong.hk1.domain.tld.

FWIW, we still do 1) - answer the verification probes,

- but no longer bother with 2) - make the callouts ourselves.

Too many unpredictable servers in our specific environment.

YMMV dramatically, as this depends on what servers *your* users correspond with.

Bill