On Wed, Mar 06, 2002 at 10:33:42AM +0000, Philip Hazel wrote:
> On Tue, 5 Mar 2002, Ollie Cook wrote:
>
> > 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)
>
> It would be, but only in the case where there is one remote host. If
> there are several remote hosts, Exim will try them all when temporary
> errors are happening. Maybe the first one fails to connect, and the
> second one gives a temporary error.
Well hopefully all the lowest MXs would either all give 2xx, all 4xx or
all 5xx depending on the recipient addresses in question.
If Exim fails to connect to all hosts (or put another way, gets non-SMTP
errors while connecting to all the hosts), then that to my mind is a
different kind of error than getting 4xx errors from all the hosts.
(An example where this might happen is if your backup MX is in a different
physical location to your primary MXs and the primaries are unreachable
over the network from the backup)
> > 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.
>
> I think in this case, letting C keep the message is perhaps the safest
> course.
In the situation where the primaries are cut off from the network for a
sizeable length of time (hopefully this would never happen, but I do like to
plan for such occurances!), I would rather hold onto the messages myself on the
backup, rather than rely on other ISPs which might have a very short set of
retries before giving up.
I'm interested to know what you mean by it being "safest".
> > 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"?
>
> I'll think about it, but I have a gut feeling that there isn't a nice
> clean non-confusing way one can specify this. Consequently, I'd rather
> keep clear...
verify = recipient/callout=5s/callout_cannot_connect_ok ?
Thank you for thinking about it, though.
Ollie
--
Oliver Cook Systems Administrator, ClaraNET
ollie@??? 020 7903 3065
