On Fri, 5 Jan 2007, Daniel Tiefnig wrote:
> Hmm, it would solve that special case with greylisting, yes. But I think
> there may still be a more general problem, with exim generating a
> permanent error due to the (long-lasting) 4xx reply from the primary MX,
> without trying the (so called "working") secondary MX if there is one.
Of course I may be mis-remembering, and of course the code may not do
what it is supposed to, but I don't see why Exim would not try the
second MX. Hmm, with more thought, maybe there is a problem...
When a recipient gets a 4xx response, Exim sets up a *recipient* retry
rather than a host retry, and this is a *routing defer*. So the
recipient isn't even routed until the retry time arrives (in queue runs).
<goes away and reads code>
However, when the retry time does arrive, it will do the routing and
then try the hosts according to the host retry times, so I'm not sure if
this is really a problem at all.
The only way to be sure of Exim's behaviour is to set up a test scenario
and run it with debugging to see exactly what is going on. After we have
4.66 released, I may think about doing this so that I can demonstrate
how it works.
> I'm not sure though, whether this really is a bug, or one may call it a
> feature.
Whatever it does, I'm quite prepared to call it a feature! I don't like
messing around in that code any more.
> Does it make sense to deliver to the 2nd MX if we know the 1st MX does
> not accept mail for the address?
You can certainly argue that it does not, because in a classical
configuration, the 2nd MX is just going to forward the message to the
first.
> Or better: do we know enough about the setup of the target MX system
> to make a reasonable decision? I don't think so.
Agreed.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
