> One thing I am interested in doing is this: > > Suppose some employer has left the company. What do you > do with his/her emails? Share it via IMAP ACL and NAMESPACE to other users - there's no need to copy them around.
> 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. give the other team members fine grained access privileges via dbmail_acl so his manager may delete messages and his colleagues may only view/copy the messages. > 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. imho shared mailboxes as mentioned before. > BTW, I am not --in any way-- suggesting that headers be > stripped off from the original blob. That would be a > mistake, IMO. jup > 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. There is not mail erased from the database if you don't run dbmail-util. Mails only get another status in dbmail_messages and are then cleaned by dbmail-util upon request (the status attribute in the dbmail_messages table determines the action of dbmail-util - check the description of dbmail_messages in the er-model). > I mean, even though the user has marked it deleted and purged > hence not visible to the user should remain in the storage. Thats already the case, if the administrator doesn't run dbmail-util. HTH Wolfram
