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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
