Slightly OT - MX RR Santity Check requested...
Kevin P. Knox
bind-users at rc4systems.net
Thu Mar 29 02:32:14 UTC 2007
Assume that we block the pref 5 MX host (which we do). Shouldn't sending
hosts use the pref 10 MX RR?
... Kev
On Wednesday 28 March 2007 09:50 pm, Mosemann, Russell wrote:
> Lowest preference value, not lowest preference. You are blocking the MX
> server that all mail servers are required to contact.
>
> --
> Russell Mosemann, Ph.D.
> Associate Professor of Computer Science
>
> From: Kevin P. Knox
> Sent: Wednesday, March 28, 2007 8:35 PM
>
> Our LOWEST pref MX RR IS REACHABLE.
>
> 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.
>
> ... 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