> I would prefer the shared folder metaphor --that way no one gets > confused as to who has sent what to whom. Plus, they can be made > read-only. have a look at
http://www.dbmail.org/dokuwiki/doku.php?id=shared-mbox > -- Any message sent or received should be hashed and stored as unique > blob in a pool, common storage (RDBMS, file sytem, cluster etc.). That's the case with dbmail - well, sent mails only if you configure your imap clients to store sent mails in some folder on the imap server. (MS Outlook can't do this afaics) > -- Users should simply have pointers to the messages. That's the case with dbmail. > They should not be able to erase the actual message even though they > have 'deleted' and 'purged' it. They will simply end up deleting the > pointer: That particular message will not be visible to the user. > That's all. That's the case with dbmail. > Since *all* messages are in one single storage, an admin can > reconstruct a user's mailbox, if the need arises, without > much load on > the system (CPU, storage etc.). That's the case with dbmail. > Having such a storage back end with pointers enables the admin to have > a shadow mailbox structure(in the british sense of shadow cabinet) > without much effort. That is, of course, if DBMail had the > functionality built in. It has this functionality built in by using the status attribute of dbmail_messages. HTH, Wolfram
