North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Localized mail servers, global scope

  • From: Brad Knowles
  • Date: Wed Jun 22 15:24:51 2005

At 6:36 PM +0100 2005-06-22, Tony Finch wrote:

 I don't think you can do that because you need to consolidate the branches
 into a single namespace with some means of dealing with clashes. Most of
 the complexity of the SLB Exim/LDAP system is for handling fuzzy matching
 and name clashes - though see http://www.sendmail.org/faq/section3.html#3.5
That one has been a favourite of mine for many years. I'm glad that there's at least one other person in this world that remembers it.

 and the only centralized part the offices would have to trust HQ to do
 is possibly run a robust redirector to the various LDAP servers.
 That's not necessary if the sites have local LDAP database replicas.
The last version of the Lachman-LASER draft (the one that was issued just before the draft was withdrawn) works well with sendmail and postfix pretty much out-of-the-box for handling LDAP routing. Unfortunately, you're going to have a problem finding a copy of this version of the draft, but you might get lucky if you're good with Google.

Of course, LDAP works best when all changes are made to a central master repository and then distributed out to slave replicas, and all LDAP queries are made exclusively to the slave replicas. It's easy enough to set up slave replicas that you can put one on each mail server, if you like.


Now, I can tell you that you absolutely, positively, do *NOT* want to list 25 MXes for @groupname.com. First off, unless you are exceedingly creative, you're not going to get 25 MXes to fit into a single UDP datagram, and if you cause DNS packet truncation, you will run into all sorts of bizarre stuff that you do not want to see.

Secondly, even if you can manage to cram 25 MX IP addresses into a single UDP datagram, most servers can't handle that many addresses. For example, lets say you list five names with five IP addresses each. Well, if someone connects to the first IP of the first name and gets a "connection refused", then they won't connect to any of the other IPs for that name. Also note that many resolvers do not properly do round-robin or properly honor DNS TTLs. Finally, keep in mind that some MTAs are screwed-up and will only ever talk to the first server on the list. If you go this route, I guarantee that you will see serious load imbalances on the servers -- you will forever have situations where some are virtually unused while others are constantly overloaded, and which ones are which will vary from time-to-time.

Been there, done that. Trust me, you do not ever want to go down these roads.


If you are forced to stick with [email protected] instead of being able to go with [email protected], then you will need to set up a small number of higher-powered servers (no more than five to seven) that are distributed to your main office facilities, and use them to front-end all mail routing for the group.

The more centralized you can make this process, the more manageable it will be, to a point -- you should have at least one or two offsite facilities that can take over if the main site is down.

If you're putting multiple servers at a site, you should also look into using L4 load-balancing switches to hide the number of back-end servers you're using and to make it easier to pull old servers out of service or to put new servers into service.


A lot of the same concepts are covered in the slides for my talk "Scalable IMAP Services: Theory, Practice, and Non-technical Issues" (see <http://www.shub-internet.org/brad/papers/sistpni/>).

--
Brad Knowles, <[email protected]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

SAGE member since 1995. See <http://www.sage.org/> for more info.