Use of the CAPABILITY command - IMAP

On Tue, 17 May 2005, Scott Lowe wrote:
> Is it part of one of the RFCs somewhere that states that an IMAP4 client
> MUST issue a CAPABILITY command before attempting to login? I ask
> because I was wondering if a non-compliant IMAP4 client might keep
> sending LOGIN statements (passing information in clear text) because the
> server had not yet been given the opportunity to advertise STARTTLS
> and/or LOGINDISABLED.

An IMAP2 (RFC 1176) client would likely do that, since IMAP2 had neither
SASL nor TLS.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On 2005-05-18 02:14:04 -0400, Mark Crispin <mrc@CAC.Washington.EDU> said:

> On Tue, 17 May 2005, Scott Lowe wrote:
>> Is it part of one of the RFCs somewhere that states that an IMAP4
>> client MUST issue a CAPABILITY command before attempting to login? I
>> ask because I was wondering if a non-compliant IMAP4 client might keep
>> sending LOGIN statements (passing information in clear text) because
>> the server had not yet been given the opportunity to advertise STARTTLS
>> and/or LOGINDISABLED.
>
> An IMAP2 (RFC 1176) client would likely do that, since IMAP2 had
> neither SASL nor TLS.
>
> -- Mark --

Thanks for the prompt response, Mark. I was testing an IMAP4 proxy
that uses STARTTLS and wondered about clients inadvertently passing
login information before securing the session with STARTTLS.

--
Scott Lowe

On Wed, 18 May 2005, Scott Lowe wrote:
> Thanks for the prompt response, Mark. I was testing an IMAP4 proxy that uses
> STARTTLS and wondered about clients inadvertently passing login information
> before securing the session with STARTTLS.

You can't prevent it from happening. There are numerous pre-TLS clients
that do not respect the LOGINDISABLED capability. STARTTLS was moved into
the base specification and made mandatory-to-implement by IESG decree in
RFC 3501, but that was only two years ago.

There is a hope that, if the server advertises a SASL mechanism that the
client knows, the client will not attempt a LOGIN command. But if the
SASL mechanism is PLAIN, that doesn't really help matters.

A similar problem exists in POP3. Very few POP3 clients check the CAPA
command to see if there is a USER capability.

To make things worse, there are POP3 servers out there which omit the USER
capability but still expect the client to issue a USER command. The
vendors of those servers claim that it is a "client bug" to obey the
specification and not send a USER command.

Consequently, the only thing that you can do is cause all unencrypted
password authentication attempts to fail. Even though the user is still
disclosing his password, the fact that he doesn't get any service will
hopefully motivate him to seek help, and thus ultimately get his client
reconfigured or replaced.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.