Joerg Pichel wrote:
> this gives an "OK". Further on the callout
> "warn verify = sender/callout
>
> failed but gives only a warning. The first "RCPT TO: <recipient-one>"
> gets "250 OK" but the sender is marked with "verification failed" in
> the sender verify cache.
>
> When the second "RCPT TO: <recipient-two>" arives the verification cache
> reads "sender verification failed" and therefore the
> "require verify = sender"
>
> gives "FAILED" and the "RCPT" is rejected with "550 sender verify failed".
>
>
> Any other ideas/solutions/patches?
>
>
Yes, you have found a problem. Note that it is not the "callout" cache
that is actually causing this, Exim has always kept a "sender verify
cache" in memory during the processing of a message. If you test the
same sender address more than once, and any of those tests cause a
failure (even if that failure will only result in a warning), the cache
will remember the failure and all future tests on the same sender
address _during that Exim process' lifetime_ will also report failure.
Whether this is actually a bug or not is debatable, and obviously will
be left up to Philip to decide. The only simple way to solve it would be
to not cache results of verifications that were only used to generate
warnings, but this will cause extra work for Exim when the same address
gets verified again later.
I can't think of any other good solution; the caching can't be done
based on which ACL rule caused the verification, because ACLs can be
completely dynamic (looked up from a database, or modified with
substitutions, etc.). I suppose Exim could maintain two cached "failure
states" for a sender address, one for a regular "verify" and one for a
"callout" verify, thereby working around the problem.
