Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote:
> On Tue, 3 Apr 2001, Craig Sanders wrote:
> > * it's slow.
> > * it doesn't scale well.
>
> Short: FUD, spread by one who's not kept up with current developements -
> Look at whats being done in 8.12 wrt multi-queues and
> multi-runners/queue. 8.12 is faster than 8.9.3 ever was (much faster
> than 8.10/11), and has a hell of lot more function
that's not saying a lot.
> Long: Sendmail was basically in `maintenance' mode for several years,
> and a few of its competitors (who didn't have legacy concerns) were able
> to leapfrog it in performance and scalability. Sendmail has had quite
> a bit of rework...
read as: bugger all was done on sendmail for years until the authors
noticed that:
a) people had got sick of all it's problems and written vastly superior
alternatives like qmail and then postfix
and, more importantly,
b) there was a chance to become dot-com millionaires.
too little, too late.
> No, but it has come a long way since then, a significant portion has
> been rewritten since 8.9.3 The last incident I can recall turned out
> to actually be the kernel capability bug...
too little, too late.
> > * it's configuration language is overly complex for the task at hand
> > (the m4 macros helped a lot, but it's still way more complex than it
> > needs to be)
>
> Depends upon the task at hand eh? For a end-node, sure sendmail.cf
> hacking isn't needed -
sendmail.cf hacking is never needed. anything you can do with .cf
hackery can be done in postfix with plain-english configuration and
appropriate use of map files.
> but the provided m4 features cover that pretty
> well with FEATURE(nullclient, `<smart_host>') -- what could be easier.
"relayhost = smart.host.example.com" in /etc/postfix/main.cf
and you've got to admit - m4 isn't exactly the easiest or most pleasant
of languages to work with...in fact, it's ugly. and that's sendmail's
*easier* configuration style.
> Sendmail *is* the kitchen sink of MTAs - and yes, there is a cost to
> that, but significant tuning *is* going on... The other side is that
> with the kitchen sink comes everything:
you miss the point. you don't *need* anything near as complicated as
sendmail.cf or even sendmail.mc to provide the features of sendmail.
> Mixing/matching of DB, LDAP, text, HESIOD, PH (not on Debian), etc.
> for *ANY* map: aliases, access, etc.
postfix does all that and more: including mysql, postgres maps, posix
and pcre regexp maps and more.
> Why suffer with `sendmail compatible' when you can have the
> `REAL thing'?
because the 'REAL thing' sucks.
postfix isn't sendmail-compatible because sendmail is the pinnacle of
MTAs and must be emulated. postfix is sendmail-compatible because there
are a lot of people running sendmail systems who will not change from
their legacy software if it requires a complete re-implementation of
their mail system...qmail proved that.
why suffer with sendmail when you can have postfix, which can do
everything that sendmail can do only faster and better and securely?
look, if you're happy to use obsolete software that's fine by me,
doesn't bother me at all...but to insist that it's anywhere near as good
as the alternatives is annoying and ridiculous.
sendmail had it's day. that day is over. it should just retire
gracefully.
the phrase "mutton dressed up as lamb" seems appropriate - sendmail's
recent facelifts are like an old woman whacking on way too much makeup
and pretending/insisting she's as young and pretty as the 20 year olds.
it really doesn't fool many people.
craig
--
craig sanders <cas@taz.net.au>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Reply to: