Slightly OT - MX RR Santity Check requested...
Kevin P. Knox
bind-users at rc4systems.net
Thu Mar 29 02:25:09 UTC 2007
> When one is talking about MX records the lowest preference
> MX record is the one with the lowest value in the preference
> field.
The lowest preferred MX RR is that with the highest integer representing it.
More preferred MX hosts have lower integers.
... Kev
On Wednesday 28 March 2007 10:21 pm, Mark Andrews wrote:
> > Our LOWEST pref MX RR IS REACHABLE.
>
> When one is talking about MX records the lowest preference
> MX record is the one with the lowest value in the preference
> field. The lowest preference MX(s) are tried first. This
> is the only way to avoid confusion.
>
> "lowest preference" is most preferred.
> "higest preference" is least preferred.
>
> The lowest preference MX is not reachable.
>
> "pref" is ambigious.
>
> > It's the high pref that's not.
> >
> > IN MX 5 firewalled.mailserver.com.
> > IN MX 10 reachable.mailserver.com.
> >
> > Pref 10 is reachable. Pref 5 is only reachable via TCP/25 by
> > reachable.mailserver.com, which is configured to relay SMTP for the
> > domain.
> >
> > A very, VERY few sending SMTP servers never even try to query the MX RR
> > for reachable.mailserver.com.
>
> Most MTAs implement the full specfication. Some implement
> a minimal specfication. Your configuration DOES NOT WORK
> with MTAs that implement the minimal specfication. Your
> configuration therefore is broken as the RFCs tell you what
> a minimal implementation is required to do and your
> configuration will not work with such a client.
>
> > ... Kev
> >
> > On Wednesday 28 March 2007 09:23 pm, you wrote:
> > > > You mean "their" configuration is broken? The sending mail server is
> > > > NOT ours. We're on the receiving end.
> > >
> > > No. Your configuration is broken. The lowest preference
> > > MXs MUST always be reachable. You cannot depend upon
> > > fallback to higher preference MXs. The sending side is not
> > > required to try them. It is required to try all the lowest
> > > preference MXs.
> > >
> > > > Our MX RRs are not empty. We've got two MX RRs for the domain in
> > > > question. Pref 5 is an internally firewalled server. Pref 10 is a
> > > > DMZ (world reachable) SMTP server. 99% of the SMTP servers sending
> > > > us mail, query the MX RRs, select the most preferred, but the
> > > > connection times out because THAT MX host isn't world reachable. So
> > > > they fall back to our pref 10 mailserver, which spools and delivers
> > > > to the firewalled mailserver.
> > > >
> > > > ...except for a few, which I'm trying to narrow down to some common
> > > > factor.
> > > >
> > > > RFC 2821 section 5 certainly strongly suggests that mail transport
> > > > agents support multiple MX records.
> > > >
> > > > ... Kev
> > >
> > > A minimal SMTP client only has to try all the lowest preference MXs.
> > > Your lowest preference MXs are unreachable. That make you wrong.
> > >
> > > [ I don't know why anyone would write a minimal SMTP client
> > > as a minimal SMTP client still has to be prepared to try
> > > multiple hosts and it really is not much more work to add
> > > all the hosts in the RRset to the list of servers to try. ]
> > >
> > > Mark
> > >
> > > > On Wednesday 28 March 2007 08:04 pm, Mark Andrews wrote:
> > > > > > I've encountered a specific problem FOUR times in the past six
> > > > > > months now and
> > > > > >
> > > > > > am kindly asking Bind-Users for some insight.
> > > > > >
> > > > > > The problem is sending SMTP servers that don't ever query past
> > > > > > the first (hi pref) MX RRs. The first time we encountered this
> > > > > > problem, it was with an e-mail list server appliance (don't know
> > > > > > the exact type/make/model) at a local university in our area.
> > > > > >
> > > > > > The second and third times were with new MS Exchange servers.
> > > > > >
> > > > > > Now today, I'm working on the same problem with a domain who's
> > > > > > SMTP services are hosted by Network Solutions Inc. (NSI).
> > > > > >
> > > > > > We use a strategy whereby our lowest numbered (high pref) MX RR
> > > > > > is a firewalled host. The higher numbered (lower pref) MX RR
> > > > > > designates our DMZ SMTP server, which handles e-mail on behalf of
> > > > > > the server in the other MX RR.
> > > > > >
> > > > > > The DMZ SMTP server is world reachable on TCP/25. It's straight
> > > > > > out of the ORA Nutshell book, "Building Internet Firewalls". We
> > > > > > process 4 million messages per month, so I'm pretty sure that
> > > > > > other organizations are still using MX and firewalls to force
> > > > > > mail through the DMZ SMTP server, and then deliver back to a
> > > > > > better protected mail server.
> > > > > >
> > > > > > I've verified that the sending SMTP server only ever queries the
> > > > > > first (low numbered - high pref) MX RR. After that...NOTHING.
> > > > > > It never tries the second.
> > > > > >
> > > > > > The net result is that the sender (in this case) will queue SMTP
> > > > > > traffic for our domain indefinitely....because they never look up
> > > > > > MX RRs any lower than the highest pref MX RR.
> > > > > >
> > > > > > Has anybody else run into this lately?
> > > > > >
> > > > > > For the curious.... YES! We plan on configuring transports in
> > > > > > place of the
> > > > > >
> > > > > > old Firewall/MX strategy on our Postfix servers ASAP.
> > > > > >
> > > > > > Thanks in advance. :-)
> > > > > >
> > > > > > ... Kev
> > > > >
> > > > > Your configuration is broken.
> > > > >
> > > > > RFC 974
> > > > >
> > > > > If the list of MX RRs is not empty, the mailer should try to
> > > > > deliver the message to the MXs in order (lowest preference value
> > > > > tried first). The mailer is required to attempt delivery to the
> > > > > lowest valued MX. Implementors are encouraged to write mailers so
> > > > > that they try the MXs in order until one of the MXs accepts the
> > > > > message, or all the MXs have been tried. A somewhat less demanding
> > > > > system, in which a fixed number of MXs is tried, is also
> > > > > reasonable. Note that multiple MXs may have the same preference
> > > > > value. In this case, all MXs at with a given value must be tried
> > > > > before any of a higher value are tried. In addition, in the
> > > > > special case in which there are several MXs with the lowest
> > > > > preference value, all of them should be tried before a message is
> > > > > deemed undeliverable.
More information about the bind-users
mailing list