Sorry to follow up my own post, but I have another question regarding callouts.
Is it possible to distinguish between the two cases:
1) Called forward and got a temporary error from remote host
2) Called forward and couldn't connect to remote host (or other
non SMTP error condition)
Perhaps it will make more sense if I explain the scenario.
Backup MX 'A' wants to check local parts on domains which it relays mail for
(trying to avoid the use of Exim 3 terminology!), because spammers have got
wise to the fact that often backup MXs have different policy controls than
primaries, so that it doesn't have to deal with generating lots of bounces, so
we would set in the appropriate ACL:
verify = recipient/callout=5s
Now, if the call forward yields "451 quota exceeded", for example (as a result
of a :defer: on the lowest MX, 'B'), then Exim on 'A' will report back to
connecting host, 'C':
451-Callout verification failed:
451 451 <overquotauser@???> Storage quota exceeded.
So far, so good. But what if Exim can't connect forward to that host (network
problems, for example):
451 Could not complete recipient callout check
In such a case, what we would want is for Exim to accept the local parts, if it
can't check them, so that we don't have to rely on C holding onto the message
for an arbitrary length of time. Append /callout_defer_out to the verify
statement, you might think.
However, in this scenario, temporary errors from B (over quota etc.) are
allowed through as 'OK' by A and consequently C can send mail to those
recipients, and we've lost the benefit of doing the call forward at all,
because we still might have to generate the bounces.
Philip, might it be possible to define different behaviours for these two cases?
Or perhaps a more general framework, rather than just, "all defers are OK"?
Hopefully,
Ollie
--
Oliver Cook Systems Administrator, ClaraNET
ollie@??? 020 7903 3065
