Tomcat error opening html email attachment

[psalm121]

I'm getting the following error when opening an email with a file attached which happens to be an html file

"java.io.IOException: Error in encoded stream: needed at least 2 valid base64 characters, but only got 0 before padding character"

I googled this error and found a solution to do with javamail which I think zimbra uses partly the solution was to:

set javamail "mail.mime.base64.ignoreerrors=true".

However I don't know where I'd go about changing this setting in the Zimbra files.

Does anyone have any ideas?

Thanks.

[phoenix]

You would have found an answer in these forums here

[psalm121]

I did search the forums but I don't think this is the same thing, it is the same problem with 3 seperate message from the same origin. Can't see how the attachment is getting messed up each time. I could see how it might be a one off corrupt message but not each time.

Maybe I'm missing the point of the other thread, if so could you explain the solution?

I did check that both rpm's where installed and it's all OK.

Does anyone have any ideas? This is a deal breaker for my customer. No HTML attachments, no Zimbra as far as he is concerned.

Thanks in advance for any help your able to give.

[psalm121]

Hi all,

I manually edited the msg files that were giving problems as error message was indicating extraneous characters at the end of the base64 encoding

removing the extra characters solved the problem.

This tells me that this is to do with the rubbish formatting of the sender's email, unfortunately it is a government department that is sending the email so they're probably not going to listen to me when I tell them to fix their rubbish encoding.

It also leaves me with the problem that every other mail client handled it without a problem.

I still believe that it is to do with the "mail.mime.base64.ignoreerrors" property for the JavaMail API

If I can set this property to true I can sort the problem. At the moment this property must be set to false as this causes an exception due to malformatted encoding.

Does anyone have any ideas where I set this property for Zimbra????

Please???

[phoenix]

I'm not sure how the users in the other thread fixed that problem, I also don't know where that property is in the zimbra code. You could try filing a bugzilla report for it and see if zimbra can do anything to alleviate the problem. I deal with Government departments quite often and they are usually quite attentive when they get a reported problem with their email, mind you I guess it depends on which Government you're talking about. Have you tried contacting the people that sent the email and telling them their server isn't up to the job.

[psalm121]

I narrowed down the problem to a design issue with 64 bit decoder within the Java language itself.

The default behaviour is to throw an exception when it encounters a fault in the 64 bit encoded stream. This is very strict behaviour and causes a problem when turned on for end users as it's very hard to guarantee that there will be no errors in an encoded stream bearing in mind the number of different methods people are using to send email (the most problematic being custom hand coded methods like messages sent from websites using php etc. ) Most mail clients do not have this strict behaviour when interepreting 64 encoded data and so ignore the error, this usually does not cause a problem as the error is almost always at the end of the stream after the important data.

This strict behaviour can be turned off by setting a system property for Java, the one I mentioned in my previous post. I think system properties can be set in tomcat, but I haven't figured out where yet!

I think I will post this to bugzilla!

(I'll also try to post to the government department sending the emails out)

Thanks for your help in the first place!

[phoenix]

I don't know why Zimbra is enforcing strict behaviour on the 64bit encoding but they might change it. Yes, indeed, it's no good having this sort of behaviour if end-users keep seeing a problem that they probably don't understand. Perhaps an admin option to turn this behaviour on/off might be mmore useful?

If you file in bugzilla don't forget to vote on it, you could also post a note back here with the bug number just in case anyone else hits the problem.