On Sat, 8 Mar 2003, Andreas Aardal Hanssen wrote:
> > 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.
Only sort of, as we have discussed earlier.
> 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.
Or rather, not need to read many directories. I question how important
this efficiency is in the big scheme of things.
> It also provides a security feature by allowing the IMAP server to live
> totally isolated from the user's home directory.
The same could be provided by some other scheme.
> >| 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.
In the case courier flattening of directory heirarchies, there's more than
path mapping to do. The difference between scanning a single directory and
walking a directory tree implies quite a lot of code difference.
> > 1. Don't restrict the chroot() to a Maildir only.
> > 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.
"chroot" itself becomes problematic if you wish to have shared folders.
> > 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.
I think it would be wiser to have the local configuration fixed in a
config file than to try to guess local policy from the files and
directories which can be found.
> 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.
>
I believe I've answered this conundrum earlier.
A directory is a maildir if it contains subdirectories tmp, new and cur. A
maildir can contain other maildirs - even (if we are perverse) ones named
tmp, new and cur. When you delete a maildir, you delete tmp, new and cur,
and any messages contained therein, plus any additional administrative
files we've added (uidvalidity, maildirfolder, maildirsize). If the
directory is then empty, we delete it. Otherwise it stays, and is
reported by IMAP's list as \Noselect.
--
Charlie
