Localized mail servers, global scope

Wed Jun 22 19:20:18 UTC 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 username.YY at groupname.com instead 
of being able to go with username at YY.groupname.com, 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, <brad at stop.mail-abuse.org>

"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.