[Dovecot] Dovecot 2.0.rc3 Capability response
Timo Sirainen
tss at iki.fi
Wed Aug 4 16:47:25 EEST 2010
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.
More information about the dovecot
mailing list