On Wed, 2010-08-04 at 14:04 +0100, pod wrote:
The case seems clear for STARTTLS; you advertise only non-plaintext AUTH mechanisms and LOGINDISABLED initially and after successful STARTTLS you can advertise plaintext AUTH mechanisms and remove LOGINDISABLED.
Yes.
I must confess I am having trouble untangling the precise meaning of the text related to AUTHENTICATE though.
Some auth mechanisms like GSSAPI and DIGEST-MD5 can add encryption/integrity protection to the stream. So in case of MITM attacks, the attacker could alter the CAPABILITY list before AUTHENTICATE, but not after it. I think RFC 3501 primarily talks about capability changing because of this.
RFC 3501 isn't fully clear that clients should update their capabilities when a CAPABILITY resp-code is sent on LOGIN, but this does strongly hint that:
A server MAY include a CAPABILITY response code in the tagged OK response to a successful LOGIN command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.