Slightly OT - MX RR Santity Check requested...
Kal Feher
kal.feher at melbourneit.com.au
Fri Mar 30 07:13:24 UTC 2007
Our pleasure.
Pointing out faults in other peoples systems is what we're all good at ;)
On 30/3/07 12:29 AM, "Kevin P. Knox" <bind-users at rc4systems.net> wrote:
> I would like to sincerely thank everybody who answered me on this! Thank you
> VERY much! It's given me a lot of verification to take up to my management
> and make changes to our SMTP services that have been NEEDED for a long time!
>
> Hopefully, maybe now they'll see the wisdom in doing away with this antiquated
> and problematic method for forcing SMTP traffic to a DMZ host.
>
> I've known for a long time how to do away with the MX RR for the firewalled
> mailserver, and have tried to explain many times why there is a better way of
> handling mail here, but now that it's actually the CULPRIT of repeated
> problems, they'll be a little more receptive of the changes I have to make.
>
> Thanks again. :-)
>
> ... Kev
>
> On Wednesday 28 March 2007 10:21 pm, Mark Andrews wrote:
>>> Our LOWEST pref MX RR IS REACHABLE.
>>
>> When one is talking about MX records the lowest preference
>> MX record is the one with the lowest value in the preference
>> field. The lowest preference MX(s) are tried first. This
>> is the only way to avoid confusion.
>>
>> "lowest preference" is most preferred.
>> "higest preference" is least preferred.
>>
>> The lowest preference MX is not reachable.
>>
>> "pref" is ambigious.
>>
>>> 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.
>>
>> Most MTAs implement the full specfication. Some implement
>> a minimal specfication. Your configuration DOES NOT WORK
>> with MTAs that implement the minimal specfication. Your
>> configuration therefore is broken as the RFCs tell you what
>> a minimal implementation is required to do and your
>> configuration will not work with such a client.
>>
>>> ... 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
More information about the bind-users
mailing list