I disagree with that interpretation. The FAQ is saying that an inability to create folders that are peers of INBOX is a client deficiency, not that "if folders appear as subfolders of INBOX this is due to a deficiency in the IMAP implementation of your client."
Anyway, if this thread has done nothing else it has shown that people are very tied to their particular mail setup. My intent is not to continue arguing the merits of either setup we're discussing, but to inform Andreas that I would like an existing tree to be exported in the same way it is now at the IMAP level. Peter On Fri, 2003-02-21 at 10:54, Charlie Brady wrote: > On Fri, 21 Feb 2003, Peter Teichman wrote: > > > This would retain filesystem-level compatibility with Courier but not > > IMAP interface-level compatibility, no? > > > > I greatly prefer that my folder tree looks the same whether exported by > > Courier or Binc. Also, one of my main mail clients, Apple's Mail.app, > > really likes having all folders to be subfolders of INBOX. > > According to the Courier FAQ quoted earlier > (http://www.courier-mta.org/FAQ.html) , if folders appear as subfolders of > INBOX this is due to a deficiency in the IMAP implementation of your > client. > > Q: Can't create folders, only subfolders of INBOX > > This is a configuration issue with your mail client. > ... > If you have to explicitly create folders that are subfolders of INBOX, > or if you explicitly have to name that "INBOX.foldername", this is due > to your IMAP client not being able to configure itself accordingly. > ... > Submit an enhancement request to have your IMAP client gracefully handle the folder > namespace root. > > This raises important issues wrt Courier compatibility. This suggest to me > that some IMAP clients will be displaying the folder which Courier saves > to disk as ./.INBOX.Foo as simply "Foo", using the implied namespace > "INBOX." which the client learns from the server, while others will > obviously display the folder as INBOX.Foo. Moreover, since Bincimap > doesn't advertise NAMESPACE, those same clients won't know to use "INBOX." > as a prefix for folder names, and won't translate "Foo" to "INBOX.Foo" > when selecting folders. > > If Bincimap were to support NAMESPACE, would it revert to the recommended > "#personal", or would compatibility with Courier's perverse "INBOX" be > required? > > But maybe I'm being too harsh with Courier - the "INBOX" namespace is one > of the examples used in RFC2342: > > Example 5.5: > =========== > > < A server that supports only the Personal Namespace, with a > leading prefix of INBOX to personal mailboxes and a hierarchy > delimiter of "."> > > C: A001 NAMESPACE > S: * NAMESPACE (("INBOX." ".")) NIL NIL > S: A001 OK NAMESPACE command completed > > < Automatically create a mailbox to store sent items.> > > C: A002 CREATE "INBOX.Sent Mail" > S: A002 OK CREATE command completed > > Although typically a server will support only a single Personal > Namespace, and a single Other User's Namespace, circumstances exist > where there MAY be multiples of these, and a client MUST be prepared > for them. If a client is configured such that it is required to > create a certain mailbox, there can be circumstances where it is > unclear which Personal Namespaces it should create the mailbox in. > In these situations a client SHOULD let the user select which > namespaces to create the mailbox in. > > > > -- > Charlie Brady >
