Closed Bug 815087 Opened 12 years ago Closed 12 years ago

The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" which is produced by is_gmail=true )

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ace-heart, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [Workaround: is_gmail=false] [gs])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 20121120062532 Steps to reproduce: Tried to check email after an update from version 16 to 17 Actual results: The IMAP mail server responded: Command Argument Error 11, I checked all the settings, and everything was OK there. After rolling back to older version email was checked correctly. OS: Ubuntu 12.04 x64, mail server runs on M$ Exchange, using IMAP protocol. Expected results: Email should be checked for new messages
Get IMAP log and check IMAP level command/response. See bug 402793 comment #28 for getting log. To what IMAP command at which stage is the "Command Argument Error 11" returned? Is same phenomenon as or similar phenomenon to bug 723109 seen in IMAP log?
It's strange but after re-updating to thunderbird 17 I can't reproduce the error.
No, I was wrong. here's the part of log with the error: -1154484480[7f88b0338d00]: ReadNextLine [stream=b4038010 nb=38 needmore=0] -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: * 937 FETCH (FLAGS (\Seen) UID 1110) -1154484480[7f88b0338d00]: ReadNextLine [stream=b4038010 nb=33 needmore=0] -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: * 938 FETCH (FLAGS () UID 1111) -1154484480[7f88b0338d00]: ReadNextLine [stream=b4038010 nb=23 needmore=0] -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: 7 OK FETCH completed. -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:SendData: 8 UID fetch 1111 (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)]) -1154484480[7f88b0338d00]: ReadNextLine [stream=b4038010 nb=34 needmore=0] -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: 8 BAD Command Argument Error. 11
As I understand, the error is not the same as in bug 723109.
(In reply to ace-heart from comment #3) > -1154484480[7f88b0338d00]: > c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: * 937 FETCH (FLAGS (\Seen) UID 1110) You said "mail server runs on M$ Exchange, using IMAP protocol" in comment #0, which is original report of this bug. Why Gmail IMAP server can be relevant to the original report of your comment #0? Do you define M$ Exchange server as imap.gmail.com in your environment, for example, in hosts file? > -1154484480[7f88b0338d00]: c79a3800:imap.gmail.com:S-INBOX:SendData: 8 UID > fetch 1111 (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)]) > c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: 8 BAD Command > Argument Error. 11 X-GM-MSGID,X-GM-THRID,X-GM-LABELS has been supported from Tb 17 by bug 721316(status-thunderbird17:fixed). > Bug 721316 Use Gmail IMAP Extension of X-GM-MSGID, X-GM-THRID, X-GM-LABELS in addition to XLIST Why Gmail IMAP returns "BAD Command Argument Error. 11"? Follow-up by Bug 798145 is needed? > Bug 798145 Gmail IMAP core Bug 721316 follow-up : Few fixes continuing for Bug 721316 Confirming per IMAP log. Anyway, setting Bug 721316 in Block: field of this bug for ease of tracking/analyis.
Blocks: 721316
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → MailNews Core
Summary: The mail server responded: Command Argument Error 11 → The mail server responded: Command Argument Error 11 ( Gmail IMAP returned "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[HEADER.FIELDS ( ... )])" )
No longer blocks: tb-gmailWIP
Oh sorry, I was CC'in myself :-/
Blocks: tb-gmailWIP
Atul Jangra(ower of Bug 721316), what's wrong? Tb's fault? Or current Gmail IMAP restriction?
@ace-heart (bug reporter) can you please add the entire imap log as an attachment. I have seen this error before as a result of the gmailbuttons addon that I have developed. The problem was because of incorrect detection of the IsGmail attribute. I am hoping that seeing the entire log will give us more insight.
Flags: needinfo?(ace-heart)
@ace-heart @wada as said by dlech, we would need the entire imap log for detecting the problem. @ace-heart : As you are not running on GMail server and fetching of X-GM-MSGID, X-GM-THRID, X-GM-LABELS occurs only in case of GMail server, thus clearly this is a problem of incorrect detection of the IsGmail attribute. Also are you running any other addon? Can you log the problem without any addon? I guess that would be more helpful.
Attached file full imap log (deleted) —
Full imap log with the error 11 returned from exchange server.
Flags: needinfo?(ace-heart)
I attached full log, please see it; the addons I use are: - CouchDB addressbook - Display Mail User Agent - EDS Contacts integration - Messaging menu and Unity launcher integration - Thunderbird Conversations After disabling all of them I still can't get new messages
Thanks for the imap log. WADA, this seems a TB's problem. I am trying to figure out where we are getting wrong.
(In reply to WADA from comment #5) > (In reply to ace-heart from comment #3) > > -1154484480[7f88b0338d00]: > > c79a3800:imap.gmail.com:S-INBOX:CreateNewLineFromSocket: * 937 FETCH (FLAGS (\Seen) UID 1110) > > You said "mail server runs on M$ Exchange, using IMAP protocol" in comment > #0, which is original report of this bug. > Why Gmail IMAP server can be relevant to the original report of your comment > #0? > Do you define M$ Exchange server as imap.gmail.com in your environment, for > example, in hosts file? @ace-heart please answer this :-) From the log I can see that imap.gmail.com is present there, is that what you expect with MS Exchange server?
Flags: needinfo?(ace-heart)
Atul Jangra, Yes, technically it's gmail server, but now web access to it is closed, and if I got it correctly, somehow they switched it to exchange now. Maybe I misunderstood somethnig :)
Flags: needinfo?(ace-heart)
Ok Thanks :) So now when they have switched to exchange, shouldn't we have something else instead of imap.gmail.com? (I am sorry, I actually know nothing about ms exchange server)
Maybe they combined it somehow. I don't know either. In the account settings I use another imap server and apparently it redirects mail client queries to gmail.
Which imap server are you using in accounts settings? Can you tell it's incoming and outgoing server?
For incoming mail I use emea.mail.ti.com, For outgoing It uses another one and I don't have problems with sending mail, only with recieving.
Ok, So summarizing the problem: we have a non-gmail server which redirects to gmail server. And in the process it is not identifying the gmail attributes. Hmm that's strange. @dlech have you experienced this thing before?
Yes, and in previous versions everything worked fine.
ace-heart, Try this: On the 'Tools' menu, select 'Options', then in the Options dialog, select 'Advanced'. Click the button that says 'Config Editor...'. This opens the about:config editor. In the search box, type 'gmail'. You should see a preference like 'mail.server.server1.is_gmail'. Set it to 'false'. Let us know what happens. Atul Jangra, I was expecting to see a folder with the \AllMail flag in the imap log because that is how TB detects a gmail server. I did not think that the isGmail attribute was persisted in the options, but apparently it is.
Oh yes. Thanks Dlech. We actually set isGmail true here: http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapIncomingServer.cpp#1189. So I guess the problem is initially there was an All Mail folder so we set isGmail true. But now, as ace-heart said, the server has been shifted to MS Exchange, but still isGmail is true. So setting the pref as false should work as a fix for the problem. Ace-heart, my bet is that the problem should be solved and you should be able to receive messages again. Dlech, But now does this call for improving the way we set isGmail? Can we be totally dependent on /AllMail flag for this?
Atul, I was thinking on Bug 798663 that we not only set the isGmail attribute if we have X-GM-EXT1 capability, but make sure we clear it if X-GM-EXT1 goes away.
(In reply to ace-heart from comment #14) > Yes, technically it's gmail server, but now web access to it is closed, > and if I got it correctly, somehow they switched it to exchange now. Does it mean that "access to FQDN=imap.gmail.com" somehow got redircted to MS Exchange server from actual Gmail IMAP server at a certain point in your environment or company or country? (In reply to ace-heart from comment #18) > For incoming mail I use emea.mail.ti.com, (snip) You did following? (1) Create Gmail IMAP account in Tb with server name=imap.gmail.com, and used actual Gmail IMAP account normally for a while. (2) At a certain point, you(or management team) changed Tb's account definition to server name=emea.mail.ti.com which is MS Exchange server, in order to use emea.mail.ti.com IMAP server newly with somehow keeping subscription list of "[Gmail]/Sent Mail" and "[Gmail]/Drafts", in order to stop using actual Gmail IMAP server(imap.gmail.com). If so, following can occur, and is_gmail=true may be kept. (By step 1) mail.server.serverN.type = imap mail.server.serverN.hostname = imap.gmail.com mail.server.serverN.userName = xxx@gmail.com mail.server.server2.is_gmail = true (By step 2) mail.server.serverN.type = imap mail.server.serverN.hostname = imap.gmail.com (unchanged, by design) mail.server.serverN.realhostname = emea.mail.ti.com mail.server.serverN.userName = xxx@gmail.com (unchanged, by design) mail.server.serverN.realuserName = ???@emea.mail.ti.com like one mail.server.serverN.is_gmail = true (perhaps unchanged by Tb) (After step 2) Tb uses permanent hostname=imap.gmail.com internally for mail server access. So, server name=imap.gmail.com appers in IMAP log. ace-heart, what is your server definitions in prefs.js of Tb? (Tool/Options/Advanced/General, Config Editor, with "Search: server.server")
(In reply to WADA from comment #24) I think you have it correct about redirecting the FQDN. That is exactly what looks like is happening. This is also on Get Satisfaction, http://gsfn.us/t/39sqa I was able to reproduce this bug with a non-gmail imap account (happened to be uw-imap in a VM, but it should not matter) 1. Create new preference 'mail.server.serverN.is_gmail' and set it to true. 2. Try to move a message from Trash to Inbox - got popup error notification that operation failed. 3. Looked in imap log and saw error similar to the attached log. Did not save it, so this may not be exact, but something like: n UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS... n BAD server does not support... 4. Change 'mail.server.serverN.is_gmail' to false 5. Try to move message again 6. Operation succeeds
Whiteboard: [gs]
OS: Linux → All
Hardware: x86_64 → All
Summary: The mail server responded: Command Argument Error 11 ( Gmail IMAP returned "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[HEADER.FIELDS ( ... )])" ) → The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" )
(In reply to David Lechner (:dlech) from comment #21) > ace-heart, > > Try this: On the 'Tools' menu, select 'Options', then in the Options dialog, > select 'Advanced'. Click the button that says 'Config Editor...'. This opens > the about:config editor. In the search box, type 'gmail'. You should see a > preference like 'mail.server.server1.is_gmail'. Set it to 'false'. Let us > know what happens. After setting this option to 'false' problem disappeared.
Summary: The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" ) → The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" whiich is produced by is_gmail=true )
Whiteboard: [gs] → [Workaround: is_gmail=false] [gs]
Summary: The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" whiich is produced by is_gmail=true ) → The mail server responded: Command Argument Error 11 ( Non-Gmail IMAP server returns "BAD Command Argument Error. 11" to "UID fetch 1111 (UID X-GM-MSGID X-GM-THRID X-GM-LABELS ... BODY.PEEK[ ... ])" which is produced by is_gmail=true )
CAPABILITY response from Gmail IMAP, as of today. > * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE I also think is_gmail should be set based on X-GM-EXT-1(and XLIST too?) in CAPABILITY response and is_gmail should be reset if no X-GM-EXT-1 in CAPABILITY response.
Depends on: 798663
(In reply to WADA from comment #27) > CAPABILITY response from Gmail IMAP, as of today. > > * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE > > I also think is_gmail should be set based on X-GM-EXT-1(and XLIST too?) in > CAPABILITY response and is_gmail should be reset if no X-GM-EXT-1 in > CAPABILITY response. Agreed. :-) I'll try to include the changes to do the same.
other servers return XLIST. And now that gmail supports special use, I wouldn't be surprised if XLIST went away.
As Bug 798663 is now resolved, I believe that this one is also resolved. Also, Dlech has tested the outcome ( ), so I am marking the bug as "RESOLVED". Feel free to reopen the bug if any further problem arises.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: