56 lines
2.2 KiB
Plaintext
56 lines
2.2 KiB
Plaintext
MBOX-Line: From dave at cridland.net Thu Sep 14 00:58:06 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:37 2018
|
|
Subject: [Imap-protocol] what if / were my server's "home directory"?
|
|
In-Reply-To: <20060914060431.GA15997@penne.toroid.org>
|
|
References: <20060914060431.GA15997@penne.toroid.org>
|
|
Message-ID: <8267.1158220687.012298@peirce.dave.cridland.net>
|
|
|
|
On Thu Sep 14 07:04:31 2006, Abhijit Menon-Sen wrote:
|
|
> Our IMAP server uses a conventional mailbox hierarchy, where each
|
|
> user's
|
|
> "home directory" is /users/name (that is, an empty reference
|
|
> argument to
|
|
> LIST is intepreted as /users/name), and a user's personal mailboxes
|
|
> may
|
|
> be accessed either as foo or /users/name/foo.
|
|
>
|
|
> What would happen if we started interpreting an empty reference as
|
|
> "/"?
|
|
>
|
|
> That is, every mailbox would have just one name. /users/foo/bar, or
|
|
> /archives/imap-protocol, or whatever. Would clients be able to cope
|
|
> with not being able to "CREATE Drafts" or whatever? (I'm told that
|
|
> isn't possible with Cyrus anyway, so it should be OK, but I haven't
|
|
> tested.)
|
|
>
|
|
> Does anyone see a problem with such a layout?
|
|
|
|
In terms of the protocol, no (although if you don't support
|
|
NAMESPACE, there shall be much gnashing of teeth).
|
|
|
|
However, in practical terms, there are some clients (The variant of
|
|
Outlook for Pocket PC springs to mind, although that could be an
|
|
older version) that expect to be able to create a slew of unqualified
|
|
mailbox names "CREATE Drafts" included. These then exhibit Strange
|
|
And Fearsome behaviour when they can't.
|
|
|
|
Although it's true that with Cyrus IMAP, the default is that the
|
|
user's own heirarchy begins at "INBOX.", I used to switch (with
|
|
altnamespace) so that user's mailboxes were at the top level as a
|
|
routine when installing servers, in order to ensure it worked with
|
|
these broken clients.
|
|
|
|
The clients *are* against specification, of course, but the fix for
|
|
them is also within specification, so I'd generally lean toward at
|
|
least having an option such that they work.
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|