Slightly OT - MX RR Santity Check requested...

[Kevin Darcy]

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.
>>>>         
>
>
>
>
>
>
>