My variation on mail headers - make this optional. It adds no value for
packaged mail clients; offers terrific value for purpose built dbmail
(probably web mail) clients. Since I'm writing a webmail client in Python
right now, its on my mind. Re-parsing the headers is a minor pain but a
major pain when the user / mail count is very high.
Even nicer than a binary on/off option for writing to a mail_headers table
would be a configuration file driven mail_headers table. Some might only
want a subset of the headers, some may want all.
I suspect I know why this was left out - things get a little more
complicated when a header has multiple values. For instance, multiple To,
Cc destinations. Its hard to guess what someone writing a client will
prefer, hence some config file driven customizability [sic] seems in order.
At 10:31 PM 9/11/2002 +1000, you wrote:
4. Nice-to-have: break up mail headers into a table
---------------------------------------------------
ie. parse the mail headers and store (a copy?) in a separate table. eg.
Create Table message_headers(id, message_idnr, header, value) might contain:
<unique-id>, <message-id>, 'to', '[EMAIL PROTECTED]'
<unique-id>, <message-id>, 'from', '[EMAIL PROTECTED]'
etc.
