[milters] Archive

Lists Index Date Thread Search

Article: 1392
From: Grant Taylor
Date: 2007-01-11 11:15:53 -0500
Subject: Re: single MX resolves to multiple hosts?

Removal...........: milters-request@milter.info?subject=remove
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 
IP addresses.

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.


ORIGIN example.net.
	MX	10	mx1.example.net
	MX	20	mx2.example.net
mx1	IN	A
mx2	IN	A

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 and milter-spiff's lookups
> returned

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 
off track.)

Grant. . . .

Lists Index Date Thread Search