User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081220 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 Quota support and Sharing support with Cyrus-IMAPd v2.3.13 worked flawlessly in 3.0a3 (Shredder). In 3.0b1 it now says that "this server does not support quotas" and "this server does not support shared folders" in the "Quota" tab of mailbox properties, on any mailbox held on a Cyrus-IMAPd server. This is tested against Cyrus IMAP v2.3.13. It still appears to work against an older Cyrus IMAP v.2.2.12. I have tried this in safe mode and with a new profile, no change in results. Please can it be fixed again, this is very important to my users. I will happily provide support to any developer who can help fix this problem. Reproducible: Always Steps to Reproduce: 1. Set up account talking to IMAP server running Cyrus v.2.3.13. 2. Right-click on a folder. 3. Choose Properties. 4. Choose Quota tab or Sharing tab. Actual Results: Dialog just shows the text "this server does not support quotas" or "this server does not support shared folders". Expected Results: Should get display of folder permissions, or amount of quota used, just like in 3.0a3. My IMAP servers are publicly acessible, and I will happily give a developer an account on both the old v.2.2 server and the new v2.3 server to test against. I am the postmaster and so will help out as much as possible.

Get NSPR log for IMAP, and check IMAP level flow first. > Environment variables for IMAP (imap:5) > http://kb.mozillazine.org/Session_logging_for_mail/news > How to get NSPR log on Mac OS X (see Enabling HTTP logging:/OSX section) > http://www.mozilla.org/projects/netlib/http/http-debugging.html > RFC 3501 (IMAP4rev1) > http://www.faqs.org/rfcs/rfc3501.html If log analysis by developers will be required, replace sensitive data in log file(such as mail addr, use name) by meaninles string, and attach log file to this bug, please.

This is a log file of Shredder 3.0a3 talking IMAP to peewit.ecs.soton.ac.uk, while I start Shredder, right-click on the inbox and show the folder properties, in particular the Sharing and Quota tabs.

This is a log file of Shredder 3.0a3 talking IMAP to peewit.ecs.soton.ac.uk, while I start Shredder, right-click on the inbox and show the folder properties, in particular the Sharing and Quota tabs.

This is a log file of Thunderbird 3.0b1 talking IMAP to peewit.ecs.soton.ac.uk, while I start Thunderbird, right-click on the inbox and show the folder properties, in particular the Sharing and Quota tabs. Thunderbird complains that the server does not support shared folders or quotas.

This is a log file of Thunderbird 3.0b1 talking IMAP to peewit.ecs.soton.ac.uk, while I start Thunderbird, right-click on the inbox and show the folder properties, in particular the Sharing and Quota tabs. Thunderbird complains that the server does not support shared folders or quotas.

Following log is seen in "works properly" case. > SendData: 10 select "INBOX" (CONDSTORE) > SendData: 11 myrights "INBOX" > SendData: 12 getacl "INBOX" > SendData: 13 getquotaroot "INBOX" But when "Shows fault" case, "(CONDSTORE)" is not used by "select", and command of myrights/getacl/getquotaroot is not seen in log. > SendData: 7 select "INBOX" CONDSTORE extension support is done by Bug 436151(FIXED on 2008-10-01). It looked to work with "Shredder 3.0a3"(old trunk build), but something relates to it seems to be corrupted by "Thunderbird 3.0b1"(Tb 3 Beta release). Can you re-produce problem with nightly latest-trunk build("Shredder/3.0b2pre")? (Off-Topic) nsHttp:5 is not needed. imap:5 is sufficient in your case. "No guide for Mac OS X user in Session_logging_for_mail/news" is the reason why I pointed "http-debugging.html". And, independent logging is not needed, even if both of imap:5 & nsHttp:5 is required - setenv NSPR_LOG_MODULES imap:5,nsHttp:5

IMAP log of Shredder 3.0b3pre talking to peewit.ecs.soton.ac.uk. Broken behaviour still seen in this release.

I'm guessing that this has to do with the parsing of the capability response in the greeting, since we're not issuing a separate capability command. We're getting two separate greeting responses; the second one has the quota capability. We need to pay attention to the second one, since that's the one that we get after we authenticate...

Good case. > Connection -> Small set of capability in greeting > 1 capability -> full capability list + additional ones(e.g AUTH=PLAIN) > 2 authenticate plain -> full capability list(after login, so no AUTH=PLAIN) > select "INBOX" (CONDSTORE), myrights/getacl/getquotaroot for "INBOX" Bad case. > Connection -> Small set of capability in greeting > (capability is not issued) > 1 authenticate plain -> full capability list > select "INBOX", no myrights/getacl/getquotaroot for "INBOX" David, "no capability command" is a result by patch for Bug 401293?

WADA, yes, that's my thought.

Confirming, based on attached log.

Dale, do you think you could have a look at this?

To David Bienvenu: I can't believe enhancement by Bug 401293 is mandatory for Tb 3. I think one of following actions is better for releasing Tb 3 Beta's, RCx, and Tb 3. (a) Backout change by Bug 401293. (b) Disable logic of "bypass capability command", until this bug's solution will be available. (This is simplest way, I think) - Define a variable which is always false. If (a_variable==true && other_conditions_met) { bypass capability ; } (c) Make functionality of "bypass capability command" optional. What do you think?

Not bypassing the capability command seems the simplest thing to do IMHO. What was the point of bypassing it anyway? Surely you want to take notice of all capability commands?

I think a) or b) makes sense - I just haven't had time to look into what was wrong with the original patch...

looking at the code, I think we're already parsing the unsolicited capability responses, so it's unclear why we're ignoring them. Anyway, I'm going to figure this out today or tomorrow, since it really messes with Cyrus users.

this should fix it, and bring us into conformance with the relevant part of the IMAP RFC.

Whoops, did not know how I did that. Reverting changes...

fix checked in.