> Wolfram A. Kraushaar wrote: > >>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 > > I had seen that link but it looked like a piece of code > that needs to be turned into CLI code :-) although I admit > a nice web interface would not hurt at all :-)
If you've got a MUA with IMAP ACL functions (i.e. SETACL/GETACL/LISTACL) like Mulberry you won't need any CLI or Web Interface code > >>-- 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) > > OK, this is something I dont quite understand either: What is the > big idea behind having to send the same message twice --once over > SMTP and once over IMAP just to have copy in the 'Sent' or 'Sent > Items' folder. Can't this be handled in the background without > the MUA being intelligent enough to cover for it? Well - storing sent messages usually isn't the job of the MTA but the MUA - that's the main reason for the IMAP APPEND Command. > Having to send the same thing really hurts if you're away on a > slow link... Is there no way to avoid this and still have a copy > of sent stuff in the 'Sent' folder? One way would be bcc-ing the sender at the MUA - maybe there're some knobs in postfix to get this done without interfering with the MUA. > I guess one needs to integrate a simple MTA (only to talk to MUA) > into DBMail in order to handle this and the BCC quirk, as well as > all those SMTP before POP and similar idiocies... Postfix is already very flexible - including MTA code into DBMail is not a good idea - this has been discussed various times on the list > And, regarding the hashing: Does DBMail do any hashing in order > to avoid duplicate messages across *all* users/mailboxes? > > http://www.dbmail.org/dokuwiki/doku.php?id=er-model > > the 'unique_id' field in dbmail_mailboxes table looks as if it > is there to make sure uniqueness /within/ an idividual user's > mailbox. Exactly, that's what the uid attribute is for. Regarding duplicates: A message sent to a distribution list will only be stored once in dbmail_messageblks and dbmail_physmessage. Every member of this list will only get a record in dbmail_messages referencing dbmail_physmessage.id. > >>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. > > I am not sure we mean the same thing. What I mean is this: I want to > be able to create shared folder(s) that contains mailboxes of other > users --just like directory soft/hardlinks. Ok, a user (e.g. with login name Bob) can share his Mailboxes to the #Users Namespace, so another User (e.g. Alice) can access it via #Users/Bob/Mailboxname if she has the IMAP ACL rights to access Bob's Mailbox. > And, these links should be able to display even the deleted/purged > items. That won't work (afaik that won't work in Cyrus/UW either) > Needless to say, these shared folders should be read-only. That's easily configured with dbmail_acl > The reason is simple, since anyone with a mail address can sent an > email to anyone else, inside or outiside the department/company, > the managers are simply left out of the game. > > While this sounds like freedom to Joe the Desk clerk, it infact means > that his manager --who is reponsible for policy etc.-- has no idea > what is going on unless there has been trouble ;-) This is true for corporate environments. Nonetheless if a manager has the time to review all mails of joe the desk clerk I'd suspect there's something wrong with the management. > Long story short: I wish to give managers a shared (read-only) folder > of the mailboxes That already works in dbmail. > (including the deleted messages That doesn't work in dbmail. > ) of the people he/she > manages. He/she then will have a better idea of what's going on under > his/her nose. There are multiple reasons for surveillance - IMHO they're a sign for lack of trust but that isn't the subject of this list :) In fact DBMail makes user surveillance very easy. > I'd like to be able to do that in DBMail and I'd like this to be > easier than > > http://www.dbmail.org/dokuwiki/doku.php?id=shared-mbox > > Am I asking too much :-) Except for the deleted Messages (which you may only retrieve by SQL right now): - It would work out of the box using Mulberry as MUA - Managing dbmail ACLs with some PHP/Perl/Java Interface should be a piece of cake (~2 weeks development effort for people with dbmail experience) Mike O'Brien told me that he includes ACL support in the next version of DBMail Administrator - maybe worth checking. HTH Wolfram
