[Imap-protocol] Fwd: ACL extension and unknown principals/mailboxes

[Philip Guenther]

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
    mailbox's ACL.

(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 
something like:
 	imap://server//home/foo/INBOX

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)
 	imap://server/INBOX		(absolute)
 	//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:
 	imap://server//home/foo/INBOX
 	//server//home/foo/INBOX

but not these two:
 	imap://home/foo/INBOX
 	//home/foo/INBOX

(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
 	"imap://server/lists/imap"
then those would both refer to
 	"imap://server/lists/INBOX"
...or at least that how I handle them.  Alexey?)


Philip Guenther