60 lines
1.8 KiB
Plaintext
60 lines
1.8 KiB
Plaintext
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.
|
|
|
|
|
|
|