112 lines
4.3 KiB
Plaintext
112 lines
4.3 KiB
Plaintext
MBOX-Line: From guenther+imap at sendmail.com Thu Mar 22 21:25:41 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Philip Guenther <guenther+imap@sendmail.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: <Pine.BSO.4.64.0703222133410.10752@vanye.mho.net>
|
|
|
|
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
|
|
|