> Mathieu CATTIN wrote:
>
>> Hello, I would like to know if it is possible to use dbmail (
>> http://www.dbmail.org/ ) with exim
>
> Yes. But you might not want to do so.
>
> Long answer, 'coz this wheel has been reinvented too many tmes
> already.....
>
>> and if somebody can point me in the direction on how to configure exim
>> the right way for this.
>
> Routers, transports, and such (which I no longer have copies of), can
> allow use of DBMail with PostgreSQL DB format for UID/PWD checking
> and mail storage with Exim.
>
> We have also done the UID/PWD part,
> but not the storage, with Courier-MTA.
>
> Such should work essentially the same with MySQL.
>
>> Basically I want to use Mysql to store mails.
>
> This comes up often. Too often.
> SQL'ers (myself among them) tend to apply our 'hammer'
> to every 'nail' that comes along.
>
> Experience will show that it is seldom the best way to go.
>
>> Dbmail is capable of redirecting the mails via a called program in a
>> database,
>
> 'Capable' yes.
>
> Any dog is capable of 'grooming' contortions most humans wouldn't
> even *want* to attempt. So, too with applying the wrong tool to the job.
>
> MTA's in general, Exim in partiucular, and the storage methods they
> utilize most often are the product of several person-millenia of
> 'in use' experience worldwide.
>
>> I just didn't figure out the right transport/router to do it. Then I will
>> use dbmail to retrieve the mails with a MUA via pop3 or IMAP ( dbmail
>> accepts both with dbmail-pop3 and dbmail-imap which I already
>> compiled and tested and seems to work).
>
> 'Work' is the operative word. Storing message traffic in an SQL DB
> brings more problems than solutions for most 'real world' instances.
>
> Not to be negative - but:
>
> 'been there, done that, and my tee-shirt has bullet-holes in it'
>
> DBMail and PowerMail only have value in very specialized cases - even
> then,
> there may be more efficient ways of getting the same result.
>
> First, DB storage *way* more than doubles the server workload, as an RDBMS
> 'engine' does a lot more work to store (and prepare to 'manage')
> information
> than the 'raw' file system, then must *also* ultimately store its tables
> *IN* said file system.
>
> Don't forget he DB engine still needs an MTA (and POP and IMAP) with
> RFC-compliance, HELO/EHLO, STARTTLS, etc.
> - none of which can be implemented in SQL.
>
> Secondly, an RDBMS increases admin workload by an even greater amount.
> RDBMS do not automatically clean up after message recovery/deletion.
> A separate 'pack' and re-indexing must be done - at least as a chron job.
>
> This is especially true of POP, where a message is expected to go
> OFF the server when retrieved - may exist 'on box' for only minutes.
> Maildir's need no further attention as this occurs, DB-storage does.
> Bigtime.
>
> DB storage is better suited to IMAP, but even then, user deletion,
> not only of messages no longer of interest, but of whatever spam
> (SA flagged/scored, or not) has been stored for them mandates frequent
> DB packs. And/or managing 'deleted' flags where the message is NOT
> going to be deleted (corporate 'big brother').
>
> Third - storing headers, message body, and mime atachments within a
> relational DB is not as straghtforward as storing them in the file system.
>
> These are different animals as far as format, variable length, character
> encoding etc. - a serious challenge even to an Object DB, and can be
> poison to the regularly-structured Relational DB.
>
> Check the history of DBMail's gradual development in this regard, and
> note it has not been a 100% problem-free path, nor is it yet today.
> Note, too, that 'the other' DB-based MTA, PowerMail, chose to use
> the DB only for indexing, and stores the traffic in the fs.
>
> Otherwise - attachments alone can drive one into the 'least efficient'
> corner of RDBMS data types - the BLOB. And spam kills you.
>
> Side issue, but an important one - MySQL is not inherently
> 'transactional',
> PostgreSQL is. While not a double-entry accounting exercise, it IS
> important
> that messages believed stored or recovered are in fact 'fully completed'
> operations. While not usually a problem, MySQL does not inherently
> guarantee this under all circumstances, so for safety's sake, one should
> either patch on the InnoDB backend - or use PostgreSQL (Oracle, DB2 $$$)
> instead.
>
> Yet *more* work w/r configuration, maintenance, and CPU and I/O cycles.
>
>
> Recommendation:
>
> Use Exim set to create maildir's on the fly, Dovecot set to alter them
> for IMAP use if so invoked, and both interfaced to the same SQL DB
> (if you must) to store domain, UID, PWD, mailstorage type and location,
> (you can mix them - maildir for users, mbox for a per-domain archive).
>
> This will allow you to use any of dozens of web-based tools, with
> appropriate privilege levels in the DB, to support admin and
> end-user configuration, password change, etc.
>
> That, BTW is one of the only 'DB' advantages, and only slightly better
> than
> vpopmail with a php admin interface at that. (CAN be more secure, is not
> automatically so... PHP security is not *always* broken)
>
> Cleaning up and packing the DB after user deletions needs a 'pack' only
> once in a blue moon, and the DB calls for domain, UID/PWD and such are
> far 'lighter' than would be required to store and retrieve actual
> message content/attachments in the DB.
>
> Bottom line (from 2+ years of testing):
>
> Exim and Dovecot (among others) are highly optimized for message
> handling, and are two of the easiest tools to interface to an SQL DB,
> to each other, and to virus and spam tools.
>
> RDBMS's are general-purpose, and carry too much 'overhead', both in CPU
> and I/O cycles and storage space inefficiency for simple message
> traffic.
>
> - SQL DB's *can* provide a flexible means of storing UID/PWD, storage
> parameters, partly because there are so many available tools to allow
> 'safe' control from userland - but they have no patent on this, LDAP
> works too.
>
> - This is an inherently 'virtual' environment - not even one shell account
> needed once set up. Again, not the only way to get there.
>
> - conventional mbox remans best for for mailing lists, archives, other
> multiple-read, seldom-deleted use.
>
> - conventional (or enhanced) Maildirs remain best for all else -
> especially
> POP, and any other recover-once, delete-usually use.
>
> Either/both are 'leaner', faster, require less man and machine
> overhead, and are far more 'universal' across potential future changes
> or upgrades to MTA, POP, or IMAP daemons than SQL DB storage.
>
> These are THE 'road well traveled' by essentially all MTA, POP, IMAP
> tools - and with good reason.
>
> YMMV, but 'if it ain't broke....'.
>
> Bill Hacker
>
>
>> Specifications of my server : - Linux slackware (FREESCO v0.3.4
>> http://www.freesco.org) - Exim 4.50 (MTA) - Mysql 4.1.7 - DBmail 2.0.4
>> Thanks in advance, best regards, Mathieu CATTIN
>
>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim
> details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Well thanks, I did not expect what you're saying in your reply, that's an
answer I'll think about in many way.
Best regards,
phbc50
