[Brought back onto the list - if you have anything you wish to add... - XF]
----- Original Message -----
From: Steve Kowalik <[EMAIL PROTECTED]>
To: Crossfire <[EMAIL PROTECTED]>
Sent: Saturday, December 30, 2000 2:11 AM
Subject: Re: [SLUG] Email Server
> On Fri, Dec 29, 2000 at 01:54:05PM +1100, Crossfire wrote:
> > ----- Original Message -----
> > From: "Colin Humphreys" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: "Alan Lee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Friday, December 29, 2000 11:11 AM
> > Subject: Re: [SLUG] Email Server
> >
> > > If you are at all concerned about security, then you really only have
> > > two choices.... qmail or postfix.
> >
> > sendmail is fine damnit. Just don't run a version with known
> > vunerabilities, and keep an eye open for advisories [like any good
sysadmin
> > should].
> >
> And which version would that be?
IIRC, 8.9.2 is fairly good. I'm sure others will be able to tell you which
versions of sendmail are "safe".
> > Bwargh. If I hear another "qmail is good" rant, I'm gonna barf. I'm
not
> > going to dispute smail, postfix or exim, or any other mailer I have no
> > experience with.
> >
> > qmail is not good. qmail is disgusting. Why?
> >
> I think you're wrong. The way it is setup takes getting used too, but it
works, amd works well.
>
> > qmail is incrediably network inefficent[1].
> >
> No, it isn't. It can hardly be called inefficent when it delivered a 12K
message to 5 recipiets on 5 different mail servers in just under 7 seconds.
I had to pick my jaw up (my 56K link is flaky at the best of times.)
First, lets verify with the maths: a 56K modem's uplink is 33.6Kbps, 10
bits per byte [due to Async framing]. thats a maximum transfer speed of
3.3KB/sec. your 12K message would take approximately 3 seconds (actually, a
little over) to transmit.
The fact you sent it to 5 distinct hosts, in under 7 seconds immediately
indicates that you are mistaken about either the time to deliver to all 5
recipiants, or of the size of your message.
If sendmail was transmitting to a smart-hub on the other side of the modem
link, it would take the 4 or 5 seconds - the message would be sent as a
single envelope to the smart-hub for further processing. Otherwise, you'd
be looking at a minimum of 5*3 = 15 seconds to send it to each distinct
host.
Qmail, however, doesn't support multiple recipients for envelopes, so those
5 recipients become 5 distinct envelopes. All 5 envelopes must be delivered
seperately. You automatically take a minimum of 5*3 = 15 seconds to
transmit that 12K message. This also affects smart-hosts under qmail IIRC.
> > qmail does address aliases in a truely disgusting manner (whatever
happened
> > to just using /etc/mail/aliases and ~/.forward, hmm?). Having to create
> > 'users' just to contain mail alias folders is just plain stupid.
> >
> "echo 'username' > /var/qmail/alias/.qmail-alias" is plain stupid?
Apart from the fact its actually ~alias/.qmail-alias, or if you're running
virtual domains, ~vhostaliasuser/.qmail-alias, yes - it is. More uncessary
inode and disk space wastage - each of those files is a minimum of one
block, and use one inode.
Yes. Aliases are most easily managed via the older aliases style. They're
more space efficent. And I'm sure sendmail's alias hashes are faster to
read too.
> > The `mailfolders' message storage scheme is just plain filesystem
> > unfriendly[2].
>
> Only because it uses one inode (or more) per message, but it's _fast_, and
works well.
Hence why its bad. For large sites, you constantly have to watch the inode
free count on the mail volume. With sendmail or mbox systems, one inode per
spool, just watch your free disk space. Also, most POP3 and IMAP daemons
work with mbox, not mailfolder. Same with mailreaders.
> > qmail's smtpd via inetd is inefficent, making you use the author's silly
> > tcpserver thing (which is just as bad IMO). More cruft to install. :/
>
> tcpserver is a godsend, and not at all cruft. Logging via IP, and defining
exactly what can and can't connect is a Good Thing[tm]
IP filtering is your protection and IP access logging layer.
And *NO* high performance system should ever run out of a inetd/tcpserver
style system. You're introducing unnecessary overhead, and this *WILL*
force your load up every time.
> > When under heavy mail loads, qmail will happily blow a single processor
PIII
> > system load up to 60+. This basically renders loadaverage monitoring
> > useless.
> >
> Really? And what do you base this claim on? Pure and utter FUD. My mate's
cable box runs qmail, and when cable went down for 4 hours, and he had a
outgoing queue of 150 messages, when the connection went up, it delievered
them all faultlessly, and gave the system a 0.4 load average (Pentium 120,
too)
We run a host with multiple (read 3) spools, tuned for *very* large spools
and queues. This machine, during a typical maillist run, gets its system
load blown out to 60.0ish. Also, broken MTAs which try [and get blocked]
and then retry rapidly have been known to blow the load up to 30 due to
tcpserver cycling processes rapidly. Also, we only use the machine to
process 20%->30% of our list traffic. the rest runs through sendmail - and
the sendmail machines are a lot happier in terms of system load.
> > All this said and done, qmail's only redeeming feature is that it
flushes
> > its spools moderately quickly. Mind you, in my eyes - thats its only
> > redeeming feature.
> Moderately quickly? Hell, qmail _speeds_ along on my server.
We're known for pushing qmail into its worse case scenario, in which case it
performs badly compared to sendmail. [we run mail lists - this is to be
expected]
> > [1] The "Lets send out multiple recipiants as individual envelopes" idea
> > is just plain stupid.
> This is explained in the Life with qmail document. Which i refuse to paste
here because it's 2am, and because i'm lazy.
and lazyiness is not an excuse. I don't care how much "more complicated" it
would make qmail to do multiple envelope delivery, its is irresponsible to
waste bandwidth when you could be saving it. Especially here.
> Did you help writee sendmail, or do you just hate DJB and/or qmail?
I hate qmail - the config is kludgy, and steps distinctly away from most
other MTAs. Migration to qmail is a pain in the ass, and similarly,
migration from qmail is also a pain in the ass. The inetd based smtpd
design is stupid. and it rabidly wastes inodes and space.
DJB on the other hand, seems to refuse to accept that he makes some
absolultely god-aweful decisions, and won't go back on them. [in particular
the whole multiple recipiants thing].
In my experience, the people who flock to qmail the most, are the same
people who can't be bothered to discover that sendmail has an m4 config
system, and refuse to accept that the same mailer we've been relying upon
for years, is still an excellent system to be using if network efficency,
reliablility and compatability is important to you.
If you want my professional opinion, qmail does not belong anywhere near
mail-hubs, mailing lists, or other high-volume mail areas.
--
+-================================================-+
| Crossfire | This message was brought to you |
| [EMAIL PROTECTED] | on 100% recycled electrons |
+-================================================-+
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
