Re: [Exim] lowest MX record - strange situation

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: dimitry
Cc: exim-users
Asunto: Re: [Exim] lowest MX record - strange situation
On Wed, 12 Jul 2000, Dmitry Alyabyev wrote:

> >> >> 123.com preference = 30, mail exchanger = relay2.mydomain.com
> >> >> 123.com preference = 20, mail exchanger = mail.123.com
> >> >> 123.com preference = 10, mail exchanger = mail.123.com
> >> >> 123.com preference = 20, mail exchanger = relay.mydomain.com


> But I think if all lowest relays are down and the Exim-host sees
> itself as "first-alive-relay" it have to try deliver to lowest MX
> relays time to time by the MX-list.


No. It must NOT deliver to any relay whose MX value is the same or
greater than its own. Thus, if the Exim-host is relay.mydomain.com, the
only choice it has is

123.com preference = 10, mail exchanger = mail.123.com

This is what RFC 974 says:

      If the domain name LOCAL is listed as an MX RR, all MX RRs with a 
      preference value greater than or equal to that of LOCAL's must be
      discarded.    


Exim is a bit cleverer than that; it not only checks the domain name for
the local host, it also checks the IP address for any local interface.

> >That is silly. Why try mail.123.com twice?
>
> Please see above.


It would have to be a very short peak to make sense, and I personally
don't think it does.

> It's not the usual but it's not wrong configuration, isn't it ?


I can't find (yet :-) any RFC text forbidding it, but IMHO it doesn't
make sense.

> There is the essential difference with my point of view.
> Could you explain me why Exim will try to deliver the message by other
> way instead to try deliver it to died relays, stops to do it after
> retry-timeout and send error message to sender ?


We have a misunderstanding here. I don't think Exim is trying to behave
differently to what you expect, other than skipping hosts it has already
tried (but as explained above, if the current host is relay.mydomain.com
it has only one host to try anyway). [Unless there's a bug, of course.]

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.