Slightly OT - MX RR Santity Check requested...
Kal Feher
kal.feher at melbourneit.com.au
Thu Mar 29 04:00:43 UTC 2007
I think your earlier email explained it well enough. I still don't
understand why you are doing that. You cant fix the compliance or otherwise
of someone else's configuration. You really should use the reachable server
as the most preferred mx host.
If you are still sometime away from your mailserver reconfiguration then use
views to flip the preference for outside servers.
So the public sees :
IN MX 10 firewalled.mailserver.com.
IN MX 5 reachable.mailserver.com.
Your servers see :
IN MX 5 firewalled.mailserver.com.
IN MX 10 reachable.mailserver.com.
On 29/3/07 12:08 PM, "Kevin P. Knox" <bind-users at rc4systems.net> wrote:
> At least somebody (you) finally understands what I'm even doing at all.
>
> Thanks for the clarification.
>
> ... Kev
>
> On Wednesday 28 March 2007 10:08 pm, Kevin P. Knox wrote:
>> At least somebody (you) finally understands what I'm even doing at all.
>>
>> Thanks for the clarification.
>>
>> ... Kev
>>
>> On Wednesday 28 March 2007 10:01 pm, Kevin Darcy wrote:
>>> 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.
>
>
--
Kal Feher
Team Leader
Network Services and Production Support
Melbourne IT Ltd
Level 2, 120 King Street
Melbourne Victoria 3000
AUSTRALIA
Ph: + 61 3 8624 2326
Mob: + 61 400 072 569
Website: www.MelbourneIT.com.au
More information about the bind-users
mailing list