Re: when ought messages to get moved from spool to user's mbx INBOX?
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.
symbolic links to mailboxes and locking
Is it safe for several users to be accessing the same mbx mailbox via different symbolic links pointing to that mailbox? Assume that all users are doing this with c-client software, or even that all users are using imapd. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
simultaneous access to incoming spool file by c-client and postfix
Please consider 2 situations where messages are moved from spool files into mbx INBOX files in users home directories: A. c-client software automatically moves mail when software accesses incoming spool file. B. Someone explicitly invokes mailutil appenddelete. The question is: Can corruption of the incoming spool file arise due to conflicts with software (such as postfix) that is delivering mail to the spool file? If so, what measures should be taken to prevent this from happening? Thanks. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: symbolic links to mailboxes and locking
On Thu, 14 Apr 2005, Mark Brand wrote: Is it safe for several users to be accessing the same mbx mailbox via different symbolic links pointing to that mailbox? Yes. However, don't use NFS with mbx format. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
caching and mailbox synchronisation with c-client
Hi, I'm writing a headless imap client using c-client on WindowsXP. I have interfaced to all the mail functions and can successfully read mail messages from my uw-imap server (linux). Since the mail storage is handled by another application, with which my client communicates. The c-client code currently has no way of knowing what has already been downloaded. In such a case, what do I need to do to keep track and do proper synchronisation with the imap server? The imap server is also accessed by other applications (webmail, existing email clients like Outlook, Thunderbird,etc). I have never wirtten an imap client before, so I don't know whether I should be downloading all the headers every time, and ask the mailstore to compare, or do I need to write a cachemanager, etc. How do I determine that some messages have been deleted and expunged between two sessions, for example? If it makes any difference, the imap server is runnng with mbx format mailboxes. These mailboxes can be quite large, sometimes into the 100Mb+ range, with messages numbering in the thousands. I appreciate any ideas that might help. Hopefully some of you have encountered this situation before, and have asome good ides to suggest. Thank you for any help you might be able to provide. Mike -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: caching and mailbox synchronisation with c-client
As a first order approximation: You should have on record the UIDVALIDITY of the mailbox, highest assigned UID in the mailbox ever seen by the client, and UIDs of all messages. If the IMAP server reports a different UIDVALIDITY then what you have, dump your entire cache; it has been invalidated so you have to reload everything. Otherwise, if the UIDVALIDITY is the same, then identify new messages by doing tag UID FETCH n+1:* FAST (instead of FAST, you may want ALL or FULL or whatever else you would like to know about new messages at synchronization time). For n+1, substitute the highest assigned UID plus 1. For example, if the highest assigned UID is 4392, then do something like: tag UID FETCH 4393:* FULL and load your cache with the returned data. If you only get back one message, then that message is the highest-numbered UID message in the mailbox (not necessarily the highest UID ever assigned, since subsequent messages could have been deleted and expunged). Next, compare the number of messages you have cached with the number of messages reported by EXISTS in the response to SELECT. If this is different, the EXISTS value is probably smaller than what you have, meaning that many messages had been deleted and expunged (if EXISTS is larger, then you have a bug in your application since you failed to cache some old message). An easy way to determine what messages were deleted is to fetch the UID map of the old messages with tag UID FETCH 1:n UID (where n is the highest assigned UID as above). A slightly less chatty way to do this is tag UID SEARCH UID 1:n ALL. The UIDs that aren't returned are the ones that you need to remove from your cache. This is a pretty simpleminded mechanism. It's possible to do a lot better, particularly by observing that sequence numbers have no holes and that UIDs are strictly ascending; these are very useful properties. But learn to walk before you run is a good point here; start with something simple like this, and then try to make it fancier. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
