Aaron Stone wrote:
Writing an MTA something like opening Pandora's box. Well, except that
Pandora's box will ravage humanity quickly and if you survive that, you're OK.
An in-house MTA will haunt you for years to come.
Postfix is one of the best MTA's out there, and is likely the very easiest to
configure. If you give DBMail another shot, then decide that it sucks, there
is one line in one configuration file that will change your mail store.
The problem that I have with DBMail goes beyond inaccurate (dare I say
broken?) Postgresql setup docs.
DBMail requires me to make *more* and to boot, *more complex* manual
changes to, for example, Sendmail files than I would have to make with
friendlier toolsets to, the commonly used but definitely 'kit built'
Qmail+patches+Courier-IMAP+VpopMail+SquirrelMail+<whatever>...etc.
-just to name one..
Though, in fairness, fewer manual edits than I would have to make to,
say the 'full' courier-mta package.
Granted, Postix (sendmail.exe on my Warp 4.5 boxen) is easier, and so
too would Exim perhaps be... not all possible settings need to be
touched. But neither of these, nor Sendmail, have their own IMAP or
necessarily even POP3, so it is back to 'kit building'.
...And I am still open about whether a DB-driven mail system needs to
store the full text and headers of messages in the DB (DBMail) or index
them on the fs (PowerMail).
But I am *adamant* about this much:
IF I am going to utilize an RDBMS for mail *at all*, THEN I want it to
'earn back' its overhead by:
A) Making use of capabilities it has that a raw fs does not have.
B) Reducing - dramatically - the complexity required of any external
smtpd, imapd, pop3d functions and the need for them to be externally
configured.
C) *optionally* facilitating the ability to run 'filter' and
'modification' processes (spam, antivirus) asynchronously, in parallel,
and in any case 'decoupled' from input data streaming.
Mind - having the DB spit out a flat file or hashed mini-DB is fine -
hostname, smtp-relays allowed, etc. don't change all that rapidly and a
SELECT for those should not be needed for every message...
If you realize that your in-house MTA has taken over your life, and it
sucks... changing to something more common and better supported will take
hours and the behavior may change causing your boss to lose his email. Double
sucks.
Fortunately, I *am* the boss in question <G>....
..remains to be seen if my coding skills (ISAM databases in Z-80 FORTH)
and DB design skills (DB2, RBase, Oracle, PGSQL) are still up to it <G>
I'm not trying to FUD you into using DBMail; just FUD you out of trying to
write your own MTA. It's just not a good idea. Even DBMail was considering
doing our own MTA, so that the entire stack would be ours, but then we saw the
light.
But it left you betwixt and between.... no advantages.
DB-driven 'PowerMail' is arguably faster, DB-less* Courier-MTA more
feature-rich, right-off-the-ports-tree DB-less* Qmail++++ quite secure,
more easily installed and configured - not to mention hard to beat for
raw performance. (*Db-less save, optionally, for authentication)
But, all that said, best of luck on your project, should you really go for it!
Aaron
Haven't much choice, as we are heavily CMS oriented these days, and are
already getting more and more DB-driven. Getting mail into and out of a
DB we are already 'connect' ing to (both PGSQL and ZODB) is attractive
when we can get single-login and single configuration input.
Will revert (shortly) to courier-mta for the interim, PITA that it is to
configure.... Haven't the desire to even try to keep Qmail current...<G>
Thanks and regards,
Bill
Bill Hacker <[EMAIL PROTECTED]> said: [snip]
But it is no longer important - I have gone ahead and looked at the
*rest* of DBMail and no longer have any interest in it...
We had started to write an SQL-based MTA just one day before finding
DBMail, which we did not realize was just a MySQL mailstore that relied
on an external MTA + more-obtuse-than-usual configuration & re-make of
said MTA...
It will be cleaner and easier to do one properly from a cold start.
