Slightly OT - MX RR Santity Check requested...

[Kevin P. Knox]

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.