Slightly OT - MX RR Santity Check requested...

[Mosemann, Russell]

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.