Slightly OT - MX RR Santity Check requested...
Mark Andrews
Mark_Andrews at isc.org
Thu Mar 29 04:20:14 UTC 2007
> I think your earlier email explained it well enough. I still don't
> understand why you are doing that. You cant fix the compliance or otherwise
> of someone else's configuration. You really should use the reachable server
> as the most preferred mx host.
>
> If you are still sometime away from your mailserver reconfiguration then use
> views to flip the preference for outside servers.
>
> So the public sees :
> IN MX 10 firewalled.mailserver.com.
> IN MX 5 reachable.mailserver.com.
It's cleaner to just have reachable.mailserver.com.
> Your servers see :
> IN MX 5 firewalled.mailserver.com.
> IN MX 10 reachable.mailserver.com.
>
>
>
> On 29/3/07 12:08 PM, "Kevin P. Knox" <bind-users at rc4systems.net> 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: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.
> >
> >
>
> --
> Kal Feher
> Team Leader
> Network Services and Production Support
> Melbourne IT Ltd
> Level 2, 120 King Street
> Melbourne Victoria 3000
> AUSTRALIA
> Ph: + 61 3 8624 2326
> Mob: + 61 400 072 569
> Website: www.MelbourneIT.com.au
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list