Slightly OT - MX RR Santity Check requested...
Kevin P. Knox
bind-users at rc4systems.net
Thu Mar 29 01:35:11 UTC 2007
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