----- Original Message -----
From: Mikolaj J. Habryn <[EMAIL PROTECTED]>
To: Crossfire <[EMAIL PROTECTED]>
Cc: Steve Kowalik <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, December 30, 2000 7:29 PM
Subject: Re: [SLUG] Email Server
> 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]>
> > 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?
ext2, yes - I rarely speak just of linux. I prefer systems that perform
consistantly between platforms - its far easier to run one system
everywhere, than a different mailer on each architecture.
I prefer mbox anyway. And yes, this is a personal preference.
> > 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.
I'll admit this is more a "I don't like maildir" rant on my behalf. mbox
works. It might be slow - but if thats a problem, split you mbox every n
days, where n prevents you from having an oversized mbox. And yes, you get
performance limitations in threaded designs with mbox because only one
thread can have the mbox open for writing at any given time.
maildir probably also works, just I don't like the idea of having lots of
tiny little files scattered about many directories. and besides, ext2 would
*hate* my mailtree if I did that. [I used to subscribe to debian-devel - 2
weeks of debian-devel in maildir on a ext2 system would probably start to
reach the large-directory-performance-hit point]
> > 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?
This is the CGI vs persistant application server argument. The Persistant
application server won last time I looked. Like I said, I'm not arguing
just for linux, but as it has been pointed out, there is a standalone mode
for the smtpd - so this arguement isn't that valid anyway.
Also Reinvoking applications rapidly is guaranteed to push your load
averages up, even if its not a performance hit. If you're running load
average monitoring as part of a network management system, and you're not
careful with your trigger thresholds, those alarm bells are going to sound a
little prematurely as a result. You solve this with the standalone mode.
'nuff said.
> > 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.
IMO, qmail is fine for just recieving, or pushing around messages for a
`small' number of people who aren't going to push to multiple recipients.
I talk mostly about large scale lists because thats what I do at the moment.
If you want to hear me mention a mailer that isn't qmail or sendmail... One
other mailer which I think is worth a look is zmailer.
I won't recommend zmailer yet for people demanding performance or ease of
configuration however. Last time we ran a practical test on the latest
release, we had a few issues with the spool which prevented a fair test.
[running out of space on /var during a spooling test is bad - and zmailer
and Solaris don't actually seem to be a very hot combo either - I'll be
fixing the /var problem before the next real test]. It is, however,
extremely flexible.
zmailer also promises qmail-like design, whilst maintianing sendmail-level
efficeny with bundling and multiple-recipient handling. On Solaris, so far,
it seems to be badly affected by the weight of the UFS system - I'm still
trying to work out exactly why it performed poorly in my first round tests
on Solaris. I also suspect that it'll run a *lot* better on Linux.
I may also look into exim and postfix in the not so distant future.
> m, who reluctantly withdrew a paper on large scale mail architecture
> from linux.conf.au recently.
drat. Wouldn't have minded to have heard that.
+-================================================-+
| 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
