[Imap-protocol] Fwd: ACL extension and unknown
guenther+imap at sendmail.com
Thu Mar 22 21:25:41 PDT 2007
On Thu, 22 Mar 2007, Dan Karp wrote:
> When you do a LISTRIGHTS and pass in an unknown principal as the
> identifier, is the correct response
> * LISTRIGHTS INBOX unknown-user ""
> A001 OK LISTRIGHTS succeeded
> or is it
> A001 NO LISTRIGHTS failed
I would say the latter is, for consistency with how SETACL with an unknown
user should behave. Returning NO to LISTRIGHTS doesn't tell the user
anything they couldn't figure out by trying something like:
tag SETACL mailbox unknown-user s
> Likewise, when the principal is fine but the mailbox doesn't exist
> or isn't visible, which is the correct response?
RFC 4314, section 4 effectively says that if you don't have the required
rights (as described by the table in that section), the server returns NO.
This is implied by by the text describing the exception to that rule:
LIST - "l" right is required. However, unlike other commands
(e.g., SELECT) the server MUST NOT return a NO response if it
can't list a mailbox.
So, doesn't exist -> NO. If you try to use LISTRIGHTS on a mailbox for
which you lack the 'a' right (c.f. that table in section 4) *and* the 'l'
right, then the server MUST return the same error as if the mailbox
doesn't exist: RFC 4314, section 6:
An implementation MUST make sure the ACL commands themselves do not
give information about mailboxes with appropriately restricted ACLs.
For example, when a user agent executes a GETACL command on a mailbox
that the user has no permission to LIST, the server would respond to
that request with the same error that would be used if the mailbox
did not exist, thus revealing no existence information, much less the
(If you have the 'l' right but not the 'a' right, then the server can give
some more helpful error message about permission denied, admin access
required, etc. Contriwise, if you have the 'a' right, you don't actually
need the 'l' right at all to use LISTRIGHTS, though it's hard to find a
real use case for that.)
> On a semi-related note, is there an issue with having a leading '/'
> on your other-users'-NAMESPACE prefix when '/' is also your
> hierarchy delimiter? I'd like to return the following:
> * NAMESPACE (("" "/")) (("/home/" "/")) NIL
I don't see why that would cause any problems. Do you have a particular
issue in mind beyond URLs?
> Would that cause issues with IMAP URLs?
Oof. Well, first off, a mailbox /home/foo/INBOX would have a URL of
Yes, two slashes, as the first slash is not part of the enc_mailbox
according to RFC 2192.
Now, the standard for URI syntax, RFC 3986, notes this:
If a URI
does not contain an authority component, then the path cannot begin
with two slash characters ("//").
(You can't do that because it would be ambiguous to parse, of course.)
That means that you cannot leave out the 'authority' component in relative
URLs for that mailbox above. Contrast a mailbox name that doesn't begin
with a slash, say, "INBOX", for which these are valid URLs:
imap://user@server:143/INBOX (absolute w/user + port)
//server/INBOX (relative, implied server)
imap:/INBOX (relative, implied scheme)
/INBOX (relative, implied scheme + server)
with that mailbox "/home/foo/INBOX", for which the last two variants above
are not available. That is, you can use these two:
but not these two:
(So what does "imap:INBOX" or just "INBOX" mean as an imap URL? Well, RFC
2192 doesn't say, but I presume that those would be relative to the
current base-URI. If your base-URI happened to be
then those would both refer to
...or at least that how I handle them. Alexey?)
More information about the Imap-protocol