MBOX-Line: From alexey.melnikov at isode.com  Sun Mar 25 13:52:26 2007
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] Fwd: ACL extension and unknown
	principals/mailboxes
In-Reply-To: <1317989450.37761174613317672.JavaMail.root@dogfood.liquidsys.com>
References: <1317989450.37761174613317672.JavaMail.root@dogfood.liquidsys.com>
Message-ID: <4606E10A.6010009@isode.com>

Hi Dan,

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
>  
>
If you want to prevent disclosing if an identifier exists, then you can 
pretend that the user exist and return some default rights in the 
LISTRIGHTS response.
However the LISTRIGHTS command already requires that the client has the 
"a" right, so there might not be any point in hiding this information.

Otherwise I think both responses are Ok, I have slight preference for 
the former.

>Likewise, when the principal is fine but the mailbox doesn't exist
>  
>
Our server returns NO in this case.

>or isn't visible, which is the correct response?
>  
>
If the current user doesn't have the "a" right, the server should always 
return NO to the current user.
The "l" right is not relevant for the LISTRIGHTS command.

>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
>
>Would that cause issues with IMAP URLs?
>
This is only an issue in relative URLs. The latest 2192bis draft adds a 
requirement that leading slashes be %-encoded in relative URLs.



