As a Courier-IMAP user who also frequently goes to the (Unix) shell to search, modify & delete mail, I find the Maildir++ to be a bit awkward and the reverse of what I would expect (from the shell point of view). An "ls" in the Maildir produces all the administrative files (eg. courier* & sqwebmail*) and none of the mail folders (other than new, cur & tmp). I would much rather have this reversed so that all those administrative files have a leading dot and are not seen using a plain ls.
I would also like to go further and suggest making Maildir/INBOX be the default mail directory (rather than just Maildir). I know that this raises some compatability and migration issues, but I think that it leads to a much cleaner system. Furthermore, I believe that DJB is going to modify or introduce a new maildir with the next version of qmail (please don't start a discussion about when this will happen) that provides much cleaner support for IMAP (& chdir).
Regards, Henry
ps. I am watching this list to see if and when I should convert to bincIMAP. HB
On Sat, 8 Mar 2003 23:25:33 +0100 (CET), Andreas Aardal Hanssen <[EMAIL PROTECTED]> wrote:
Hi, Dale.
On Fri, 7 Mar 2003, Dale Woolridge wrote:On 26-Feb-2003 10:49 Andreas Aardal Hanssen wrote: | In what way does Maildir++ do anything to improve IMAP support for | Maildir? Part of the problem is in not treating a Maildir as precious and something that resides in directory tree leaves. Maildir++ includes the IMAP namespace to filesystem mapping. For example: http://www.inter7.com/courierimap/README.maildirquota.html refers to a _folder_ named "Important", which is a directory named .Important. Maildir++ adds the restriction that any Maildir++ directory must reside on the same filesystem as its subdirectories (subfolders). I'm guessing this is done to make the IMAP implementation easier.
Agreed, this is clumsy.
Maildir++ reads like it was designed hand-in-hand with a particular IMAP implementation in mind: i.e., it's not an extension to Maildir which happens to have a side effect of improving IMAP support. I think it places unnecessary restrictions on your IMAP server. How does Maildir++ benefit BincIMAP?
For our current situation, Maildir++ provides a unique mapping from IMAP mailboxes to file system directories and back again. It works very well with the way IMAP interprets submailboxes ( which sucks ;) ) and is efficient in that the IMAP server does not need to stat many files when the client issues LIST.
It also provides a security feature by allowing the IMAP server to live totally isolated from the user's home directory.
When all that is said - it does put more restrictions on IMAP than we need.
| This goes to everyone really - if Binc allowed the user or admin to define
| how mailboxes and submailboxes are created, we could have a special
| setting that was exactly Maildir++. User contributions could then allow
| maps to alternate paths.
1. Don't restrict the chroot() to a Maildir only.
That's a feature request. I'll add it to the list.
2. Recommend use of a non-top-level Maildir scheme so that chroot()
can avoid top-level. For example, recommend using ~/mail/Maildir
as the inbox & chroot ~/mail instead of ~/mail/Maildir. Some
systems may wish to chroot ~/Maildir though.
3. INBOX refers to . or Maildir or Mailbox { path = ... }, whichever
is the first Maildir
4. INBOX/hello refers to hello, hello/Maildir, hello/<Mailbox { path = ... }>,
or INBOX/.hello, whichever is the first Maildir
I like 4, it's the sort of design I'm looking for. This gives backwards compatibility while providing the features we want.
5. hello refers to (same as 4) except INBOX/.hello
6. Make the selection in 3-5 easier using a setting in Mailbox { }
(perhaps two types should be supported, type = "Maildir" and type = "Maildir++")
How would you suggest the response from LIST? For mbox purposes, LIST
returns an actual listing of all items in the home area, and lets the
client choose what to subscribe to. We would need a consistent mapping
back from the file system representation and 1-1 to mailbox names that can
be pushed back to the client.
Ok, we are definitely getting somewhere.
We also need to find a way to define what happens when the client issues these commands. Shouldn't bee too difficult.
CREATE private CREATE private/kids CREATE INBOX/work CREATE INBOX/work/contracts
Obviously, these semantics have to correspond with what LIST reports. It does not have to correspond with Binc's current behavior, though, as long as existing clients don't "break".
Also, I hate to mess things up but this is also a requirement in the IMAP protocol which makes it hard for us to use "true" filesystem subdirectories to represent the same kinds of multilevelled IMAP mailboxes:
From 6.4.3 of rfc2060 for your convenience:
The DELETE command MUST NOT remove inferior hierarchical names. For example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." is the hierarchy delimiter character), removing "foo" MUST NOT remove "foo.bar". It is an error to attempt to delete a name that has inferior hierarchical names and also has the \Noselect mailbox name attribute (see the description of the LIST response for more details).
It's in other words not the way the unix file systems work. This has been
solved in Maildir++ by storing the mailboxes in one level only. The IMAP
server then "emulates" the superior mailboxes if they do not exist and
sets "\NoSelect".
It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute.
and:
The value of the highest-used unique identifier of the deleted mailbox MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
Andy :-)
-- Henry Baragar
