RFC 1123 - Load balancing question

Chris Buxton cbuxton at menandmice.com
Mon Oct 2 17:26:27 UTC 2006

Note that this isn't a BIND question at all, and probably shouldn't  
be on this list.

The RFC seems pretty clear. The algorithm used by a mail server  
should be:

- Retrieve all MX records for the recipient domain from DNS. (If  
there is no MX record, there is a fallback mechanism, but that's not  
relevant here.)

- Group the MX records by preference.

- Resolve each MX record's mailhost name to an address using DNS. If  
there are multiple A records for a given mailhost, I'm not sure  
whether the sender is required to respect the entire RRSet or just  
use one of the available addresses.

- Check the list of retrieved addresses for its own address (or does  
it do this based on its configured name? not sure). If found, remove  
itself and any other mailhost with an equal or higher preference. The  
result so far could potentially be cached by the sending MTA for use  
in delivering future messages, hopefully respecting the DNS TTL.

- Repeat the following for each group (i.e. for each preference  
value), starting at the lowest-number preference:

   - Order the mailhosts in this level somehow. If the sending MTA is  
configured to do some kind of address-based sorting, or any other  
logical sort algorithm, do that; otherwise, randomize the list.
   - Contact each recipient MTA in the list (of recipient MTA's for  
this preference value), in the derived order, until one responds and  
accepts the message for delivery.

Note that this means that the order should be re-determined each  
time. If there is no reason for the sender to favor one particular  
recipient over another, the ordering for each preference value should  
be randomized each time. The result then would be a roughly even  
distribution across all of the recipient domain's MTA's ** that have  
the same MX record preference value **.

Chris Buxton
Men & Mice
Take control of your network

On Sep 30, 2006, at 4:12 PM, Jon Doe wrote:

> Can someone please help me in understanding the information  
> contained in the
> following section of RFC 1123?
> I'm currently involved in a situation where the other company I'm  
> dealing is
> quoting RFC1123 with claims that my mailer is not complying
> with this passage and therefore, it's my fault that mail is being  
> delayed in
> reaching them.
> RFC 1123
> 5.3.4  Reliable Mail Transmission
> (1)  Multiple MX Records --  If there are
>               multiple destinations with the same preference and there
>               is no clear reason to favor one (e.g., by address
>               preference), then the sender-SMTP SHOULD pick one at
>               random to spread the load across multiple mail exchanges
>               for a specific organization;
> The short story is that, we send over 15,000 messages to one  
> company, and
> during peak times we see delays of those messages to be over 4- 
> hours (I dont
> see delays to any other domain). They have 6 MX records and during  
> these
> peak times, my SMTP logs show attempts to connect, but there's always
> delays. Even when I telnet to port 25, it takes up to 20 seconds to  
> even get
> the banner screen. The other guy says that they show that they most  
> of my
> mail sender's traffic attempting just 2 of the 6 MX records they  
> have, and
> therefore not "spreading the load".
> So my question is, how should this passage in the RFC be  
> interpreted? What
> does the RFC mean by "spread the load"? My SMTP sender simply finds  
> the MX
> server, connects and keeps sending to that one server until the TTL  
> expires.
> Also, what does the RFC mean by "random"? When I do an nslokup on  
> my DNS
> server, I get a list of MX records, and it's this list that my mail  
> sender
> uses in determining where to send the mail. By the way, I found a  
> similar
> passage in RFC 2821 section 5.
> My thought is, my sender is fine, but I want to be armed with the  
> correct
> information before responding to the claims that my sender isn't RFC
> 1123-compliant.
> Thanks in advance!

More information about the bind-users mailing list