404323 - IMAP server capabilities not rechecked after login

Status: RESOLVED DUPLICATE of bug 470650

(MailNews Core :: Networking: IMAP, defect)

Description

[Duncan Brannen]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: 2.0.0.0.9

We've multiple backend IMAP server fronted by a proxy which looks up the users
server.  We've been getting strange behaviour with thunderbird sending 
a list "" "~|mail|%"
instead of
a list "" "~/mail/*" 
and so being unable to list / subscribe to folders , move messages between folders.  It doesn't seem to affect all users, in fact it only affects a tiny
percentage (2-5%) Using a different client or connecting directly works.

The problem seems to be that thunderbird sends the
1 capability
command before the user logs in and doesn't get the correct set of capabilities,
in fact it only gets CAPABILITY IMAP4 IMAP4REV1 STARTTLS sent back.
Thunderbird doesn't then ask for the updated capabilities after login


Reproducible: Always

Steps to Reproduce:
Turn on logging, run thunderbird, watch the traffic.
Actual Results:  
36108288[17bf8150]: ImapThreadMainLoop entering [this=276c400]
-1610559488[1a071a0]: 276c400:imap.st-andrews.ac.uk:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:ProcessCurrentURL: entering
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:ProcessCurrentURL:imap://[e-mail]:143/discoverallandsubscribedboxes:  = currentUrl
36108288[17bf8150]: ReadNextLine [stream=17bf8a58 nb=35 needmore=0]
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:CreateNewLineFromSocket: * OK IMAP4 Ready imap 0001e274
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:SendData: 1 capability
36108288[17bf8150]: ReadNextLine [stream=17bf8a58 nb=39 needmore=0]
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4REV1 STARTTLS
36108288[17bf8150]: ReadNextLine [stream=17bf8a58 nb=17 needmore=0]
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:CreateNewLineFromSocket: 1 OK CAPABILITY
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
36108288[17bf8150]: ReadNextLine [stream=17bf8a58 nb=20 needmore=0]
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:NA:CreateNewLineFromSocket: 2 OK You are so in
36108288[17bf8150]: 276c400:imap.st-andrews.ac.uk:A:SendData: 3 list "" "#mh/%"


Expected Results:  
After login, having not received any updated capability results in the 
'OK you are so in'
login result, another 1 capability command should be sent.


Not sure whether this is normal or minor, there's an easy work around, to tell
the proxy server what capabilities to advertise in advance but since our servers
support different capabilities, this mean hobbling some of them to support others.

Thanks for any help.

   Duncan

Comment 1

[Duncan Brannen]

This seems to be linked to
https://bugzilla.mozilla.org/show_bug.cgi?id=401293
In that it affects the same Networking : IMAP component
and is to do with whether option response codes are in the headers, although
in this case it's the post login header rather than the greeting.

Comment 2

[Nikolay Shopik]

This is violates RFC 2060 (6.1.1.) which clearly says:
This listing of capabilities is not dependent upon connection state or user.

Comment 3

[Duncan Brannen]

RFC 3501 obsoletes 2060 and doesn't have that restriction.

After a STARTTLS, for example, the RFC (3501) states the client MUST reissue a capabilities command and also that it doesn't have to after an AUTHENTICATE or
LOGIN if it recognises them in a tagged OK response, which could imply it should.

  I'd thought I'd seen something saying that capabilities could be user
dependant but can't remember where at the moment.

Eudora and MacOS Mail for example work through proxies fine (where you don't know
the capabilities of the server till you've authenticated)  Maybe there's another
reason thunderbird's sending strange requests to the server but this is what
differentiates it from the other clients we've tested.

Comment 4

[Nikolay Shopik]

Yeah right almost unnoticed about obsolete RFC 2060.

Comment 5

[Wayne Mery (:wsmwk)]

disposition?

Comment 7

[Duncan Brannen]

Is this confirmed as a duplicate?

470650 is to do with announced capabilities being ignored, this bug is to do
with no requesting the capabilities if they are not reported after a change in
the status of the connection eg login or starttls

Comment 8

[Nikolay Shopik]

David can confirm for comment #7 is this dupe or not. For me looks same, but could be wrong.

Comment 9

[David :Bienvenu]

we do re-issue capability after STARTTLS, and we parse the CAPABILITY response for non-CAPABILITY commands, which afaik is sufficient to work with extant imap servers. Can you point me at an imap server which changes capabilities after LOGON, but doesn't return them as part of the LOGON response?

Comment 10

[Duncan Brannen]

Hi David,
       Our IMAP servers (Dovecot and uw-imap) don't redisplay capabilities after
a logon.  When you've a proxy in front of these to redirect the users to the
correct server, then until the user has logged in you don't know which server a
user belongs on or what capabilities it supports.  In effect here, the
capabilities are changing after login and the server is not reporting them.

If the server it not reporting these in a tagged response after a LOGIN, then the
client doesn't know without sending a CAPABILITY command what the server supports.

See Comment #3, my understanding is that the RFC implies you should rerequest
capabilities after an authneticate or login if they're not recognised in the
login response (which seems to be how Eudora and Mail on the Mac work)