MX question

[Kevin Darcy]

Barry Margolin wrote:

> 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).

The way I read RFC 2821, it is not legal to "skip" MX targets like that; I read it as
requiring a delivery attempt to each MX target at a given preference level before
proceeding to the next preference level, although it does allow skipping of
"alternative" addresses (i.e. when a given MX target is multihomed) as well as an
overall limitation on how many delivery attempts to make before giving up.

> >> 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.

See also, "prostitution". See also, "lowest common denominator".

> 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.

I've never interpreted the Interoperability Principle as extending to the point of
"I am compelled to munge my configuration in various perverse ways to accommodate
your brokenness".


- Kevin