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" "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