Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.3.1
-
None
Description
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.