------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=677
Summary: callout sender verify defer remembered incorrectly as a
defer on sender verify
Product: Exim
Version: 4.63
Platform: Other
OS/Version: Linux
Status: NEW
Severity: bug
Priority: high
Component: ACLs
AssignedTo: nigel@???
ReportedBy: aprl@???
CC: exim-dev@???
My understanding is that the following three things are *different*:
verify = sender/callout=60s,defer_ok
verify = sender/defer_ok/callout=60s
verify = sender/defer_ok/callout=60s,defer_ok
After all, sender verification involves two steps:
1) Run the address through the routers
2) Do the callout
The different ways of specifying "defer_ok" indicate *which* step may be
deferred without leading to a failure.
If this understanding is correct, then I believe we've found a bug that leads
to temporary errors when in reality there is no error at all.
The bug we're observing is that Exim remembers the defer that happened on an
earlier verification in step 2 and later applies that as a cached value to a
subsequent verification at step 1.
In our RCPT ACL we have
verify = sender/callout=60s,defer_ok
A given address comes in and is verified against the routers (step 1) with no
problem. Then the callout is attempted but times out, leading to a callout
defer (step 2), but the "defer_ok" in the config allows our processing to
continue.
Later in the DATA ACL we have
verify = header_sender
[I realize now that this check is rather superfluous, to allow a valid From or
Reply-to at this point, if we already earlier forced a valid Sender. But even
though superfluous, Exim should handle it correctly (read on for description on
how it handles it incorrectly). This configuration is probably not too
uncommon, as someone reading 40.23 on different days in the manual might get
the idea one day to add the sender callout to their RCPT ACL, and another idea
get the idea to add the header_sender check to their DATA ACL.]
Now say that, among the Sender,From,Reply-to, Exim picks the same address (the
Sender) that was already used in the earlier verification. Exim now says "I
remember I got a deferral earlier" and observes "but there's no defer_ok option
specified here", and it promptly rejects with a temporary error.
And that's a bug! The earlier deferral happened on the callout (step 2 of the
verification process), not on the routing (step 1 of the process), and here
we're only asking for step 1 to be completed. So there should be no temporary
error at all. In fact, Exim should accept the message!
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
