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 :-)
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | Nil desperandum
