MX question

[Barry Margolin]

In article <a9hv02$c0c at pub3.rc.vix.com>,
Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
>
>Barry Margolin wrote:
>> Some systems have a limit on the number of equal-preference MX records that
>> they'll try.
>
>Those systems are broken, IMO, if they can't deal with moderate quantities of
>equal-preference MX records (6 in this case). Is Microsoft -- a mail server
>software vendor, I'll note -- setting a good example by structuring their
>MX records to accommodate brokenness?

I think 3-4 may be a common limit.  If you fail to connect to that many, it
almost always means that a single failure is affecting all of them
(e.g. they're a server pool on the same LAN, whose connection is down), so
there's little point in trying more.  Instead, it's better to fail over to
the next preference level (which are likely to be off-site backups).

>> Also, if you have *lots* of mail servers, you risk overflowing the 500-byte
>> limit of UDP DNS replies if they're all separate MX records.  If you
>> cluster them, the A records go into the Additional Records section, and an
>> overflow there doesn't require a TCP retry.
>
>Again, we're only talking about 6 targets here. That's nowhere near overflowing
>the UDP limit.

I was talking about the general reason not to have separate MX records for
every address.

Most of the problems I described affected AOL years ago, when they tried to
use something like 30 MX records.

>But, even in the hypothetical case where UDP overflow occurs, what's so bad about
>a TCP retry? It seems to me that much if not most of the time a simple TCP retry
>will actually use *less* resources overall than having to do "x" UDP queries for
>all of the A records missing from the Additional Section.

I guess you don't remember that BIND 4 recursive servers won't do TCP
retries.

Most organizations can probably ignore this problem; their mail
architecture doesn't tickle the problem, and even if it does they can
probably live without the mail from those few sites that have problems at
the sending end.  But companies like AOL, Microsoft, and Yahoo can have
their reputation affected if places can't send them mail, even if it's
because the sending site is running obsolete software.  They need to be as
accomodating as possible.

I remember once, about 5 years ago, some of our customers were having
trouble sending mail to AOL, and it was because their SMTP greeting message
was one really long line (they had added some text to it as a warning to
spammers).  It was within the legal limit that the SMTP RFC specified, but
a common mailer (from either Lotus or Microsoft, I think).  AOL didn't use
the fact that they complied with the standard and the senders didn't as an
excuse to ignore the problem; as soon as they were notified of it, they
changed their greeting message (they split it across multiple lines).

This is all part of the "be conservative in what you send" half of the
Interoperability Principle.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.