[geeks] Email experts?

[Greg A. Woods]

[ On Wednesday, January 9, 2002 at 11:38:15 (-0500), Big Endian wrote: ]
> Subject: Re: [geeks] Email experts?
>
> I have a machine that relays mail from our application servers to the 
> world.  We need to be able to make user bound email (reciepts and 
> confirmations and such ala ebay/amazon/etc) go out almost 
> instantaneously.  However the other 66% of our traffic is bound for 
> about 10 very overloaded domains in .gov land.  I'm trying to add 
> priority capabilities to the mail queueing system.  The system needs 
> to be scaleable to 300k total messages a day.  100k of those need to 
> be gone within 5 minutes.

You still haven't described the rates at peak times, nor the load
distribution, nor the message size distribution, nor half dozen other
relevant parameters.  I can easily send 100,000 messages per day within
five minutes of submission on an ISDN-connected network from a lowly
486-based system, provided I don't tell you anything more about how big
the messages are and at what rate and when they're submitted, what I/O
subsystems my server has, and how well connected the destination site(s)
is(are) to my upstream network.

Assuming you have more than adequate outbound network capacity, and that
it's got a low enough latency; assuming you've got adequate server
capacity; assuming the messages are not overly large; and assuming
you're not simply trying to feed more e-mail to some sites than they're
capable of receiving, then either of Exim or Postifx, and probably
Zmailer too, and maybe just maybe even smail, should be easily capable
of handling your e-mail load without any direct attention at all.

Perhaps all your problem is not your own but rather that of the
administrators of the overloaded .gov servers.  Perhaps you can mitigate
this problem either by peering your network directly with them, and/or
by managing their expectations better by informing them of the loads
they can expect from you.  I don't know exactly what sendmail's queuing
algorithms do, but I do know intimately how smail's algorithms work and
how they react to clogged destinations.  I made some relatively simple
changes to smail not so long ago so that a clogged site wouldn't delay
delivery to un-clogged destinations.  With those changes one of my
customer sites went from having major problems when a significant
destination (eg. home.com) got clogged) to having no problems at all.
I.e. even with a clogged/down common destination we were able to meet
and/or exceed user expectations with regard to delivery latency
(i.e. maintain essentially the same latency as was seen without a common
destination being clogged or down).

There are a huge number of assumptions and secondary factors here, and
without detailed analysis I doubt it's possible for anyone to make any
more intelligent suggestions -- we would only be guessing.

Your ideas about queue management are based on hacking your current
sendmail based implementation, and perhaps in blindness to the real
causes of the delays you are experiencing.  In any real scalable mail
system your loads are trivial and shouldn't even account for more than a
few moments of your attention to handle really exceptional bounces and
such.

BTW, putting a requirement like "30% of our traffic MUST be delivered in
less than 5 minutes" on an SMTP-based public Internet system is like
playing Russian roulette against yourself with three chambers loaded.
You cannot win.  Your expectations are not even in line with reality.
You need to think in terms of best effort and be able to cope with
unexpected delays and abberant conditions that are not within your realm
of control.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>