Re: [bincimap] Maildir++

[Caskey L. Dickson]

Andreas Aardal Hanssen wrote:

On Thu, 20 Feb 2003, Caskey L. Dickson wrote:

Lee Daniel Crocker wrote:

etc.  Of course then some maroon would manually create a
directory "./.INBOX", and the code would blow up.  Of course
my code would have the same problem with "./:".

Even worse is that it is perfectly reasonable that when a user asks their client to create INBOX/foo/bar, that it create all the higher level folders as well, thereby completely innocently creating ./.INBOX, ./.INBOX.foo, ./.INBOX.foo.bar.
After all, if foo didn't exist already, one wouldn't be too far off in expecting it to be created for you.

If a user creates INBOX/foo/bar with the scheme you're all presenting,
then Binc would create only the ./.INBOX.foo.bar/ folder and not its
inferiors. Binc is smart enough to display the inferiors with \NoSelect in
LIST.

Yes, I agree that Binc would not create the superior folders, but *other* clients might see a request to create INBOX.foo.bar as a request to create (if not exist) INBOX, create (if not exist) INBOX.foo, and create (if not exist) INBOX.foo.bar, for a maildir++ client, it will happily create these folders.

We're certainly getting somewhere. We can allow root folders next to INBOX
by interpreting all folders called ./.<something> as such, but reserving
one special folder to be interpreted as a special "alias" for INBOX.

If we call this special folder "INBOX", that is, ~john/Maildir/.INBOX/,
then Courier-IMAP and any other Maildir++ clients would display this as
INBOX.INBOX/. Looks quite stupid, but that doesn't really matter to us. I'm curious to see how Courier interprets such a folder name.

I can tell you it lists it as INBOX.INBOX, because for courier INBOX is a namespace, not a folder. It's also different from INBOX which by itself means the INBOX mailbox, not the namespace INBOX. (Remember, it is only prepended that it is (supposed to be) considered a namespace.)

Binc IMAP would never create the actual folder called ./.INBOX/ as an
actual Maildir++ folder; it would only create inferiors like
./.INBOX.bincimap/ and ./.INBOX.Sent.2002.Feb.03/. If a seperate client
was to create the folder called ./.INBOX/ and that was a selectable
Maildir++ folder, then we need to make a decision as to what Binc IMAP
should do.

So what do you guys think?

 - As a root folder next to INBOX with a special name
 - As INBOX/INBOX (but what about ./.INBOX.INBOX/ ?

How about this - Binc could explicitly disallow a selectable root mailbox
(subfolder of the root Maildir) by the name INBOX. This means that if the
folder does not exist, Binc creates it and makes it \NoSelect with some
trick, such as removing the execute permission bits (Maildir++ says
nothing about that?).

The execute bit is the traversal bit and removing it will block access to the mail contents of the folder. Creating ./.INBOX and removing all permissions to it will most likely just create confuison if/when something tries to access it. I don't think we want people saying that Binc broke their mail store.

I think simply ignoring ./.INBOX/ is as good of a solution as we can get. That leaves only two special cases that must be dealt with in code:

1) INBOX <-> Maildir/ (the current situation)
2) (nothing) <-> Maildir/.INBOX/ (has no meaning and is ignored)

Maybe consider using an ALERT of some kind upon login/first LIST that there exists a folder that Binc is refusing to list. That way the user is informed in the rare case that something made the folder.

Binc will ignore CREATE INBOX, and CREATE INBOX.foo is handled by creating Maildir/.INBOX.foo/.

If it's there, then Binc could rename the folder and give it a new name -
this can be done safely by appending numbers.

>

The client could be informed with an [ALERT] notice - that means that
Outlook Express users would get a pop-up saying what has been done. The
sysadmin could be notified through logs.

Yiii, I'm wary of any solution that moves a folder automatically. What if the user uses two clients, one of which keeps putting it back.

Who would make a subfolder of INBOX called INBOX? The only thing I can
think of is subscribers to lists-bincimap trying to break Courier-IMAP. ;)

I don't know who would, but there's nothing in the RFC that precludes it, let alone INBOX.INBOX.INBOX. I think the solution you recommeded was a good one.

This is all courier's fault, they had to use INBOX. as the personal namespace and confused the whole issue. If they would have just stuck to #personal or #stuff or #$USER or *anything*, life would have been far easier.

C=)

--
--------------------------------------------------------------------------
Better the hard truth than the comforting fantasy. -- Carl Sagan
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
A presumption on your part does not constitute an obligation on my part.