Slightly OT - MX RR Santity Check requested...
Kevin P. Knox
bind-users at rc4systems.net
Thu Mar 29 02:08:52 UTC 2007
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.
More information about the bind-users
mailing list