On Thu, 13 Mar 2003, Andreas Aardal Hanssen wrote: > On Thu, 13 Mar 2003, Charlie Brady wrote: > >On Thu, 13 Mar 2003, Andreas Aardal Hanssen wrote: > >> Hey, Charlie! > >> On Thu, 13 Mar 2003, Charlie Brady wrote: > >But INBOX *is* special. It's special in two ways - both required by RFC > >2060. One is that all case permutations (inBoX, etc) map to the same > >mailbox, and the other is that it must be "the primary mailbox for this > >user on this server". If the system is running qmail, there is already a > >system default inbox - probably ./Maildir. So imapd should use the same > >path. > > Agreed that INBOX is special in the IMAP protocol, but that does _not_ > imply that it should be treated much differently in the file system.
Agred. > I beleive that having a direct mapping from Maildir INBOX/ to IMAP INBOX > is a good thing. I'd like to head your reasoning. This is what I believe. Each system has a defined "primary" mailbox for users. This mailbox is known as INBOX, inbox, and any other case permutation. Other than this one mailbox, all other mailboxes which the user may have are in one of three categories: - can't be addressed via IMAP (e.g the system wide imap root is set to ~/mail, but the folder is not contained within ~/mail) - can be addressed via IMAP, but are hidden by "INBOX". (e.g. ~/mail/Inbox) These are the ones you propose telling the admin about - I agree that's a good idea. - can be addressed and accessed via IMAP. > Any permutation of InBoX in the file system would be ignored if "." is a > Maildir, but if "." is not a Maildir then the first come first serve > principle would have to apply. > Again, the logs would inform the > administrator of ignored folders if a user has defined both INBOX and > Inbox. Here is one area where we differ. I think the logs should notify about both INBOX and Inbox. I see no reason that the primary mailbox of the user should be called INBOX in the file system. INBOX is a special IMAP name - on my system I want it to refer to the maildir ~/Maildir/. Both INBOX and Inbox maildirs will be hidden by INBOX, so I want imapd to ignore and report both of them. > >If, OTOH, we interpret "the primary mailbox for this user on this server" > >to mean the user-specific primary mailbox, then we have a difficult > >problem - we have to find that mailbox. We don't want to be reading and > >interpreting .qmail files to do that. We don't want to go there. > > We can assume that any administrator that wants to enforce this structure > on all his users would tell qmail-local to deliver to mail/INBOX/ by > default. We can further assume that any user who would want to enforce > this structure in an individual basis would be smart enough to update > .qmail. Perhaps. Nothing I've said precludes the primary mailbox from being configured to mail/INBOX/ - but I'd recommend the traditional ~/Maildir/ - it will look exactly the same to an IMAP client. > >> I want INBOX to be a mailbox just like all other mailboxes. > >It is, other than that it is the primary mailbox, which none of the others > >is. > > It's not like all other mailboxes in this schema if > > 1) Its name does not map 1-1 to it's LIST name in IMAP It doesn't need to. > 2) It does not recide inside a file system directory, rather its > "directory" is ".". "." is a file system directory. > 3) It is not a leaf node. It can be. And I don't think that it matters. Refer to my earlier discussion of maildirs within maildirs. > Dale suggested that ".", INBOX, and then "Maildir" be tested to find the > qualified IMAP INBOX. I'm proposing an alternative to the standard > depository using Dale's ideas, but allowing the entire mailbox depot to > reside in one location with no special cases. What I am suggesting doesn't preclude that. The policy for an installation can be expressed in two parameters - the INBOX location, and the root for mail folder location. These can overlap, or not overlap, as the admin chooses. Let's call these parameters A and B. The use of A should be obvious. It's where imapd should look for messages when INBOX is selected, etc. B will be the location to start looking for other folders. A wildcard list with show INBOX, plus all the folders found searching from B, *except* for any which will alias to INBOX once case is collapsed. > >> >[Why would "mail/INBOX/" be preferred to "Maildir/" for INBOX?] > >Did you have an answer for this? > > Yes, I did. As we have discussed earlier, Maildir++ adds Maildirs inside a > Maildir. This scheme suggests an alternative solution where all mailboxes > are standard (Not Maildir++) Maildirs, and organized in such a way that > there are no real special cases in the server when converting an IMAP > mailbox name to a filesystem location. I follow you so far, although I don't think the Maildir definition precludes other Maildirs inside. > > If I understand you correctly, what you don't like about this idea is > having to change Maildir/ being the equivalent of INBOX. Yes, any compulsory change goes against the grain. My motto comes from Einstein - "Keep it as simple as possible - but no simpler". Unless this restraint is necessary, then it should be avoided. I don't think it is necessary. > This you can do > in two ways. One - you can set Maildir/ to be your root depository, having > "." server as INBOX, and having the Maildir/INBOX/ folder be ignored. This sounds like A = Maildir/ and B = Maildir/ in my scheme. Maildir/INBOX would be ignored, as would Maildir/InBoX, etc. > Two - you can symlink your Maildir/ folder into mail/INBOX. You could, but I don't think it is necessary. Is this just to avoid telling imapd explicitly where the inbox is? I don't have any problem with giving imapd two pieces of information, because they are different. One is the location of the system inbox, and they other is the location of the user defined folder collection. These can be different, and I don't think we gain anything by constraining them to be sepecified by a single datum. > This would ofcourse mean that you would have to move your Maildir++ > submailboxes out of the actual Maildir/ folder and into the root of the > mailbox depository. Why? I haven't see any incompatibility between Maildir and Maildir++ which would make this necessary. -- Charlie
