Hi all, I think which this fix it's definitly time for a new james 2.3.2 release.
What you thought ? bye Norman Am Donnerstag, den 26.06.2008, 09:57 -0700 schrieb Stefano Bagnara (JIRA): > [ > https://issues.apache.org/jira/browse/JAMES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Stefano Bagnara resolved JAMES-846. > ----------------------------------- > > Resolution: Fixed > Fix Version/s: 2.3.2 > > Applied (with a small refactoring). > > Backported to v2.3 because this is a major issue leading to message > corruption under some circumstance. > > > RemoteDelivery convertTo7Bit() can corrupt message content. > > ------------------------------------------------------------ > > > > Key: JAMES-846 > > URL: https://issues.apache.org/jira/browse/JAMES-846 > > Project: James > > Issue Type: Bug > > Components: Remote Delivery > > Affects Versions: 2.3.1, Trunk > > Reporter: Rick McGuire > > Assignee: Stefano Bagnara > > Fix For: 2.3.2, Trunk > > > > Attachments: remotedeliver.patch > > > > > > This is something I ran into while fixing the Geronimo javamail bugs, and > > noticed that the RemoteDelivery code has the same problem. In the > > convertTo7Bit() method, the transfer encoding is unconditionally set to > > either quoted-printable or base64 depending on the MIME type. This can > > make the content invalid when transmitted as mail > > To understand the reason, you need to understand how MimeMessage holds the > > content internally. The content can exist in one of two forms: 1) The > > real content object, or 2) the content encoded as a byte array. In case > > 1), the Content-Transfer-Encoding indicates how the content WILL BE encoded > > when written to a stream. In case 2), the Content-Transfer-Encoding > > indicates how the content IS encoded in the byte array. In the first case, > > setting the transfer encoding works ok. In the second case, it's changing > > how the already encoded information will be interpreted. I've confirmed > > this to be the case with the Sun implementation as well. > > I ran into the reverse aspect of this problem with the implementation of > > the 8BITMIME support. It was not sufficient to just set the > > Content-Transfer-Encoding header to convert this to 8bit. It was necessary > > to call getContent(), then set the same content back on the message. Once > > that was done, it was safe to change the Content-Transfer-Encoding header. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
