Re: Parsing a MimeMultipart :: Test case

remi__ wrote:
> As you suggested, here is the answer of themail server I use.
>
> * 23 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET"  
> "windows-1252") NIL
> NIL "7bit" 9 1)("TEXT" "PLAIN" ("NAME" "file") NIL NIL "base64"  
> 2516 33 NIL
> ("attachment" ("FILENAME" "file")))("TEXT" "PLAIN" ("NAME" "file")  
> NIL NIL
> "base64" 2516 33 NIL ("attachment" ("FILENAME" "file")))("TEXT"  
> "PLAIN"
> ("NAME" "file") NIL NIL "base64" 2516 33 NIL ("attachment" ("FILENAME"
> "file")))("TEXT" "PLAIN" ("NAME" "file") NIL NIL "base64" 2516 33 NIL
> ("attachment" ("FILENAME" "file")))("TEXT" "PLAIN" ("NAME" "file")  
> NIL NIL
> "base64" 2516 33 NIL ("attachment" ("FILENAME" "file")))  
> "MIXED" ("BOUNDARY"
> "----=_Part_0_31379709.1179480493454") NIL NIL))
>
> And here is the output of my test case:
>
> Content-Type: text/plain; name=file
> Content-Transfer-Encoding: 33
> javax.mail.MessagingException: Unknown encoding: 33
> 	at javax.mail.internet.MimeUtility.encode(MimeUtility.java:240)
> 	at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:804)
> 	at TestGNUMail.displayMail(TestGNUMail.java:61)
> 	at TestGNUMail.test(TestGNUMail.java:45)
> 	at TestGNUMail.main(TestGNUMail.java:33)
> Content-Id: base64
> Content-Description: 2516
>
> It seems that the "2516 33" pattern is recurrent in the answer. Is  
> that
> supposed to be so? I have no knowledge in the IMAP protocol.

The response looks mostly normal. It appears to have a content- 
disposition in the extension where a content-language is expected,  
but that certainly shouldn't break anything and would not cause the  
content-id, content-description, and content-transfer-encoding to  
have the wrong values.

Maybe the parsing of the IMAP structure is broken at a lower level.  
If you have access to a debugging environment, could you post the  
value of "list" in the IMAPMessage.parseMultipart method during  
execution of your program?