Re: Er.... for Sendmail users......

On Mon, 28 Aug 2006, adam bultman wrote:

> One thing I must talk about, though: Sendmail is slow in general.
> Qmail will accept, handle, and deliver mail far faster than sendmail
> does because it is a number of small, discrete binaries. I ran a couple
> sendmail servers at my first job, a few qmail servers at my second job,
> and now I run sendmail servers at my current position. In terms of raw
> speed, no offense, but qmail is to the rocket as sendmail is to the
> rickshaw with square wheels. If I do get spammed hard, qmail will
> always handle it more intelligently than sendmail. Hands down.

Huh?! Qmail is faster because it's small discrete binaries?! First off,
sendmail (from the perspective of the daemon) is one binary (plus some
libraries), and that will always beat spawning external programs, if that's
what qmail does. Everything else (with the exception of smrsh) are userland
utilities.

Second, qmail doesn't do a fraction of what sendmail does, so sure, if it
couldn't do what little it does faster (seeing that it doesn't need the code
baggage of all the extra functionality) the developer would have to be a
really bad coder. However, add some complexity to your requirements and
either qmail can't do it, or you'll find sendmail will scale far better than
qmail just because of how well you can tune it. I'd only buy your conjecture
if you're testing out-of-box configs.

Third: qmail always handles spam storms *more* intelligently? Dude, I'll put
my sendmail config against qmail any day. Again: you don't have the level of
tuning capabilities I have with sendmail. Using a milter alone will smoke
qmail on those kind of tests, but even without it you have a bunch of rules
that will "intelligently" handle spam storms. Beyond connection rate
throttling, bad receipt throttles, and queue/refuse on load average thresholds
you can tune *every* stage of the SMTP transaction's timeouts.

I'll put my tuned sendmail installation against any qmail install any day.
Hands down.

> When sendmail has a problem, if I want to tinker, I have to shut it
> down. If qmail is having a problem, I can stop the daemon (qmail-smtpd)
> so it doesn't accept messages while taking care of the queue
> (qmail-local, qmail-remote). I can tweak the number of incoming
> connections, outgoing connections, etc, and handle things a little more
> delicately and smoothly and not have outages.

Again, this isn't correct. You could easily put in a 450 response in your
access.db and the running daemon will immediately tell senders to requeue
and try again later. If you know anything about the access database you know
that you can finely target that response as well.

As for tweaking, again, I'll wager you can't tune qmail anywhere near what
sendmail can.

> Plus (and this is my biggest thing) I don't have the sendmail "Oh, Crap,
> I don't know what to do so I'm deleting incoming mail" error. Qmail has
> the sense, when it's misconfigured, to either not start at all, or to
> save incoming mail to the queue so i don't lose messages.

Odd. I've never had this problem with sendmail (outside of running out of
disk on the queue volumes) so I can't imagine what you did to get that. Even
so, sendmail does exactly what it's configured to, which is a *good* things.
You may think that qmail blindly queueing thing is a good thing, but I see a
DoS opportunity as your disk space is exhausted. Sendmail, properly
configured, is rock solid.

> I'll let you know how I do - but if you have more stories, I'd love to
> hear them. I've got to make a decision and quickly, so I can start
> working. Only snag: I'm on solaris.

<G> Then you've already got a *great* MTA: sendmail! ;->>>>

         --Arthur Corliss
           Bolverk's Lair -- http://arthur.corlissfamily.org/
           Digital Mages -- http://www.digitalmages.com/
           "Live Free or Die, the Only Way to Live" -- NH State Motto
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Aug 28 20:47:08 2006