Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Oct 2008 17:34:29 +0100

Дилян Палаузов wrote:

> Hello,

Hi Дилян,

>>> Section 3:
>>>
>>>>         sieveurl-script = "sieve://" [ authority ] "/" scriptname
>>>
>>> * IMAP URLs made the mistake of confusing the identity used to 
>>> authenticate with the identity that owns the script.  This makes 
>>> IMAP URLs cumbersome. I would strongly encourage a naming model that 
>>> separates the two and keeps the script owner explicit.  For example:
>>>
>>>   sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname
>>
> What about
>    sieveurl-script = "sieve://" [ authority ] "/" [owner "/"] scriptname
>
> And missing [owner "/"] implies authentication ID = authorization ID

This might work. But I think this would also require that any "/" in the 
<owner> or <scriptname> be URL %-encoded. This shouldn't be a problem 
for existing deployments, because I don't think use of "/" in script 
names is common anyway (and some servers currently disallow it).

>> 1). opinions on whether you think this change is a good or a bad idea
>
> Good.
>
>> 2). if you know of any application using existing <sieveurl-script> 
>> form (with no "owner").
>
> I used kio_slave on my old computer some years ago, but to what I 
> remember as "root" I could edit only the global scripts, not the 
> users' ones. By enhancing the URI with owner-part, the "root" can 
> access anyscript by just changing the URI (and the client software 
> then issues an UNAUTHENTICATE/AUTHENTICATE commands to access it).
>
> Alternatively the URI could be "sieve://" [[ owner "@" ] authority]...

<authority> can already contain an optional name of the user the client 
should authenticate as.
I don't think sticking authorization identity (== "owner") would be 
syntactically valid according to the URI specification.

> As next one could think on a way how the "root" or any other who can 
> access the script of more than one person can retrieve the list of 
> script-owners, s/he has access to (in means of URI and protocol command).

This can probably be an extension.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Oct 2008 17:40:40 +0100

Kjetil Torgrim Homme wrote:

>On Sun, 2008-09-21 at 12:55 +0100, Alexey Melnikov wrote:
>  
>
>>Chris Newman has reviewed the ManageSieve document and sent me the 
>>following comment on Sieve URLs that point to scripts:
>>
>>    
>>
>>>Section 3:
>>>
>>>      
>>>
>>>authenticate with the identity that owns the script.  This makes IMAP 
>>>URLs cumbersome. I would strongly encourage a naming model that 
>>I agree with Chris, however I am concerned that there are existing 
>>applications using <sieveurl-script> form of Sieve URLs.
>>So I would like to hear from people:
>it might be a good change.  the URI specification as I read it does not
>mandate changes to the userinfo to indicate separate namespaces, but
>it's clearly allowable.  if we put authentication credentials in the
>"authority" (e.g., authz "=" auth ":" password "@" server), this will
>too create a new namespace...
>  
>
Hmm, this is something that no other URI scheme does. So I would rather 
avoid creating a separate syntax.

>oh -- I think the ManageSieve specification should disallow encoding the
>password as part of the URI,
>
As far as I remember the base URI document has already prohibited this 
feature, so I don't think we need to worry about this.

>or it needs to go the whole hog and specify how to encode SASL methods, the need for TLS etc.
>
IMAP URI document did this. I am a big believer in negotiating the best 
security using SASL and TLS, so I don't think there is any benefit.
Certainly not for SASL mechanisms.

>to make the owner an explicit part of the path itself is a clean and
>intuitively understandable solution, especially for listscripts when the
>user is authorised to edit the scripts of many owners.  the other
>alternative is to make it crystal clear that the userinfo component in
>authority indicates the owner, and authorization by other parties can
>not be encoded in the URI.
>  
>