------- 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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [email protected] 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
