On 30 Dec 2000 18:03:23 +1100, Crossfire wrote:
> [Brought back onto the list - if you have anything you wish to add... - XF]
> From: Steve Kowalik <[EMAIL PROTECTED]>
> > On Fri, Dec 29, 2000 at 01:54:05PM +1100, Crossfire wrote:
> > > From: "Colin Humphreys" <[EMAIL PROTECTED]>
> > > > 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".
Sigh. Rewind and reality check. Everybody get the irony in there? Good.
> 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.
Next, let's re-verify the maths. Async framing went out with the loaves
and fishes. Ever since MNP4, modem links have been synchronous, clocking
in at 8 + epsilon bits to transfer each byte of data. But wait, there's
more! Ever since MNP5, modem links have been compressed. Modem
compression isn't really worth all that much, except in the very limited
realm of repetitive plain text. Like email, to pick a random example.
And what better way to make it repetitive than to send the same thing to
n destinations?
> 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.
By one person, for one person, yes. The thing about virtual domains,
see, is that they're usually for the benefit of multiple owners. And
these multiple owners, pesky and arrogant individuals that they are,
want to make changes to delivery rules at odd hours of the morning with
depressing regularity. There's something very, very appealing about
putting all the control for any given domain in the hands of a separate
user, and then washing your hands of the matter. But then, I'm an
anti-control freak.
> 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.
And the qualitative difference between monitoring disk space alone or
disk space and inode count is what, exactly? The median mail message
weighs in at 3-4k in size. The average big ext2 filesystem comes
formatted with one inode per 4k of disk space. Good match, wouldn't you
say?
> Also, most POP3 and IMAP daemons
> work with mbox, not mailfolder. Same with mailreaders.
Boggle. How many POP3 daemons do you want to run? They don't exactly
vary a huge amount in terms of featureset. As for IMAP - I can think of
three major open source contenders off the top of my head. Of those, one
may or may not be mbox only, but shouldn't be touched by a ten foot pole
(as a security expert, I'm sure you know which one I'm talking about),
one is maildir only, and one uses it's own entirely funky storage
subsystem and glares daggers at any foreign software.
> 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.
Somebody go and count the cycles involved in half a dozen fork/execs -
/especially/ under Linux - and compare it to the cost of fsyncing one
block of data to disk. Reality check?
> 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.
You've said a lot about mailing lists, and, with all due respect,
grossly misrepresented dib's view on them (which directly relates to how
and why qmail does what it does). I don't think large scale mailing
lists are a topic of interest to the original poster, so I'll just say
that djb did some rather extensive benchmarking and testing of his
design versus the more orthodox approach, and documented his priorities
and results quite extensively.
m, who reluctantly withdrew a paper on large scale mail architecture
from linux.conf.au recently.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
