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. 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). I think dbmail should focus on being a high-performance, reliable, scalable message store. xn
