From: "Jesse Norell" <[EMAIL PROTECTED]> > > Right - we're working on the dynamic caching because with us being > > too lazy to change dbmail to handle it itsself, that's the only > > practical option available. The only reason to add that to the pop3/ > > imap daemons would be for seemless migration (all new messages get > > cached at injection time, old messages happen as needed). It may > > be easier just to write that into dbmail-maintenance though, and > > when you update from the old non-header-caching setup to the new, > > you just have to run dbmail-maintenance to fix things up. > > Adding that support to dbmail-maintenance is probably not a bad > idea. Put the list of "interesting" headers in dbmail.conf and run > the maintenance program to bring the header cache up to date. Then > if you change your list of what is interesting, just run > dbmail-maintenance again (to both add in new and delete out old > headers).
What is the advantage of adding this list to dbmail.conf rather than to a "interesting_headers" lookup table that is inside the database. Putting it in the database has several advantages: a) an application that has access to the database but not to the dbmail.conf file can see the list. b) the list can be joined with tables and used to enforce integrity checks etc... c) easily updated via sql. I think dbmail.conf should be used for external settings such as database name, port number etc etc etc... I think settings that effect the internal structure of the application should be stored in the database.
