604182 - Thunderbird IMAP client should re-issue CAPABILITY if server does not include CAPABILITY in the tagged OK response of a successful AUTHENTICATE command

Status: RESOLVED DUPLICATE of bug 564642

(MailNews Core :: Networking: IMAP, defect)

Description

[Jesse Thompson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Build Identifier: 3.1.4

http://tools.ietf.org/html/rfc3501 - section 6.2.2

"      A server MAY include a CAPABILITY response code in the tagged OK
"      response of a successful AUTHENTICATE 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.

The RFC isn't precise about this, but I think that the client should send a separate CAPABILITY command if the server doesn't include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command.  Ideally, it would be nice if the server sent a CAPABILITY automatically, but it would also be nice if the client didn't assume that all servers will do that (because that is an incorrect assumption).

Reproducible: Always

Steps to Reproduce:
1. Client connects to server via TLS and server sends CAPABILITY.
2. Client authenticates and server does not send new CAPABILITY (it isn't required to).
3. Client does not send CAPABILITY command.
Actual Results:  
Client does not get an updated CAPABILITY from the server.

Expected Results:  
If the server did not include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command, then the client should notice this and issue a CAPABILITY command.

As a workaround, servers can hard code the enhanced CAPABILITY in the initial connect banner.  However, this is not desirable for services that proxy multiple IMAP servers with different CAPABILITYs.

Comment 1

[skurylo]

I'm using thunderbird 3.1.10.

We've started using perdition imap proxy, and by default it does not include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command.

Therefore thunderbird never knows the capabilities of the server.  For example IDLE does not work.

After changing perdition to include a CAPABILITY response code, IDLE now works.

I can produce NSPR_LOG_FILEs on request.

Thanks.

Comment 2

[Sergio.Gelato]

The RFC explicitly mentions at least one circumstance in which the AUTHENTICATE command should not include a CAPABILITY response in the tagged OK, and adds that

"    [SASL] requires the client to re-issue a CAPABILITY command in this case."

I've had a look at what it would take to fix this (so far only in the 3.1 code base; hopefully 8.0/trunk is not too different). It seems to me that one would want to add a PRBool to the nsImapServerResponseParser to keep track of when a refresh of capability information is desired, together with public getter and setter methods for it. The capability_data() method would then reset the flag whenever a new capability response is processed. nsImapProtocol::AuthLogin() (or its caller) could arm the flag just before authentication, then check whether it's still set after a successful authentication and call Capability() if so. Any comments about this plan?

I believe that bug 404323, which was somewhat controversially marked as a duplicate of bug 470650, is really identical with this bug instead.

Comment 3

[Nikolay Shopik]

Sound like dupe of bug 564642 for me