From: Grant Taylor
Date: 2007-01-11 11:15:53 -0500
Subject: Re: single MX resolves to multiple hosts?
More information..: http://www.milter.info/#Support
Ben Spencer wrote:
> I skimmed over the RFC and didn't see this addressed. The following
> configuration seems to defeat the purpose of the MX weight (it also
> seems to cause issues for milter-spiff -- well...depends how one looks
> at it). This the following configuration legal per the RFCs?
As far as I understand it, it is perfectly acceptable for an MX record
to resolve to a host name / A record that in turn resolves to multiple
Consider if you will, a lower numbered / higher priority MX record that
resolves to mx1.example.net and a a higher numbered / lower priority MX
record that resolves to mx2.example.net. Have mx1 and mx2 be two
different clusters in two different locations, each with IP addresses
from two or more different ISPs.
MX 10 mx1.example.net
MX 20 mx2.example.net
mx1 IN A 18.104.22.168
IN A 22.214.171.124
mx2 IN A 126.96.36.199
IN A 188.8.131.52
In this case, MX1 is a cluster behind a couple of load balancers. Each
LB would have a primary IP from one ISP and a secondary from the other
ISP. Granted each LB has a secondary IP that is the other LB's primary
IP address. This will allow either LB to fail with out any thing more
than momentary lose of service for either IP.
MX2 would be set up correspondingly in (presumably) a different
location, (possibly) with different ISPs.
This type of set up will allow you to have a very redundant MX system
that has 4 (or more) different IP addresses to keep the system up and
In this scenario, your MUA / MSA / MTA would resolve each MX to two
different IP addresses and arbitrarily choose one to connect to. If for
some reason a connection to one IP failed (ISP link down), the client
should attempt to use the other IP address of the said MX.
If all IP addresses of a given MX are unaccessible, the client should
try the next higher numbered / lower priority MX in turn.
What is not clear is if the client should continue down it's MX
traversal list if it receives a temporary error from an MX. I believe
the general consensus is that it should continue it's MX traversal list
looking for an MX that is willing to accept responsibility for the
message. The idea is to move the message as quickly as possible with
out having to requeue it.
> Milter-spiff failed the related email message. I suspect it is because
> the connecting mail server was 184.108.40.206 and milter-spiff's lookups
> returned 220.127.116.11.
I have no comment on the operation of milter-spiff in this situation as
I don't have enough information. However if this is indeed the case,
(milter-spiff not properly handling multiple IP addresses for an MX)
this is a bug that should be addressed and I'm sure that Anthony would
have something to say.
(any one) Comments / questions / thoughts / opinions are welcomed and
encouraged. (I'm only human and I like to be (politely) told when I'm
Grant. . . .
Copyright 2009, 2012 by SnertSoft. All rights reserved.