Stephan Bosch wrote:
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.
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?
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.
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" "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?
Regards,
Stephan