Slightly OT - MX RR Santity Check requested...
Kevin Darcy
kcd at daimlerchrysler.com
Thu Mar 29 02:01:34 UTC 2007
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