Slightly OT - MX RR Santity Check requested...

[Mark Andrews]

> 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.
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org