Thank you Mark, I have little information on the server side library used, I'm querying that at the moment. C-client on the end user app side for sure.
Thanks for the RFC reference, that helps to sort it all. Cheers, PatH -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Tuesday, February 12, 2008 6:22 PM To: Patrick Hamel (path) Cc: [email protected] Subject: RE: [Imap-uw] Handling of enclosed message in multipart messages. Here's some additional information about your problem: According to test, the server sent the following as a BODYSTRUCTURE: (("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename" "My.wav")) NIL NIL)("message" "rfc822" NIL NIL NIL NIL 113287 NIL) NIL NIL NIL NIL NIL NIL NIL) ("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename" "My.wav")) NIL NIL) 0 NIL NIL NIL NIL) "mixed" NIL NIL NIL NIL) So let's analyze this. The first part looks good: ("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename" "My.wav")) NIL NIL) But then we get to the next part: ("message" "rfc822" NIL NIL NIL NIL 113287 NIL) This is completely bogus. The relevant RFC 3501 syntax rules start with: body-type-msg = media-message SP body-fields SP envelope SP body SP body-fld-lines media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP body-fld-enc SP body-fld-octets So, we start off with "MESSAGE" and "RFC822"; then body-fld-param, body-fld-id, body-fld-desc, and body-fld-end are all NIL; then body-fld-octets is 113287. So far, so good. But now we see that envelope is NIL, and body and body-fld-lines are completely missing. Checking the syntax for envelope, we see: envelope = "(" env-date SP env-subject SP env-from SP env-sender SP env-reply-to SP env-to SP env-cc SP env-bcc SP env-in-reply-to SP env-message-id ")" So envelope is a field that can not, under any circumstances, be NIL. At this point, all is lost. The server is non-compliant. Then what follows after that is complete nonsense: NIL NIL NIL NIL NIL NIL NIL) ("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename" "My.wav")) NIL NIL) 0 NIL NIL NIL NIL) "mixed" NIL NIL NIL NIL) Note the three spaces after the second NIL. In IMAP syntax, a space is either mandatory or forbidden; and in any case it is exactly one space, never more. Looking further at that line, you see a close paren and...another space! Two problems here. First, the only level of parenthesis at this point is the BODYSTRUCTURE itself, so the BODYSTRUCTURE has ended at this point. Then, there is something that looks like an AUDIO/WAV body part following it, as if it is another body part, but IMAP prohibits spaces between body parts. Now, just assume that we swallow this body part anyway: ("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename" "My.wav")) NIL NIL) We now see: 0 NIL NIL NIL NIL) "mixed" NIL NIL NIL NIL) which is apparently to end the MULTIPART (never mind the broken nesting). However, that would mean that 0 is a media-subtype which is requested to be a string. The end of the MULTIPART is apparently at -2 nesting level where we see a "mixed" which is appropriate. The bottom line is that this IMAP server is completely broken. What server implementation is it? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
