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

Re: set new-folder-format same-as-inbox broken?

>> Could it be that "set new-folder-format same-as-inbox" documented in >> 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.

Re: set new-folder-format same-as-inbox broken?

>> Could it be that "set new-folder-format same-as-inbox" documented in >> 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.

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

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

set new-folder-format same-as-inbox broken?

Could it be that "set new-folder-format same-as-inbox" documented in 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 sys

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 o

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

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

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 mail box that members of a group "info" can read and write to. -Postfix delivers messages to /var/spool/info (