Brian Blood wrote:
On Mar 15, 2011, at 3:57 PM, Mihamina Rakotomandimby wrote:
Has anyone in here tried Exim with dbmail?
http://www.dbmail.org/dokuwiki/doku.php/debian:exim4
The goal is 1°) to have email users in a SQL database 2°) have an
MTA + MDA (Exim4) 3°) have a POP + IMAP server (OT here, but I'll
choose Dovecot)
All this, running Debian stable. Any notes?
Once upon a time, I deployed dbmail 1.2 and postfix for a client, it
worked fine, but I had some problems with innodb on mysql 4 that are
no longer an issue.
We migrated that client to our ecmsquared.com solution, but I've
always kept dbmail in mind for a backend.
One of the main things that kept it out of consideration that has now
been added to the new 3.0RC is native SSL/TLS support, so I'll be
taking a look at it again once it's reaches stable.
I really like the idea of having messages in a DBMS, to me it's
really a logical choice.
Brian
Short answer: it works.
'long ago ...' (can't remember the year, but OS was FreeBSd 4.X, CPU was
a K6 400 or 500 MHz IIRC, and Exim was early 4.X, not 3.X)
... ran DBMail with courier-mta, then migrated it to Exim. RDBMS was
PostgreSQL.
See also PowerMail, trialed the same way in parallel. IIRC, one of these
stores the message in the DB, the other stores the message in the fs,
but keeps info ABOUT it (more than just location..) in the DB.
What we ran was experimental, half-dozen account quasi 'production' - eg
it was public-facing, did what was asked of it for several months
testing, but I have no idea what it might have looked like under 'real
world' load, let alone a DoS attack. Simulations looked OK, but may not
have been at all realistic.
Major issue was simply more complexity than otherwise required, so we
went back to use of the fs (UFS) as Maildir+ instead of a DB.
Mind - any fs *IS* a 'DB' of sorts, and often a very fast and efficient
one. Whereas a [ H | R | O ] DBMS has to have a fs under it *somehow*,
even if just as a raw block device.
IF/AS/WHEN handing the *DBMS significantly complex work to do, and/or
managements of more complex rights and privs than the fs can manage
well, it can repay the overhead of its existence.
ELSE NOT.
At the end of about a year of fiddling, came to the conclusion that a
[*]DBMS is *not* generally suited to email storage.
For the most part, messages are write once, read once or twice, move
'maybe', then ignore forever-after. YMMV.
Not much place for a *DBMS to add value in that equation on the MTA.
An accompanying IMAPD has a bit of ongoing sorting and housekeeping to
do, but Dovecot, for example, does that well enough using the fs, even
when optioned to NOT use hardlinks.
Most of the rest - such as 'moving' messages into bespoke folders and
similar (re)organization based on various header or content criteria is
best done in the MUA, or MUA+IMAPD - not the MTA,
One size seldom fits all, so that seems a better solution than an
uber-configurable SQL (or whatever) MTA & mailstore.
See also the Opera browser's integrated MUA (DB backed store), and
PowerMAIL (the for-fee Swiss MUA, not the for-free RDBMS-based MTA).
Tried both of those and went back to SeaMonkey's MUA as a more solid
performer when the synced IMAP store is in the multi-GB range.
Overall, there is a putative 'DB-based' advantage in storing one copy of
a message intended for many recipients. But we just didn't find that
scenario to be all that common. Quite the reverse - it is seriously rare!
Even so, the fs can support that with hardlinks, so, still not much
opportunity for a *DBMS to add value.....*unless* your primary function
is extracting statistics. Data mining, IOW.
We stiil use PostgreSQL with Exim, but only for auth, user profiles and
preferences, Exim configuration options, acl and router/tranport set
content. Not for storage.
JM2CW,
Bill Hacker
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
