Christian G. Warden wrote:
On Fri, Nov 21, 2003 at 01:19:56PM +0800, Bill Hacker wrote:
That is a whole lot easier to implement that the approach I just posted.
But may have to be re-implemented as the external MTA or toolsets change..
- It also tends to leave us with a system where all we have really
done is replace Maildirs or Mboxes with an RDBMS for message and
configuration storage.
i.e raw or structured file sytem storage vs RDBMS for storage doesn't
really maximize the available RDBMS tools...
..and we are still utilizing conventional queues, pipelines, *whatever*
of the legacy MTA world, with attendent delays in the I/O.
Why not simply get the messages straight into the DB, then apply the
filtering as a separate process before flagging the message as
'available' to the POP or IMAP client?
There is a lot of filtering that you may want to do during the SMTP
dialog such as spam filtering, virus scanning, and various other policy
checks on messages.
ACK. Most efficent place to do that empirically. But I am willing to
try another way in the interest of non-blocking I/O and the certainty of
100% logging.
> There may also be filtering that redirects messages
to other hosts in which case it makes sense to keep messages within the
control of an MTA, and only hand messages off to dbmail for final
delivery (final, neglecting subsequent pickup by a POP/IMAP client).
It makes sense. It seems optimal. It is not the only way, and in the
big picture may not even be the best way for all circumstances.
Suppose you are an enterprise site and have a requirement for a
permanent record of all traffic. Logging is simpler if the mailstore
*is* the log.
I think dbmail should focus on being a high-performance, reliable,
scalable message store.
xn
Fortunately, these goals are by no means mutually exclusive...
But the "high performance, reliable, scalable" (whatever) "store" is
called a file system. <G> In any of its flavors a fs *is* a database in
its own right, and the DB engines we use have to impose a different
style of DB on top of it. In order to recover that translation
'overhead' we need to get advantages out of the DB engine that we cannot
easily get directly from the fs.
Better security and easier configuration can probably be taken as
"stipulated" in favor of the DB engine. High performance is another matter.
A 'Database Management System' can only compete on performance with the
raw fs when there are *complex and/or difficult to predict* tasks or
manipulations to be performed on whatever is being stored. Ordinary
indexed storage, i.e. store/retrieve w/o alteration, w/o sub-selects,
w/o ordering, w/o complex WHERE clauses, etc. is not really its best
suit of clothes, 'coz the right fs does those things pretty well as is.
The better ones are even transactionally aware.
For my part, IF I am to use a DB at all, I want it to earn its place at
the table, not just do raw storage + a bit.
As the two approaches don't get in the way of each other, (extra flags
are ignored) I hope both methods get some attention.
Bill Hacker
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
