Slightly OT - MX RR Santity Check requested...

[Kal Feher]

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