On 21 Feb 2003, Peter Teichman wrote: >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."
It's Courier-IMAP's FAQ first and foremost. Courier-IMAP seems to require something from the client that is not in the unextended IMAP protocol to provide this. >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. So are you saying "keep it as it is", or "keep it as it is but _also_ allow root level folders"? Andy >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 >> > > -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
