At Fri, 20 Nov 2009 13:10:15 -0500, Dave B <spam%y2009.dberg.net@localhost>
wrote:
Subject: Re: Looking for guidance on filesystem tuning
>
> On Fri, Nov 20, 2009 at 11:54:50AM -0500, Greg A. Woods wrote:
> ...
> > I'd say just use Cyrus IMAPd, and in addition I'd say avoid Dovecot, and
> > avoid Courier-imap, and especially avoid imap-uw. I say this as a
> ...
>
> What about dbmail with dbmail-imapd?
Hmmm... I've never heard of it until now.
In general it does worry me a lot though when anyone combines the
acronym "db" with the word "mail" as I fear the worst and suspect
they're trying to use a general-purpose relational database as their
hammer to solve all problems. Even worse is when the excuse for using
an RDB for e-mail storage is that it offers SQL to the user.
Indeed I now see from the pgksrc description of mail/dbmail that this is
_exactly_ the kind of abuse I was worried about.
Seriously, Cyrus IMAPd has been fairly carefully designed so as to use
the most optimum data structures possible for each given task inside the
mail storage system thus optimizing the overall application, and indeed
at the source code level it is modular and easily accepts new or better
data storage mechanisms for each of its various "database" requirements.
It really saddens me that so-called "database" people (such as whomever
wrote DBMail and its description for pkgsrc) don't seem to realise (or
at least admit) that filesystems _are_ databases, and filesystems are
carefully optimised to manage and control chunks of variable sized data,
something like exactly what mail messages are. A major part of an
e-mail storage system does not require anything like what a general
purpose relational database system is designed to offer, especially not
one which uses SQL as its interface language. What is best done in an
e-mail storage system by indexing structures more sophisticated than the
filesystem offers is already handled well by appropriate optimized
indexing tools provided inside Cyrus IMAPd.
As for scalability, well sure, I've seen truly gargantuan RDB
installations of various kinds. DBMail's web page claims that they
_think_ it can handle millions of users. Well, no need to think about
it with Cyrus IMAPd, which has been proven to work well with millions of
users in current configurations. Informal reports on various forums
suggest DBMail requires as much as an order of magnitude more hardware
capacity and speed than an equivalent load in Cyrus IMAPd.
The one basic benchmark I've seen which included DBmail does not include
Cyrus IMAPd, though extrapolation from the other results suggests that
Cyrus IMAPd would be several times faster than DBMail at fetching
metadata, and probably equally fast at fetching messages, and perhaps
orders of magnitude faster at accepting new messages from LMTP in a
clustered configuration.
From a security perspective there are some similarities between Cyrus
IMAPd and DBMail, but with the use of SQL as part of a network service
offering in the latter, well, I can't even begin to imagine how many
more possibilities for problems this might present.
Also on the security front I'd really like to see what benefits could
come from rewriting something like Cyrus IMAPd in Google's Go(lang).
I.e. keep the same basic design, and hopefully as much backwards
compatibility as possible, at least with cvt_cyrusdb still in the
picture. I'm really very ready to give up on C for many/most purposes.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgp9QazaxtWef.pgp
Description: PGP signature