Paul J Stevens wrote:
This is already in progress in the 2.1 code. The database layout
> in the current implementation is described in:
http://www.dbmail.org/dokuwiki/doku.php?id=headercache
Thank you for the link.
While there is dbmail_ccfield, I did not see a dbmail_BCCfield
table mention.
OK, messages received from MTA does not contain addresses for
BCCs, but does not DBMail have an actual record of the message
so that BCC can parsed out too?
listmember wrote:
One further application I have in mind is tracking
or charting email traffic in a corp environment.
Boyoboy, there's a can of worms.
There definitely is. It isn't as if it was not possible
before --except maybe a little harder.
One thing I am interested in doing is this:
Suppose some employer has left the company. What do you
do with his/her emails?
Time and lack of manpower make it impossible to go through
his/her emails and sort out which ones were private and which
ones need to be distributed other members of the team.
So, all you can do is do a very fast search for known sources
of senders (customers and people) and either copy those
messages to other users or simply assign them to other users
(by assign, I mean do a SQL update on the underlying tables).
In order to be able to do some of this, one needs that can
of worms thing --or is there a better way.
BTW, I am not --in any way-- suggesting that headers be
stripped off from the original blob. That would be a
mistake, IMO.
One further thing [though this thread may not be perfect
to ask it, I'll ask anyway :-) ] Is there already a
functionality in DBMail that --whatever the user action--
*no* mail is actually erased from the mail storage.
I mean, even though the user has marked it deleted and purged
hence not visible to the user should remain in the storage.
I know this is another can of worms, but one that is very
importnt in a corp env.
Cheers,
