You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Rick McGuire (JIRA)" <se...@james.apache.org> on 2008/06/25 12:59:45 UTC
[jira] Created: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
RemoteDelivery convertTo7Bit() can corrupt message content.
------------------------------------------------------------
Key: JAMES-846
URL: https://issues.apache.org/jira/browse/JAMES-846
Project: James
Issue Type: Bug
Reporter: Rick McGuire
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated JAMES-846:
----------------------------------
Fix Version/s: (was: Trunk)
3.0
Affects Version/s: (was: Trunk)
> 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
> Reporter: Rick McGuire
> Assignee: Stefano Bagnara
> Fix For: 2.3.2, 3.0
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608494#action_12608494 ]
Stefano Bagnara commented on JAMES-846:
---------------------------------------
Great!! Thank you! This patch solve an issue I noticed since months on my james and I didn't find the time to track until today! Today I reproduced it and saw that your patch fixed it! :-)
I'm going to apply it.
> RemoteDelivery convertTo7Bit() can corrupt message content.
> ------------------------------------------------------------
>
> Key: JAMES-846
> URL: https://issues.apache.org/jira/browse/JAMES-846
> Project: James
> Issue Type: Bug
> Reporter: Rick McGuire
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
Posted by "Rick McGuire (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire updated JAMES-846:
-------------------------------
Attachment: remotedeliver.patch
Recommended patch for this error. In addition to setting the content, this only adjusts the transfer encoding if the current encoding is 8bit.
> RemoteDelivery convertTo7Bit() can corrupt message content.
> ------------------------------------------------------------
>
> Key: JAMES-846
> URL: https://issues.apache.org/jira/browse/JAMES-846
> Project: James
> Issue Type: Bug
> Reporter: Rick McGuire
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.2 release? (Was: [jira] Resolved: (JAMES-846))
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jun 27, 2008 at 8:36 AM, Norman Maurer <no...@apache.org> wrote:
> Am Freitag, den 27.06.2008, 09:25 +0200 schrieb Stefano Bagnara:
>> Norman Maurer ha scritto:
>> > Hi all,
>> >
>> > I think which this fix it's definitly time for a new james 2.3.2
>> > release.
>> >
>> > What you thought ?
>>
>> https://issues.apache.org/jira/browse/JAMES/fixforversion/12312493
>>
>> IMHO
>>
>> JAMES-589 - Build Debian and Ubuntu packages of james
>> - Can be moved to Trunk (unless you plan to work on it soon)
>>
> Yeah let us move it.. I will take care..
>
>> JAMES-770 - Exception when runnning JAMES with run.sh
>> - Can be resolved as "won't fix". It about running james under windows
>> using cygwin. We provide a run.bat for windows, no need to support
>> cygwin, IMHO.
>
> +1
>
>>
>> Yesterday I fixed some of the other doc/build issue you see listed in 2.3.2.
>>
>> I don't need a 2.3.2 release but I'll +1 any attempt to do this :-)
>>
>> Stefano
>
> I think It would be a good step to push a new 2.3.x release ( release
> often ;) ) ...
release early, release often :-)
with a little bit of luck we might be able to see quite a number of
releases this july
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.2 release? (Was: [jira] Resolved: (JAMES-846))
Posted by Norman Maurer <no...@apache.org>.
Am Freitag, den 27.06.2008, 09:25 +0200 schrieb Stefano Bagnara:
> Norman Maurer ha scritto:
> > Hi all,
> >
> > I think which this fix it's definitly time for a new james 2.3.2
> > release.
> >
> > What you thought ?
>
> https://issues.apache.org/jira/browse/JAMES/fixforversion/12312493
>
> IMHO
>
> JAMES-589 - Build Debian and Ubuntu packages of james
> - Can be moved to Trunk (unless you plan to work on it soon)
>
Yeah let us move it.. I will take care..
> JAMES-770 - Exception when runnning JAMES with run.sh
> - Can be resolved as "won't fix". It about running james under windows
> using cygwin. We provide a run.bat for windows, no need to support
> cygwin, IMHO.
+1
>
> Yesterday I fixed some of the other doc/build issue you see listed in 2.3.2.
>
> I don't need a 2.3.2 release but I'll +1 any attempt to do this :-)
>
> Stefano
I think It would be a good step to push a new 2.3.x release ( release
often ;) ) ...
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
2.3.2 release? (Was: [jira] Resolved: (JAMES-846))
Posted by Stefano Bagnara <ap...@bago.org>.
Norman Maurer ha scritto:
> Hi all,
>
> I think which this fix it's definitly time for a new james 2.3.2
> release.
>
> What you thought ?
https://issues.apache.org/jira/browse/JAMES/fixforversion/12312493
IMHO
JAMES-589 - Build Debian and Ubuntu packages of james
- Can be moved to Trunk (unless you plan to work on it soon)
JAMES-770 - Exception when runnning JAMES with run.sh
- Can be resolved as "won't fix". It about running james under windows
using cygwin. We provide a run.bat for windows, no need to support
cygwin, IMHO.
Yesterday I fixed some of the other doc/build issue you see listed in 2.3.2.
I don't need a 2.3.2 release but I'll +1 any attempt to do this :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Resolved: (JAMES-846) RemoteDelivery convertTo7Bit()
can corrupt message content.
Posted by Norman Maurer <no...@apache.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-846) RemoteDelivery convertTo7Bit() can
corrupt message content.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated JAMES-846:
----------------------------------
Component/s: Remote Delivery
Affects Version/s: Trunk
2.3.1
Fix Version/s: Trunk
Assignee: Stefano Bagnara
> 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: 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org