>I have a question, or maybe I just need some advice. Consider this >situation please: > >-There's a user called "info". The purpose of the user is to receive >mail that will end up in a shared mailbox that members of a group >"info" can read and write to. >-Postfix delivers messages to /var/spool/mail/info (traditional unix style >text file) >-An mbx INBOX exists in /home/info (created by mailutil create >#driver.mbx/INBOX) >-Another user, Sam, has a symbolic link: "/home/sam/mail/info" pointing >to "/home/info/INBOX". ... > >... > >..if Sam uses imap to subscribe to the symbolic link and read >messages, this act does NOT result in magically moving new messages from >/var/spool/mail/info /home/info/INBOX. (My ugly workaround for the time >being is a cron job that does the moving with mailutil.) > >
Thanks to Eduardo Chappa for explanation and discussion of better strategies to get incoming mail into an INBOX meant to be shared and accessed by multiple users at the same time. Here's a summary, in case someone else is trying to do the same thing. The behavior of c-client which moves mail from the incoming spool file to INBOX in the home directory is triggered by accessing the spool file. It therefore makes perfect sense that reading mail from a symbolic link pointing to the INBOX in the home directory won't trigger moving. A better strategy uses procmail and dmail to allow postfix to deliver incoming mail to the mbx INBOX. (Postfix by itself does not know how to write to mbx files.) I installed the dmail binary built from the imap kit into /usr/bin. I then made .forward and .procmailrc in /home/info. The .forward contains: "|/usr/bin/procmail" The .procmailrc contains: :0 fw |/usr/bin/dmail +INBOX As Mark Crispin pointed out later, postfix can also use tmail to deliver mail to mbx mailboxes (without having to use procmail). I have not been able to evaluate yet whether the tmail approach would be better suited to my situation.