Subject: Question about ManageSieve capabilities

From: Stephan Bosch <[email-masked]>
Date: Tue, 11 Aug 2009 10:21:40 +0200

Hello,

Recently, I noticed that it can be useful or even important to have the 
supported Sieve and ManageSieve capabilities depend on the authenticated 
user. Because the identity of the connected user is not known until the 
client authenticates, the capabilities reported upon connect and after 
authentication are going to differ.

Now I am wondering how to best implement a capability change upon 
authentication. According to section 1.8 of the draft, the capabilities 
are allowed to change after an AUTHENTICATE command, so there is no 
problem there. However, there is still the problem of reliably notifying 
the client that the capabilities have changed. After AUTHENTICATE this 
can happen with an unsolicited capability response directly after the 
command. However, the draft only mentions this in relation to the 
establishment of a SASL security layer.

Now I have a question:

Is the server allowed to send the unsolicited capability response after 
AUTHENTICATION also when just capabilities have changed and no SASL 
security layer has come into effect?

This may be an important notion, because client implementations may not 
expect this when it is not explicitly mentioned/allowed/prohibited in 
the specification.

So, for example, this is what I would like to do:

S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" ""
S: "VERSION" "1.0"
S: OK
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation relational copy date index enotify"
S: "MAXREDIRECTS" "10"
S: "NOTIFY" "mailto xmmp"
S: "VERSION" "1.0"
S: "OWNER" "[email-masked]"
S: OK "Logged in."

The alternative would be to rely upon the client to issue a CAPABILITY 
command. This is somewhat less reliable, as clients may refrain from 
doing so.

So, what's the best way to go here?

Regards,

Stephan

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Aug 2009 22:20:15 +0100

> Hello,

Hi Stephan,

> Recently, I noticed that it can be useful or even important to have 
> the supported Sieve and ManageSieve capabilities depend on the 
> authenticated user. Because the identity of the connected user is not 
> known until the client authenticates, the capabilities reported upon 
> connect and after authentication are going to differ.
>
> authentication. According to section 1.8 of the draft, the 
> capabilities are allowed to change after an AUTHENTICATE command, so 
> there is no problem there. However, there is still the problem of 
> reliably notifying the client that the capabilities have changed. 
> After AUTHENTICATE this can happen with an unsolicited capability 
> response directly after the command. However, the draft only mentions 
> this in relation to the establishment of a SASL security layer.
>
> Now I have a question:
>
> Is the server allowed to send the unsolicited capability response 
> after AUTHENTICATION also when just capabilities have changed and no 
> SASL security layer has come into effect?

I didn't think this should ever happen. (But to be frank I haven't 
thought about making the two SASL cases symmetrical.) My intent was that 
the client needs to reissue the CAPABILITY command explicitly if it 
wants to know about changes.

> This may be an important notion, because client implementations may 
> not expect this when it is not explicitly mentioned/allowed/prohibited 
> in the specification.

This can indeed be a problem for clients.
I suppose we can change the spec to allow for that, but this would need 
some information about how existing clients cope with this.