javax.mail.internet.ParseException: Expected ';', got ":"

Hello Everyone,

I get 2 exceptions when I use the MimeMultipart's getCount method on e-mail messages that have either a colon or equals characters.

javax.mail.internet.ParseException: Expected';', got":"

at javax.mail.internet.ParameterList.<init>(ParameterList.java:179)

at javax.mail.internet.ContentType.<init>(ContentType.java:100)

at javax.mail.internet.MimeMultipart.parsebm(MimeMultipart.java:651)

In the above case the Content-Types of the MimeMultipart BodyParts contain colon(s) as in these examples:

Content-Type: multipart/alternative;

boundary="106493654088256";

class-id=2:7dHScNImUABLVHAHX3omUA:1738023

Content-Type: text/plain; charset=us-ascii; class-id=2:5BrQ7RNUzCDbwrCr3G9UzC:1738023

Content-Type: text/html; charset=us-ascii; class-id=2:4O40LtDu6zISq4z4eMKu6z:1738023

I couldn't find any specifications for Content-Type in RFC 822 , which is used by JavaMail.

I don't have control over what the incoming E-Mail messages contain.

Because mimeMultipart.getCount(); throws the above exceptions, I'm unable to count the number of body parts in the e-mails that have these special characters (colon, equals sign) in the Content-Type header.

I am catching the above exception though, so the processing of the rest of the e-mails continues without interruption.

However, is there any way I could get the count of the body parts in a MimeMultipart message that has problematic Content-Types as shown above?

Should I file a bug?

javax.mail.internet.ParseException: Expected';', got"="

at javax.mail.internet.ParameterList.<init>(ParameterList.java:179)

at javax.mail.internet.ContentType.<init>(ContentType.java:100)

at javax.mail.internet.MimeMultipart.parsebm(MimeMultipart.java:651)

In the above case the Content-Types in the Multipart email message are as follows:

Content-Type: multipart/alternative; boundary=-=_NextPart_boundary_000_aPpABvk398f_v.2.0.ENC7bin

=_NextPart_boundary_000_aPpABvk398f_v.2.0.ENC7bin

Content-Type: text/plain; charset=us-ascii

java version "1.5.0_11"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)

Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)

JavaMail version 1.4

-

I searched everywhere, but couldn't find a solution. Most people are facing this problem.

Any help is appreciated.

[2613 byte] By [appy77a] at [2007-11-27 8:28:27]
# 1

If those messages aren't spam, you should definitely contact the

owner of the software that generated those messages and get them

to fix their software. Those messages are incorrectly formatted.

The parameter values need to be quoted when they contain special

characters such as those. The MIME spec is very clear on this.

Dealing with messages that can be incorrectly formated in

arbitrary ways is an endless task. The kinds of problems you're

seeing are relatively infrequent, except in spam. JavaMail doesn't

have a good way to deal with them.

In the worst case, you can catch these parsing errors, make a copy

of the message, attempt to repair the formating error, and parse the

repaired message. This is not easy and typically involvesquite a few

heuristics.

Sorry I don't have a better answer for you...

bshannona at 2007-7-12 20:18:27 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 2

Hi bshannon,

Thank you for your answer, the information you've provided is quite useful.

I think I'm supposed to process all messages regardless of whether they're spam or not.

I will take a look at the MIME spec.

I don't think I have a choice but to deal with incorrect formats, and I've written things for correcting other components of an email.

For the sake of processing multipart messages that raise this exception, I may have to separately count the number of content types and then try to read in each body part.

I haven't tested if I'll be able to read specific message body parts yet. I will be doing that soon.

I'm assigning you 10 dukes.

appy77a at 2007-7-12 20:18:27 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...