Closed Bug 627805 Opened 15 years ago Closed 14 years ago

Certain Messages cause TB to logout after getting body structure (Microsoft Exchange IMAP, no Content-Transfer-Encoding in MIME part, MS Exchange returns 7BIT without quote in BODYSTRUCTURE response)

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Version:
1.9.2 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: phil, Unassigned)

Details

(Whiteboard: [has protocol log])

I've had 3 messages now which have various attachments where either (A) the message won't load at all or (B) it loads part of the message which usually means either I'm missing some attachments and one attachment is corrupt (i.e. if there are 5 attachments and the message ends half way through the 4th). I've been trying to debug this for days, but it's actually kind of hard to reproduce - resetting account settings sometimes will change the behavior. I managed to get a tcpdump that shows tbird sending a 'logout' just after it gets a response to a bodystructure fetch. In this case it's an IMAP server running Exchange, which could easy be doing something odd, nonstandard, or broken, but if it is, I haven't seen it in the dumps yet. I had a tcpdump running, started tbird, waited for traffic to stop, hit enter in the terminal a few times, and then clicked on the problem message, and then pasted everything after that. In this particular case, the symptom is that tbird shows a blank message. It shouldn't make a difference, but I'm running a local stunnel in order to be able to get non-encrypted IMAP traffic, so this dump is actually from localhost to localhost on random ports. 11:04:46.513681 IP6 frantic.44187 > frantic.9999: Flags [P.], seq 366:372, ack 35863, win 386, options [nop,nop,TS val 59136446 ecr 59136050], length 6 0x0000: 6000 0000 0026 0640 0000 0000 0000 0000 `....&.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd5a ..........'..1.Z 0x0030: 0e8b 25eb 8018 0182 002e 0000 0101 080a ..%............. 0x0040: 0386 59be 0386 5832 444f 4e45 0d0a ..Y...X2DONE.. 11:04:46.516231 IP6 frantic.9999 > frantic.44187: Flags [P.], seq 35863:35885, ack 372, win 265, options [nop,nop,TS val 59136446 ecr 59136446], length 22 0x0000: 6000 0000 0036 0640 0000 0000 0000 0000 `....6.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 270f ac9b 0e8b 25eb ........'.....%. 0x0030: 0e31 cd60 8018 0109 003e 0000 0101 080a .1.`.....>...... 0x0040: 0386 59be 0386 59be 3820 4f4b 2049 444c ..Y...Y.8.OK.IDL 0x0050: 4520 636f 6d70 6c65 7465 642e 0d0a E.completed... 11:04:46.516246 IP6 frantic.44187 > frantic.9999: Flags [.], ack 35885, win 386, options [nop,nop,TS val 59136446 ecr 59136446], length 0 0x0000: 6000 0000 0020 0640 0000 0000 0000 0000 `......@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd60 ..........'..1.` 0x0030: 0e8b 2601 8010 0182 0028 0000 0101 080a ..&......(...... 0x0040: 0386 59be 0386 59be ..Y...Y. 11:04:46.518650 IP6 frantic.44187 > frantic.9999: Flags [P.], seq 372:406, ack 35885, win 386, options [nop,nop,TS val 59136447 ecr 59136446], length 34 0x0000: 6000 0000 0042 0640 0000 0000 0000 0000 `....B.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd60 ..........'..1.` 0x0030: 0e8b 2601 8018 0182 004a 0000 0101 080a ..&......J...... 0x0040: 0386 59bf 0386 59be 3920 5549 4420 6665 ..Y...Y.9.UID.fe 0x0050: 7463 6820 3337 3839 2028 424f 4459 5354 tch.3789.(BODYST 0x0060: 5255 4354 5552 4529 0d0a RUCTURE).. 11:04:46.538461 IP6 frantic.9999 > frantic.44187: Flags [P.], seq 35885:36348, ack 406, win 265, options [nop,nop,TS val 59136449 ecr 59136447], length 463 0x0000: 6000 0000 01ef 0640 0000 0000 0000 0000 `......@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 270f ac9b 0e8b 2601 ........'.....&. 0x0030: 0e31 cd82 8018 0109 01f7 0000 0101 080a .1.............. 0x0040: 0386 59c1 0386 59bf 2a20 3839 3520 4645 ..Y...Y.*.895.FE 0x0050: 5443 4820 2842 4f44 5953 5452 5543 5455 TCH.(BODYSTRUCTU 0x0060: 5245 2028 2828 2274 6578 7422 2022 706c RE.((("text"."pl 0x0070: 6169 6e22 2028 2263 6861 7273 6574 2220 ain".("charset". 0x0080: 2255 532d 4153 4349 4922 2920 4e49 4c20 "US-ASCII").NIL. 0x0090: 4e49 4c20 3742 4954 2033 3735 3520 3135 NIL.7BIT.3755.15 0x00a0: 3320 4e49 4c20 4e49 4c20 4e49 4c20 4e49 3.NIL.NIL.NIL.NI 0x00b0: 4c29 2822 7465 7874 2220 2268 746d 6c22 L)("text"."html" 0x00c0: 2028 2263 6861 7273 6574 2220 2255 532d .("charset"."US- 0x00d0: 4153 4349 4922 2920 4e49 4c20 4e49 4c20 ASCII").NIL.NIL. 0x00e0: 3742 4954 2039 3330 3420 3138 3620 4e49 7BIT.9304.186.NI 0x00f0: 4c20 4e49 4c20 4e49 4c20 4e49 4c29 2022 L.NIL.NIL.NIL)." 0x0100: 616c 7465 726e 6174 6976 6522 2028 2262 alternative".("b 0x0110: 6f75 6e64 6172 7922 2022 3d5f 616c 7465 oundary"."=_alte 0x0120: 726e 6174 6976 6520 3030 3539 3741 4432 rnative.00597AD2 0x0130: 3835 3235 3738 3146 5f3d 2229 204e 494c 8525781F_=").NIL 0x0140: 204e 494c 2928 2261 7070 6c69 6361 7469 .NIL)("applicati 0x0150: 6f6e 2220 226f 6374 6574 2d73 7472 6561 on"."octet-strea 0x0160: 6d22 2028 226e 616d 6522 2022 3436 3338 m".("name"."4638 0x0170: 5f30 3031 5b31 5d2e 7064 6622 2920 4e49 _001[1].pdf").NI 0x0180: 4c20 4e49 4c20 2262 6173 6536 3422 2033 L.NIL."base64".3 0x0190: 3632 3239 3820 4e49 4c20 2822 6174 7461 62298.NIL.("atta 0x01a0: 6368 6d65 6e74 2220 2822 6669 6c65 6e61 chment".("filena 0x01b0: 6d65 2220 2234 3633 385f 3030 315b 315d me"."4638_001[1] 0x01c0: 2e70 6466 2229 2920 4e49 4c20 4e49 4c29 .pdf")).NIL.NIL) 0x01d0: 2022 6d69 7865 6422 2028 2262 6f75 6e64 ."mixed".("bound 0x01e0: 6172 7922 2022 3d5f 6d69 7865 6420 3030 ary"."=_mixed.00 0x01f0: 3539 3741 4432 3835 3235 3738 3146 5f3d 597AD28525781F_= 0x0200: 2229 204e 494c 204e 494c 2920 5549 4420 ").NIL.NIL).UID. 0x0210: 3337 3839 290d 0a 3789).. 11:04:46.546478 IP6 frantic.44187 > frantic.9999: Flags [P.], seq 406:417, ack 36348, win 386, options [nop,nop,TS val 59136449 ecr 59136449], length 11 0x0000: 6000 0000 002b 0640 0000 0000 0000 0000 `....+.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd82 ..........'..1.. 0x0030: 0e8b 27d0 8018 0182 0033 0000 0101 080a ..'......3...... 0x0040: 0386 59c1 0386 59c1 3130 206c 6f67 6f75 ..Y...Y.10.logou 0x0050: 740d 0a t.. 11:04:46.548528 IP6 frantic.9999 > frantic.44187: Flags [P.], seq 36348:36371, ack 417, win 265, options [nop,nop,TS val 59136450 ecr 59136449], length 23 0x0000: 6000 0000 0037 0640 0000 0000 0000 0000 `....7.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 270f ac9b 0e8b 27d0 ........'.....'. 0x0030: 0e31 cd8d 8018 0109 003f 0000 0101 080a .1.......?...... 0x0040: 0386 59c2 0386 59c1 3920 4f4b 2046 4554 ..Y...Y.9.OK.FET 0x0050: 4348 2063 6f6d 706c 6574 6564 2e0d 0a CH.completed... 11:04:46.550177 IP6 frantic.9999 > frantic.44187: Flags [FP.], seq 36371:36460, ack 417, win 265, options [nop,nop,TS val 59136450 ecr 59136449], length 89 0x0000: 6000 0000 0079 0640 0000 0000 0000 0000 `....y.@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 270f ac9b 0e8b 27e7 ........'.....'. 0x0030: 0e31 cd8d 8019 0109 0081 0000 0101 080a .1.............. 0x0040: 0386 59c2 0386 59c1 2a20 4259 4520 4d69 ..Y...Y.*.BYE.Mi 0x0050: 6372 6f73 6f66 7420 4578 6368 616e 6765 crosoft.Exchange 0x0060: 2053 6572 7665 7220 3230 3130 2049 4d41 .Server.2010.IMA 0x0070: 5034 2073 6572 7665 7220 7369 676e 696e P4.server.signin 0x0080: 6720 6f66 662e 0d0a 3130 204f 4b20 4c4f g.off...10.OK.LO 0x0090: 474f 5554 2063 6f6d 706c 6574 6564 2e0d GOUT.completed.. 0x00a0: 0a . 11:04:46.550212 IP6 frantic.44187 > frantic.9999: Flags [.], ack 36461, win 386, options [nop,nop,TS val 59136450 ecr 59136450], length 0 0x0000: 6000 0000 0020 0640 0000 0000 0000 0000 `......@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd8d ..........'..1.. 0x0030: 0e8b 2841 8010 0182 0028 0000 0101 080a ..(A.....(...... 0x0040: 0386 59c2 0386 59c2 ..Y...Y. 11:04:46.552662 IP6 frantic.44187 > frantic.9999: Flags [F.], seq 417, ack 36461, win 386, options [nop,nop,TS val 59136450 ecr 59136450], length 0 0x0000: 6000 0000 0020 0640 0000 0000 0000 0000 `......@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 ac9b 270f 0e31 cd8d ..........'..1.. 0x0030: 0e8b 2841 8011 0182 0028 0000 0101 080a ..(A.....(...... 0x0040: 0386 59c2 0386 59c2 ..Y...Y. 11:04:46.552677 IP6 frantic.9999 > frantic.44187: Flags [.], ack 418, win 265, options [nop,nop,TS val 59136450 ecr 59136450], length 0 0x0000: 6000 0000 0020 0640 0000 0000 0000 0000 `......@........ 0x0010: 0000 0000 0000 0001 0000 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 270f ac9b 0e8b 2841 ........'.....(A 0x0030: 0e31 cd8e 8010 0109 0028 0000 0101 080a .1.......(...... 0x0040: 0386 59c2 0386 59c2 ..Y...Y.
What happens if you either set mail.server.default.mime_parts_on_demand or both browser.cache.{disk,memory}.enable to false? If those resolve the issue, this may be bug 565852, which is fixed for 3.1.8 (candidate builds should be coming up any day now).
On a second thought, is your IMAP account set to keep local offline copies? The bug I've referred to above only applies if synchronization is disabled.
I do not have message sync on, so this could be applicable. I'll run the tests after lunch. Thanks for the quick response!
I set both to false, restarted tbird, and still the symptom remains.
Ok, it was worth a try - moving to MailNews Core / Networking: IMAP. Can you attach an IMAP:5 log? See https://wiki.mozilla.org/MailNews:Logging for details, you may want to edit the log to restrict it to the actual problem message and to remove any information you don't intend to post publicly.
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Version: 3.1 → 1.9.2 Branch
Oh, that's actually pretty telling. (I've scrubbed the log to replace my mailserver with MYMAILSERVER and user with MYUSER. Not that I think these are particularly sensitive, but it's a work account, and so I'm being overly cautious.) 2011-01-21 22:02:32.091582 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:SendData: DONE 2011-01-21 22:02:32.094197 UTC - 258995968[7f0d0f80a370]: ReadNextLine [stream=18168c10 nb=22 needmore=0] 2011-01-21 22:02:32.094228 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:CreateNewLineFromSocket: 8 OK IDLE completed. 2011-01-21 22:02:32.094252 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:ProcessCurrentURL: entering 2011-01-21 22:02:32.094273 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:ProcessCurrentURL:imap://MYUSER@MYMAILSERVER:9999/fetch%3EUID%3E/INBOX%3E3789: = currentUrl 2011-01-21 22:02:32.125992 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:SendData: 9 UID fetch 3789 (BODYSTRUCTURE) 2011-01-21 22:02:32.147311 UTC - 258995968[7f0d0f80a370]: ReadNextLine [stream=18168c10 nb=463 needmore=0] 2011-01-21 22:02:32.147345 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:CreateNewLineFromSocket: * 895 FETCH (BODYSTRUCTURE ((("text" "plain" ("charset" "US-ASCII") NIL NIL 7BIT 3755 153 NIL NIL NIL NIL)("text" "html" ("charset" "US-ASCII") NIL NIL 7BIT 9304 186 NIL NIL NIL NIL) "alternative" ("boundary" "=_alternative 00597AD28525781F_=") NIL NIL)("application" "octet-stream" ("name" "4638_001[1].pdf") NIL NIL "base64" 362298 NIL ("attachment" ("filename" "4638_001[1].pdf")) NIL NIL) "mixed" 2011-01-21 22:02:32.147377 UTC - 258995968[7f0d0f80a370]: ("boundary" "=_mixed 00597AD28525781F_=") NIL NIL) UID 3789) 2011-01-21 22:02:32.147436 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:PARSER:Internal Syntax Error: %s:: string does not start with '{' or '"' 2011-01-21 22:02:32.147453 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:PARSER:Internal Syntax Error on line: %s: * 895 FETCH (BODYSTRUCTURE ((("text" "plain" ("charset" "US-ASCII") NIL NIL 7BIT 3755 153 NIL NIL NIL NIL)("text" "html" ("charset" "US-ASCII") NIL NIL 7BIT 9304 186 NIL NIL NIL NIL) "alternative" ("boundary" "=_alternative 00597AD28525781F_=") NIL NIL)("application" "octet-stream" ("name" "4638_001[1].pdf") NIL NIL "base64" 362298 NIL ("attachment" ("filename" "4638_001[1].pdf")) NIL NIL) "mixed" 2011-01-21 22:02:32.147482 UTC - 258995968[7f0d0f80a370]: ("boundary" "=_mixed 00597AD28525781F_=") NIL NIL) UID 3789) 2011-01-21 22:02:32.147579 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:PARSER:Internal Syntax Error on line: %s: * 895 FETCH (BODYSTRUCTURE ((("text" "plain" ("charset" "US-ASCII") NIL NIL 7BIT 3755 153 NIL NIL NIL NIL)("text" "html" ("charset" "US-ASCII") NIL NIL 7BIT 9304 186 NIL NIL NIL NIL) "alternative" ("boundary" "=_alternative 00597AD28525781F_=") NIL NIL)("application" "octet-stream" ("name" "4638_001[1].pdf") NIL NIL "base64" 362298 NIL ("attachment" ("filename" "4638_001[1].pdf")) NIL NIL) "mixed" 2011-01-21 22:02:32.147609 UTC - 258995968[7f0d0f80a370]: ("boundary" "=_mixed 00597AD28525781F_=") NIL NIL) UID 3789) 2011-01-21 22:02:32.156403 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:SendData: 10 logout 2011-01-21 22:02:32.158293 UTC - 258995968[7f0d0f80a370]: ReadNextLine [stream=18168c10 nb=23 needmore=0] 2011-01-21 22:02:32.158325 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:S-INBOX:CreateNewLineFromSocket: 9 OK FETCH completed. 2011-01-21 22:02:32.158700 UTC - 258995968[7f0d0f80a370]: 171ee000:MYMAILSERVER:NA:TellThreadToDie: close socket connection 2011-01-21 22:02:32.158723 UTC - 258995968[7f0d0f80a370]: ImapThreadMainLoop leaving [this=171ee000]
David or WADA, anything that looks familiar from bug 565852?
Whiteboard: [has protocol log]
It's probably worth noting that I had both memory and disk cache disabled when that log was generated.
(In reply to comment #7) > David or WADA, anything that looks familiar from bug 565852? No, this is a syntax error in the body structure response returned by the server, or at least what looks like a syntax error to our imap parser. I'd need a sample message to debug it, however.
I'll have to get permission for that... it's a potentially sensitive message. If I do get permission, I can't post it publicly.
If you do get permission, can you save the message as a .eml file, and e-mail it to me?
That should have said "I may not be able to post it publicly" - I fired off an email to the right people. Well, tbird can't get it, ut I can export the raw message using mutt, which has no issue, and email that to you. That should be the same as .eml, I believe.
Following is BODYSTRUCTURE response from Gmail IMAP for similar mail structure. Content-Transfer-Encoding header in my test mail is; > Content-Transfer-Encoding: 7BIT I your case, 7BIT is not quoted by doublequote's, although base64 is correctly quoted as "base64". [5764] 4980[4d81080]: 25a3000:imap.gmail.com:S-bug-627805Y:SendData: 85 UID fetch 6 (BODYSTRUCTURE) [5764] 4980[4d81080]: ReadNextLine [stream=195a100 nb=443 needmore=0] [5764] 4980[4d81080]: 25a3000:imap.gmail.com:S-bug-627805Y:CreateNewLineFromSocket: * 1 FETCH (UID 6 BODYSTRUCTURE ((("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 17 1 NIL NIL NIL)("TEXT" "HTML" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 54 3 NIL NIL NIL) "ALTERNATIVE" ("BOUNDARY" "=_alternative 00597AD28525781F_=") NIL NIL)("APPLICATION" "OCTET-STREAM" ("NAME" "4638_001[1].pdf") NIL NIL "BASE64" 2954946 NIL ("ATTACHMENT" ("FILENAME" "4638_001[1].pdf")) NIL) "MIXED" ("BOUNDARY [5764] 4980[4d81080]: " "=_mixed 00597AD28525781F_=") NIL NIL)) [5764] 4980[4d81080]: ReadNextLine [stream=195a100 nb=15 needmore=0] [5764] 4980[4d81080]: 25a3000:imap.gmail.com:S-bug-627805Y:CreateNewLineFromSocket: 85 OK Success Phil Dibowitz(bu opener), can you check using test mail of without(or with) Content-Transfer-Encoding: 7BIT header? (1) Save the mail to .eml file, edit the .eml file, change subject, remove Content-Transfer-Encoding: 7BIT header of text/plain and text/html part in multipart/alternative part if exists, or add Content-Transfer-Encoding: 7BIT header to text/plain and text/html part in multipart/alternative part if doesn't exist. If needed, check with next, please. Content-Transfer-Encoding: "7BIT" (2) Create an IMAP folder(Test1, offline-use=off), drag the .eml file to thread pane of Test1. Wait for upload completion. Check the mail. (3) Get clean IMAP log. (3-1) Restart Tb with IMAP logging enabled. (3-2) Rename Test1 to Test2(force discard of cached data etc.) (3-3) Click Test2 (3-4) Click the test mail in Test2(fetch bodystructure is issued) (3-5) Terminate Tb.
(In reply to comment #6) > FETCH (BODYSTRUCTURE ((("text" "plain" ("charset" "US-ASCII") NIL NIL 7BIT 3755 > 153 NIL NIL NIL NIL)("text" "html" ("charset" "US-ASCII") NIL NIL 7BIT 9304 186 Good catch - per http://tools.ietf.org/html/rfc2060#section-9 the values of body_fld_enc include "7BIT" with quotes, but the formal syntax also allows a string, which per http://tools.ietf.org/html/rfc2060#section-4.3 can be either a literal or a quoted string. Thus, I'm a bit confused whether or not the response from the server is syntactically correct...
Oops, wrong RFC, should be http://tools.ietf.org/html/rfc3501#section-4.3 instead. The literal doesn't seem to apply anyway as it would have to be preceded by the octet count, thus I'd say the "7BIT" needs the quotes.
Wada, OK, there are three parts to the MIME, 1 text/plain, 1 text/html, and one application/octet-stream. I added: Content-Transfer-Encoding: "7BIT" to the first two (neither had a C-T-E header), and followed the rest of the directions, and it worked fine. The relevant part of the log: 2011-01-24 19:11:15.091413 UTC - -614467840[7fb8dbd88360]: db6b5000:MYSERVER:S-test4:SendData: 5 UID fetch 1 (UID 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)])^M 2011-01-24 19:11:15.100249 UTC - -614467840[7fb8dbd88360]: ReadNextLine [stream=db67a810 nb=185 needmore=0] 2011-01-24 19:11:15.100300 UTC - -614467840[7fb8dbd88360]: db6b5000:MYSERVER:S-test4:CreateNewLineFromSocket: * 1 FETCH (UID 1 RFC822.SIZE 275995 FLAGS (\Seen) BODY[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {651}^M 2011-01-24 19:11:15.100954 UTC - -614467840[7fb8dbd88360]: db6b5000:MYSERVER:S-test4:STREAM:OPEN Size: 275995: Begin Message Download Stream It wasn't clear to me if I was supposed to try that with and without the quotes, but I tried it with. Where does that leave us? - Phil
Content-Transfer-Encoding: 7bit should be valid without the quotes. It appears though that your IMAP server implies "7bit" if no CTE is given, but omits the necessary quotes in the IMAP protocol if that default is applied, whereas the non-default values are quoted correctly. David, WADA: Do you concur? Would this bug report be "invalid" in this case, or is there anything the IMAP backend could do to catch this minor violation?
BTW, I believe we have a support contract with MS, so we can probably file a bug if need be. Just so I understand, what is it not quoting that should be? It's not the "7bit" in the CTE, but the "7BIT" in the BODYSTRUCTURE response? FWIW, this is a standard Exchange IMAP server, so even if MS is wrong, working around this would be beneficial to legions of people stuck with Exchange. :)
(In reply to comment #18) > Just so I understand, what is it not quoting that should be? It's not the > "7bit" in the CTE, but the "7BIT" in the BODYSTRUCTURE response? Correct, quoting the 7bit in the CTE header of the message is not necessary whereas quoting of the "7BIT" in the IMAP response is mandatory (comment #15). > FWIW, this is a standard Exchange IMAP server, so even if MS is wrong, working > around this would be beneficial to legions of people stuck with Exchange. :) That was my thinking too, as long as it can be solved unambiguously and with some reasonable effort. I don't know enough to make that assessment, though.
Summary: Certain Messages cause TB to logout after getting body structure → Certain Messages cause TB to logout after getting body structure (Microsoft Exchange IMAP, no Content-Transfer-Encoding in MIME part)
Some sites are found by Google search for ""ms exchange content-transfer-encoding bodystructure". http://mailman2.u.washington.edu/pipermail/alpine-info/2008-November/001389.html > On Wed, 26 Nov 2008, ... wrote: > (BODYSTRUCTURE (("TEXT" "PLAIN" ("charset" "iso-8859-1") NIL NIL > "QUOTED-PRINTABLE" 11 0 NIL NIL NIL NIL)("MESSAGE" "RFC822" NIL NIL NIL MS Exchange in 2008 looks to have returned NIL if no Content-Transfer-Encoding header. http://postmaster.ge/blog/post/Exchange-Server-2007-Summary-KBs-January-2010.aspx > Exchange Svr Ent 2007 AL: When an IMAP4 client sends a FETCH (bodystructure) > request to a server that is running the Exchange Server 2007 IMAP4 service, > a corrupted response is sent as a reply > http://support.microsoft.com/kb/975918/EN-US http://support.microsoft.com/kb/975918/EN-US > Article ID: 975918 - Last Review: January 22, 2010 - Revision: 1.0 > This issue occurs when the Exchange 2007 server responds to a FETCH (bodystructure) request. > The response message does not contain a Content-Transfer-Encoding field in > the MIME header of each body part of the message. When this field is missing, > the Exchange 2007 server sets the body-fld-enc parameter of the > Content-Transfer-Encoding field to the NIL value. >(snip) > To resolve this issue, download and install Update Rollup 2 for Exchange Server 2007 Service Pack 2. I think bug of fix in the service pack of Exchange server. MS changed from NIL to 7BIT if no Content-Transfer-Encoding header or no parameter in Content-Tranfer-Encoding header, but forgot to quote it. I guess that many of currently used Exchange server still returns NIL then Tb does't report syntax error and processes it correctly even if MS Exchange server is used. I believe that fix of apparent MS Exchange's bug should be requested first. If MS replys "it'll take 10 years to fix it", Tb's workaround of MS's bug will probably be required, as usual. Phil Dibowitz, which version of MS Exchange do you use? No new Service Pack for it yet? Note: Following is search result for "bodystructure" at support.microsoft.com. http://support.microsoft.com/search/default.aspx?query=bodystructure&catalog=LCID%3D1033&mode=r I couldn't find newer article relevant to bodystructure than MSKB 975918.
Summary: Certain Messages cause TB to logout after getting body structure (Microsoft Exchange IMAP, no Content-Transfer-Encoding in MIME part) → Certain Messages cause TB to logout after getting body structure (Microsoft Exchange IMAP, no Content-Transfer-Encoding in MIME part, MS Exchange returns 7BIT without quote in BODYSTRUCTURE response)
According to "help" the WebUI: Mailbox server Microsoft Exchange version: 14.1.218.0 But there's also another version listed: "Version: 14.1.218.13" Getting a service pack from Microsoft is *never* a fast issue, and rolling out a new mail server is a lot more effort than a new client. I think recognizing '7BIT' in addition to '"7BIT"' seems like a not-too-large change.
I'm not sure how much work it will be to change the parser to allow invalid IMAP protocol in this case will be, but I'll check.
(In reply to comment #21) > "Version: 14.1.218.13" Microsoft Exchange Server 2010 Service Pack 1 (SP1) looks "14.1.218.15". > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b > Microsoft Exchange Server 2010 Service Pack 1 (SP1) > Version: 14.01.0218.015 > Date Published: 8/24/2010 Phil Dibowitz, can you ask MS about whether bug of "unquoted 7BIT" is already known and fix for it is included in SP1 if already known? (I guess unknown bug then hotfix doesn't exist yet)
I've asked our Internal IT team to ask... - Phil
I spoke to one of our exchange admins and he doesn't see any mention of this in the docs on SP1 or known issues with exchange. He's willing to file a bug (I need to generate a better example, but I should be able to do that). However, in both his and my experience a patch for this is unlikely to appear in the near future, so if we can work around this it would be really useful.
WADA - I've provided good test messages to my exchange guy who will follow up with Microsoft. But don't hold your breath. :) David - Any word on being able to work around this? FWIW, mutt and others I've tried don't choke on this, so hopefully it's not too much work. - Phil
(In reply to comment #26) > WADA - I've provided good test messages to my exchange guy who will follow up > with Microsoft. But don't hold your breath. :) > > David - Any word on being able to work around this? FWIW, mutt and others I've > tried don't choke on this, so hopefully it's not too much work. > No, I'm swamped with other stuff.
As far as I can tell, this was fixed in a more recent version of Exchange...
thanks Phil
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.