On 26-Feb-2003 10:49 Andreas Aardal Hanssen wrote:
|
| Yup. But the filesystem doesn't say how INBOX/hello maps to the file
| system, and neither does Maildir. Since Binc IMAP currently uses
| Maildir++, and deviance would break interoperability with other Maildir++
| apps, I don't want that. But read on.
Well, I did open the discussion with a rather na�ve observation.
I'll have to pretend I understand how "INBOX/hello" should be used.
| > Some features are part of maildir proper (as per djb) and others
| > are extensions (Maildir++) made by Courier (any others?). Maildir
| > was designed for reliable mail delivery, while Maildir++ was designed
| > to extend (abuse) a Maildir to support an IMAP (+ other mail subsystems)
| > implementation.
|
| In what way does Maildir++ abuse the Maildir format?
Arguably, it defines an extension (for quotas) that breaks the original
intent of Maildir: lock avoidance.
| 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.
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?
| Can you sketch a scheme for us which allows for a consistent definition of
| how to create Maildir mailboxes in Binc IMAP, which is independent of
| Maildir++?
|
| 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.
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
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++")
regards.
--
-Dale
