Re: possible imaprc.txt erratum
Mark, The text is correct. If INBOX is an empty file, it defaults to the system standard (which is traditional UNIX format on most systems, but MMDF on SCO). I see your point. Empty means empty in the sense of contains zero bytes rather than contains zero messages (since it describes a file rather than a mail folder). I was thinking that the passage neglected to specify what happens if the mail folder file INBOX does not exist, but then I realized that I was making another subtle misinterpretation. I think I grasp now that INBOX is the imap abstraction equivalent to the mail folder INBOX in $HOME or, when this does not exist, the incoming mail spool file. But still, even with this understanding, what happens if there is no INBOX at all? Mark
Re: set new-folder-format same-as-inbox broken?
Could it be that set new-folder-format same-as-inbox documented in http://www.washington.edu/imap/documentation/imaprc.txt.html does not work in imap-2004c1? I have done a bunch of tests with this and it seems to have no effect when the INBOX is in mbx format. It works for me. I just tried it. Note that an mbx-format INBOX must exist in order for this to work. Sorry about the false alarm. For some reason I can't reproduce the problem anymore either (still using Mozilla as client). The only difference I can point to between now and then is an update from Mozilla 1.7.6 to 1.7.7, but this seems like an impossible explanation. I'll assume that I made a mistake (several times) during my testing. Maybe the imap connection was persisting during the various versions of c-client.cf and the file is only read once when imapd starts (invoked by inetd). Still, I am puzzled because I restarted Mozilla several times intending to rule out this possible effect. Mailutil create is not affected by set new-folder-format same-as-inbox, but I think this is by design. Mark
Re: possible imaprc.txt erratum
But still, even with this understanding, what happens if there is no INBOX at all? That's where magic begins. You'll have to read the code in the dummy driver to understand. Now that you mention it, I had noticed a number of almost supernatural properties in imap. Probably because the documentation is otherwise so thorough, the omission of this case, slight as it is, sort of stands out.
set new-folder-format same-as-inbox broken?
Could it be that set new-folder-format same-as-inbox documented in http://www.washington.edu/imap/documentation/imaprc.txt.html does not work in imap-2004c1? I have done a bunch of tests with this and it seems to have no effect when the INBOX is in mbx format. (New folders are still in the system (Linux) default of traditional Unix) On the other hande set new-folder-format mbx works as expected. Here is my /etc/c-client.cf: I accept the risk # uncomment this if you want plaintext logins w/o ssl (a bad idea) set disable-plaintext nil # uncomment this if you want $HOME/.imaprc to work for individual users # set allow-user-config T # don't allow people to use .. and ~ in mailbox expressions (cleaner) # set restrict-mailbox-access all set new-folder-format mbx regards, Mark -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
possible imaprc.txt erratum
In the following passage of imaprc.txt, shouldn't the sentence If INBOX is empty, it defaults to system standard. read If INBOX does not exist, it defaults to system standard. 1) set new-folder-format sets what format new mailboxes are created in. This also controls default delivery via tmail and dmail. a) set new-folder-format same-as-inbox Folder is created using the same mailbox format as INBOX. If INBOX is empty, it defaults to system standard. b) set new-folder-format system-standard This is the default. Folder is created using the wired-in system standard format, which on most UNIX systems is ordinary UNIX /bin/mail format. On SCO systems, this is MMDF. c) set new-folder-format Folder is created using the given driver name, e.g. mbx, unix, mmdf, etc. regards, Mark -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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 --
