User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Build Identifier: Thunderbird 3 Beta 3 (de, win32) When I try to open an email in the drafts-folder, as soon as I select the email I want to read, TB tries to retrieve it (status bar says, roughly translated from german: "Sending login-data..." then "Opening folder "[Google Mail]/Entwürfe..." but the "Opening folder..." text doesn't disappear - instead, a modal warning dialog opens which reads: "Der aktuelle Befehl war nicht erfolgreich. Der Mail-Server antwortete: Could not parse command ." Which means "command not successful. Mail-server responded: Could not parse command ." Reproducible: Always Steps to Reproduce: 1. Open Drafts folder 2. Select mail in the top-right pane Actual Results: Mail is selected but isn't shown in the bottom-right pane. Expected Results: Show the selected mail, not throw an exception.
WFM but I'm using gmail. CC'ing Marco whom I think uses googlemail (and probably the German locale).
Confirming. I've run into this recently, too. In Germany, when you sign up to gmail it's called "googlemail", as in my e-mail address, due to some legal issue with a German company. So all gmail users from Germany will be affected.
Status: UNCONFIRMED → NEW
Ever confirmed: true
To Philipp Krüger(bug opener): Do you choose other than English(US) at "Display Language" of Gmail setting? If yes, googlemail.com renames "Drafts" to "Entwürfe..." at sever side, and Gmail IMAP of imap.googlemail.com presents it as IMAP folder of "[Googlemail]/Entwürfe..." instead of "[Googlemail]/Drafts". If no, googlemail.com uses "Drafts" at sever side, and Gmail IMAP of imap.googlemail.com presents it as IMAP folder of "[Googlemail]/Drafts", and, if localized Tb(de version) is used, Tb displays it as [Googlemail]/Entwürfe.." (same localized name is used by Gmail & Tb). How did you select "folder to save draft mail"? Via folder selection list of Account Settings/Copies&Folders/Others: of de version of Tb? Check mail.identity.idN.draft_folder via config editor. Whet is set in it? Check location: of folder properties/general of all of "[Googlemail]/Drafts", "[Googlemail]/Entwürfe...". What is displayed in location? Is mail.server.serverN.is_gmail=true set for the account on googlemail.com? > "Der aktuelle Befehl war nicht erfolgreich. Der Mail-Server antwortete: Could not parse command ." > Which means "command not successful. Mail-server responded: Could not parse command." Not error of "folder doesn't exist"? Get IMAP log, and check IMAP level flow first. > Getting log : https://wiki.mozilla.org/MailNews:Logging > IMAP command/response : http://tools.ietf.org/html/rfc3501 > (If Tb's fault is found in log, attach log file. Never paste log data.) (In reply to comment #2) > Confirming. I've run into this recently, too. In Germany, when you sign up to > gmail it's called "googlemail", as in my e-mail address, due to some legal > issue with a German company. So all gmail users from Germany will be affected. Marco Zehe, what/which issue in comment #0 are you confirming? [Googlemail] itslef is irrelevant to issues in comment #0, because [Googlemail] part is correctly set by bug opener if google.com is used by bug opener. If [Googlemail] part is correct, problem in comment #0 is issue around "localized name" part of IMAP folder by Gmail and/or de version of Tb. Read meta bug 402793 and see bugs listed in Dependency tree for the meta bug 402793, for phenomena/issues around localized name by Gmail and/or localized name by Tb, Gmail vs. Googlemail, please.
The folder name is [Google Mail] (with a space. And even when using the English display language on the website I see the problem when opening the [Google Mail]/Drafts folder. This is a recent regression, worked without problem for over a year for me before that.
(In reply to comment #4) > The folder name is [Google Mail] (with a space.) You are right. Sorry for wrong string. > And even when using the English display language on the website I see the problem when opening the [Google Mail]/Drafts folder. Does "opening the [Google Mail]/Drafts folder" means that "[Google Mail]/Drafts" is displayed at folder pane? Do you use de version of Tb? en-US version of Tb? If you used "Display Language=Deutsch", IMAP folder name presented to Tb by Gmail IMAP is "[Google Mail]/Entwürfe...". If you selected this folder, drafts folder setting of Tb becomes "[Google Mail]/Entwürfe...", and it's displayed as "[Google Mail]/Entwürfe..." at folder pane by both de & en-US version of Tb. If you changed Display Language to English(US), Gmail/Gmail IMAP renames the drafts folder to "[Google Mail]/Drafts", so mismatch from your setting([Google Mail]/Entwürfe...) and Gmail's folder name([Google Mail]/Drafts) happens. Did you properly change sent/drafts/junk/trash folder selection after Display Language change by Gmail? > This is a recent regression, worked without problem for over a year for me before that. Which build do you use? Tb 2? If yes, problem started from which release? Tb 3(trunk)? If yes, problem started from which build?
If mismatch between Gmail's IMAP folder name(depends on Display Language of Gmail) and Tb's folder selection setting exists, phenomena described in Bug 467860 occur. DUP of Bug 467860? Comment #0 is a variation of Bug 467860 Comment #35?
(In reply to comment #4) > The folder name is [Google Mail] (with a space.) Do you set Display Language=English(UK)? Is [Google Mail] used for Display Language=Deutsch by your Gmail IMAP server? Is [Google Mail] used for Display Language=English(US) by your Gmail IMAP server? Anyway, get IMAP log, and check response to XLIST command first.
I get a similar message for all 4 accounts, Gmail, AOL, and a local ISP. This started with the upgrade to Thunderbird 3.1 yesterday. I am running 64 bit Windows 7 Professional.
User Agent : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:220.127.116.11) Gecko/20100608 Thunderbird/3.1 Hi: I have been trying to reproduce it from Thunderbird 18.104.22.168 to Thunderbird 3.1 but I can't reproduce the problem. I have changed my Gmail Display language to Deutsch and seems to work correctly, I've checked too the mail.server.serverN settings in the configuration editor and all the values seem to be correct. I don't know because the only difference that I've found that seems to be important is that I'm running Thunderbird over Mac not Windows. Can someone try again under Windows, maybe Don Daniels or Phillipp. As soon as I got feedback I will work again on it.
Dear Pedro, I just fired up the desktop again, and am still getting the problem, but have some more details and clarification. 1. On this machine I am running Windows 7 Professional 64 bit. 2. I have 4 email accounts, and I get a series of 4 windows in the bottom right corner of the screen, but the 1st three are covered and I am unable to confirm if there is one for each account, or just 4 flags for the one Gmail account. 3. It seems to download mail properly at first, and then a few minutes later (perhaps the auto refresh time cycle), it runs those 4 flags up again. 4. With the bug on my desktop, I have been reluctant to apply the update to my 32 bit XP laptop or my wife's 32 Bit Windows 7 laptop, so can't say yet if it affects those other platforms. They are both still running Thunderbird 3.05. 5. It is NOT triggered by clicking on "Get Mail" trying to force a download attempt. I often get 2 waves of 4 flags in close successon, then nothing for several minutes. 6. Have not found any repeatable corelation to a specific task. I do have my Gmail account set to check for mail every 5 minutes, and that seems about to correspond. Let me set it to 1 minute and see what happens??? I am still getting 2 waves of 4 flags, and perhaps they are coming faster, but still over a minute, so no strong corelation there. Manually switching between accounts and going back to my Gmail account does NOT seem to trigger it, not did compacting the folder. Can't think of a whole lot more to try unless you have some suggestions. Is there a way to give you a system configuration dump to make things easier? However, it does not seem to matter what other programs are running, it does it periodically whenever Thunderbird is running, and is still doing it right now. Never had this problem with Thunderbird 3.05 on this same machine. Also, my account settins show imap.gmail.com inbound and smtp.gmail.com outbound. As I recall, the auto configuration when I upgraded to Thunderbird 3 set it to Googlemail, but I manually changed it back to Gmail per the ISP instructions and the way it had always worked before. Will try to catch the message ver batum as it comes up next time. It is: The current operation for "Inbox" did not succeed. The mail server for (Gmail address without @gmail) responded: Could not parse command. And, just to make troubleshooting tougher, the new update to Xmarks keeps crashing my Firefox browser. It opens fine, but as soon as Xmarks trys to sync it locks up saying I need to whitelist logon.xmarks.com in my NoScript, but at the same time it is locked so I can't whitelist anything. Will have to go back to that, try to cancel the Xmarks sync, and get it whitelisted before it crashes. Problem is that just as I am dashing to try and cancle the sync, Firefox pops up with the master security password message, and won't let me reach the Xmarks cancel in time, and then I am frozen, at least in that tab. I love my Firefox and Thunderbird, but Not having a good Mozilla day today. May have to do a different bug report on that if I can't figure it out soon.
Dear Pedro, Just a small update to the previous post. I have now seen the four warning flags in the bottom right corner of the screen come up slowly enough to tell that they are all for my Gmail account, and not one for each account. So that should localize the bug even further to Gmail handling. Also, on my laptop I use the alternate ports as hotels often block the standard email ports, at least outgoing, in order to block spammers. Not sure if I did that also on the desktop, but here are the ports I am using. Gmail imap.gmail.com Port 993 (Default) inbound, smtp.gmail.com Port 587 outbound Just for grins, I changed the inbound server to imap.googlemail.com since that is the way it is on my laptop (setup default) and I have seen the flags pop up one time. Will let you know if I still get them after the next reboot. It is looking like a Gmail or Googlemail interface problem, though I have receive mail with both incoming servers and Thunderbird seems to be working normally other than the annoying warning flags. Hope this helps, Don Daniels
Dear Pedro, Just wanted to inform you that changing the inbound mail server from imap.gmail.com to imap.googlemail.com and rebooting the computer had no effect on the error flags. I am still getting them, although the best I can tell the program seems to be functioning properly in spite of the error messages. At this point it seems to be more of a nuisance than a loss of functionality. Good luck figuring it out, and I will let you know if I find any other correlations. Don Daniels
Get IMAP log and check IMAP level flow, and check when the error message is returned from server. > https://wiki.mozilla.org/MailNews:Logging > SET NSPR_LOG_MODULES=timestamp,imap:5 > IMAP command/response : http://tools.ietf.org/html/rfc3501 If anf only if Tb's fault is seen in log, attach log file to this bug after replacing sensitive data in log file.
Open Tools/Activity Manager window. Full error message text of alert is proably seen at Activity Manager window.
Component: Folder and Message Lists → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: folders-message-lists → networking.imap
I created the .bat file from the wiki page, and run it as administrator, but can't seem to get it to create a log file. I've tried activating it both before and after starting Thunderbird. I do a search for imap.log, but it does not seem to be anywhere on my computer. Any suggestions? Here is what the Create_imap_log.bat file contains. Don set NSPR_LOG_MODULES=imap:5 set NSPR_LOG_FILE=c:\imap.log "C:\Program Files\Mozilla Thunderbird\thunderbird.exe" Also, I am getting a bunch of messages in the error console that look similar to this, but with different unknown property errors. Don't know if this helps? Warning: Unknown property 'mso-margin-top-alt'. Declaration dropped. Source File: imap://xxx%2Exxxx@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3E5959 Line: 0
(In reply to comment #15) > and run it as administrator, (snip) What operation do you mean by "run it as administrator"? If the three lines are writeen in Create_imap_log.bat file, you need to do next operations only. Terminate Tb, if Tb is already running. Open Command Prompt window, and type ...\Create_imap_log.bat. After some tests, terminate Tb, and save log file.
Is anyone still experiencing this problem?
(In reply to David Lechner (:dlech) from comment #17) > Is anyone still experiencing this problem? David, There is a recent report (among others) at https://getsatisfaction.com/mozilla_messaging/topics/imap_could_not_parse_command#reply_13288398 In that topic, multiple users report problem did not start until TB24!
(In reply to Wayne Mery (:wsmwk) from comment #18) > There is a recent report (among others) at > https://getsatisfaction.com/mozilla_messaging/topics/imap_could_not_parse_command#reply_13288398 > In that topic, multiple users report problem did not start until TB24! FYI. This is bug 926467, which was caused by * in HEADER.FIELDS, which comes from wrongly generated mailnews.customHeaders. > 33 UID fetch 98912:98913,98941:98942,98962:99150 > (UID X-GM-MSGID X-GM-THRID X-GM-LABELS RFC822.SIZE FLAGS > BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References > Newsgroups In-Reply-To Content-Type Reply-To reply-to *)]) > 33 BAD Could not parse command
I can't undersand reason why any problem reporter in this bug still never provide IMAP log data, even though "Could not parse command" responce from IMAP server" is a result of an IMAP command which Tb sent to the IMAP server" and the "IMAP command which Tb sent to the IMAP server" is pretty easily known merely by getting Tb side IMAP log. What is reason to keep this bug as "Open", even though no problem reporter won't provide required data for problem analysis? Please note that here is B.M.O to help "bug resolving by developers". Here is never support forum nor "Help Center".
(In reply to WADA from comment #20) > I can't undersand reason why any problem reporter in this bug still never > provide IMAP log data, even though "Could not parse command" responce from > IMAP server" is a result of an IMAP command which Tb sent to the IMAP > server" and the "IMAP command which Tb sent to the IMAP server" is pretty > easily known merely by getting Tb side IMAP log. > What is reason to keep this bug as "Open", even though no problem reporter > won't provide required data for problem analysis? Please note that here is > B.M.O to help "bug resolving by developers". Here is never support forum nor > "Help Center". The reporter Philipp no longer uses Thunderbird. wada, if you think it would be helpful please needinfo others who have previously commented in the bug report. Or, if there is no value in keeping the bug open, then please do close it.
"Could not parse command ." is response from server. 1. Tb sends command to server. e.g. "uid nnn fetch (Flags)" 2. Server returns responce. e.g. "OK", "NO xxx Could not parse command ...". Unfortunately, when error responce from server, Tb doesn't notify about "sent command at step 1.". Tb merely informs "error responce from server at step 2". Therefore, without IMAP log, server side log, TCP/IP trace etc., we can't know "what command with what parameter" was sent to server by Tb. i.e. Report like "'Could not parse command was shown by Tb' only without sent command information" is useless for problem analysis by developer at bugzilla.mozilla.org. It's useful only for counting number of "'Could not parse command' responce" which was returned from a server or servers. Improvement on Tb's error message(include sent command in error message) is already requested by other bug. Closig as INCOMPLETE. because required data for problem analysis is not provided by any problem reporters in this bug. Please re-open this bug with required data for problem analysis, if closing as INCOMPLETE is wrong. .'
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.