[Top] [All Lists]

Question about ManageSieve capabilities

2009-08-11 04:36:12


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: "SIEVE" ""
S: "VERSION" "1.0"
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SIEVE" "fileinto vacation relational copy date index enotify"
S: "NOTIFY" "mailto xmmp"
S: "VERSION" "1.0"
S: "OWNER" "richard(_at_)example(_dot_)com"
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?



<Prev in Thread] Current Thread [Next in Thread>