> > 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?
The point is still valid regardless of the transfer method.
> > 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.
black vs white. choose whats appropriate, thus the value of opensource.
> 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?
If your running big mail servers lots of disk is important anyway, but
saving it is still good. mbox isnt great, i like maildir and most apps
have been adapted or writen for maildir support. qmail can run as mbox
anyway, and if your really desperate you could just pop into your local
machine.
> > 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.
There are pop / imap servers for both. what does it matter how many
there
are?
> > 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?
depends on how things are implemented. No doubt some poor coding would
make an inetd/tcpserver solution higher performance.
> > 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.
Crossfire spams for a living, he has some knowledge of MTA's and has
caused me to reconsider my preferance of qmail (expecially after having
recently installed exim as the mail relay for our exchange machines at
PCL)
Find whats good for you, if you dont like it attack the code with vi
(or nano, i like nano) then recompile.
Dean
--
BONG: http://www.bong.com.au
EMAIL...
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
ICQ: 16867613
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
