Wrong MX record selected? - SendMail

In article <v4-dnW-0T9SfJg_bnZ2dnUVZ_hCdnZ2d@whidbeytel.com> Ken Wright
<ken@cncware.com> writes:
>I have two mail servers (A & B) within the same domain independently
>sending mail to a particular domain that dns returns 3 mx records for
>(10,20,30).
>
>Server (A) - Sendmail 8.13.8/8.12.8 - Redhat 9.0
>Server (B) - Sendmail 8.13.8/8.13.8 - Redhat EL5
>
>Server (A) always chooses the lowest value (highest preference) mx
>record to deliver to as would be expected.
>
>Server (B) seemingly randomly chooses between all 3. Often, due to
>external reasons beyond control, the lowest preference mx server (30) is
>actually unavailable so the mail becomes deferred. This is odd as I
>would expect sendmail to then attempt the other two servers, which makes
>me believe it actually worked correctly and ended up at the lowest
>preferred server at the end of the sorted list. Or is only selecting the
>first mx record returned by dns (which is random).

Of course sendmail will try the MXen in preference order. However
delivery based on MX records can be overridden by e.g. mailertable or
custom .mc/.cf rules. And of course there can be network connectivity
issues that make the higher preference MXen reachable from one server
but not from the other.

>Of special note is that when exercising dig on both machines, Server (A)
>will always display the mx records in sorted order, where Server (B)
>displays them in the random order in which they are provided by dns.
>Maybe this is significant, maybe not.

It's not significant. However "the server" or "dig" don't display them
in any particular order, they are displayed in the order they were
received from whatever DNS server was queried - so clearly the two
servers are configured to use different DNS servers. The latter *could*
be significant if one of those DNS servers isn't functioning correctly,
but if dig on both servers always shows all MXen, that's probably not
the issue.

>Would appreciate either some advice in methods to debug this unusual
>behavior or some known information about it?

First step would be to watch the processing of a message on the
"problematic" server with some debugging enabled. The below will show a)
the results of the DNS lookups done by sendmail, b) the cycling through
the MXen (if any), and c) the SMTP dialogue(s) at delivery (attempts)
(if any). As root:

date | sendmail -Am -d8.8 -v user@particular.domain

--Per Hedeland
per@hedeland.org

Thanks much for the info. This was helpful to move forward although
still not resolved.

Ken

Per Hedeland wrote:
> In article <v4-dnW-0T9SfJg_bnZ2dnUVZ_hCdnZ2d@whidbeytel.com> Ken Wright
> <ken@cncware.com> writes:
>> I have two mail servers (A & B) within the same domain independently
>> sending mail to a particular domain that dns returns 3 mx records for
>> (10,20,30).
>>
>> Server (A) - Sendmail 8.13.8/8.12.8 - Redhat 9.0
>> Server (B) - Sendmail 8.13.8/8.13.8 - Redhat EL5
>>
>> Server (A) always chooses the lowest value (highest preference) mx
>> record to deliver to as would be expected.
>>
>> Server (B) seemingly randomly chooses between all 3. Often, due to
>> external reasons beyond control, the lowest preference mx server (30) is
>> actually unavailable so the mail becomes deferred. This is odd as I
>> would expect sendmail to then attempt the other two servers, which makes
>> me believe it actually worked correctly and ended up at the lowest
>> preferred server at the end of the sorted list. Or is only selecting the
>> first mx record returned by dns (which is random).
>
> Of course sendmail will try the MXen in preference order. However
> delivery based on MX records can be overridden by e.g. mailertable or
> custom .mc/.cf rules. And of course there can be network connectivity
> issues that make the higher preference MXen reachable from one server
> but not from the other.
>
>> Of special note is that when exercising dig on both machines, Server (A)
>> will always display the mx records in sorted order, where Server (B)
>> displays them in the random order in which they are provided by dns.
>> Maybe this is significant, maybe not.
>
> It's not significant. However "the server" or "dig" don't display them
> in any particular order, they are displayed in the order they were
> received from whatever DNS server was queried - so clearly the two
> servers are configured to use different DNS servers. The latter *could*
> be significant if one of those DNS servers isn't functioning correctly,
> but if dig on both servers always shows all MXen, that's probably not
> the issue.
>
>> Would appreciate either some advice in methods to debug this unusual
>> behavior or some known information about it?
>
> First step would be to watch the processing of a message on the
> "problematic" server with some debugging enabled. The below will show a)
> the results of the DNS lookups done by sendmail, b) the cycling through
> the MXen (if any), and c) the SMTP dialogue(s) at delivery (attempts)
> (if any). As root:
>
> date | sendmail -Am -d8.8 -v user@particular.domain
>
> --Per Hedeland
> per@hedeland.org