Slightly OT - MX RR Santity Check requested...

[Kevin P. Knox]

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