Slightly OT - MX RR Santity Check requested...

[Kevin P. Knox]

At least somebody (you) finally understands what I'm even doing at all.

Thanks for the clarification.

... Kev

On Wednesday 28 March 2007 10:08 pm, Kevin P. Knox wrote:
> At least somebody (you) finally understands what I'm even doing at all.
>
> Thanks for the clarification.
>
> ... Kev
>
> On Wednesday 28 March 2007 10:01 pm, Kevin Darcy wrote:
> > Put even more simply, your configuration *forces* everyone to do MX
> > failover. But MX failover capability is not mandated by the relevant
> > RFC. So, some minimally-compliant implementations will fail. You have
> > brought this on yourself.
> >
> > - Kevin
> >
> > 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.