On Monday, November 18, 2002, at 05:16 PM, Gabriel Ricard wrote:

So, has this been done already? Or even thought of? Is it possible?
Primehost used to have a module that would speak rudimentary SMTP, but it
would mostly forward messages on to a delivery hub.   I doubt the code
would work in 3.x, even if someone could find it.

Or am I just nuts?
Kinda.

SMTP is a simple protocol (a simple mail transport protocol, to be
specific), but there are some complex semantics behind SMTP, such as
knowing that you must have guaranteed that the message is received and
safe (which usually means committed to disk) before you return the
"Message queued" status to the DATA command.  There are a bunch of other
gotchas like that one, and it becomes really easy to screw up routing
semantics given the wide array of legal addressing formats.  Basically,
while it's easy to emit and read SMTP format, getting the protocol right
is actually pretty hard, unless most of what you do is pass messages along
to a smarter mail server.

I'm not trying to say no one else should ever write an SMTP server, I'm
just saying the job is a lot harder than it looks, and if you can use an
existing one, you'll save yourself a lot of heartache.  You should prowl
USENET groups or mailing lists to see if there is information about tuning
Exim; most mail servers are way faster than the connections they serve
(your case may be different), and you may be suffering from another
problem, like slow DNS resolution (running a caching-only DNS server on
the same box as the mail server may help), or file system problems (if you
queue a lot of messages, too many files in one directory can slow down
some file systems; try another filesystem).  If you can't tune Exim
adequately, consider another Mail Transport Agent (MTA); I'd recommend
sendmail (I know, you're going to say "it's slow and insecure"; I'll say
"Stop running a sendmail from the early '90s").  Properly configured, the
current sendmail implementation can process more messages per second than
current releases of postfix or qmail.  Among the reasons are that sendmail
can relay messages without doing any disk writes in many cases.   "Proper
configuration" usually means watching your timeouts. creating multiple
queues, and moving slow messages to slow queues (most folks don't run
sendmail with more than 1 queue). You can use aliases supported by most
MTAs to run code through Tcl procs (and once AOLserver 4 comes out, you
can load libnsd.so and get all your favorite AOLserver functions), and
sendmail and postfix will both allow you to read virtual user mappings
from a database (including MySQL and PostgreSQL, if you plug in the right
drivers) or LDAP.  Ok, it's not as friendly to configure as AOLserver, but
sendmail and postfix do their jobs really well (Exim probably does, too).

Another point is that if your problem is DNS or filesystem issues,
switching to another MTA won't fix it, so that's another point in favor of
trying to understand why your current setup is slower than you want it to
be.

So, before you start reading and rereading RFC 821 and friends, see if you
can adjust your MTA environment first, to make it perform to your needs.

Pete.

Reply via email to