[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