>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.


Reply via email to