You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Originally submitted to Sun bug system, transferred to Oracle bug system,
and finally here for resolution.
Originally submitted by sun@bago.org on 2006-08-02 18:22:38.)
EXTRA RELEVANT SYSTEM CONFIGURATION :
Input mail contains 8bit parts, remote server does not support 8bitmime
A DESCRIPTION OF THE PROBLEM :
Javamail smtp transport does not check the remote server to see wether it
supports 8bitmime before sending 8bit mails.
This is not a problem with messages created via apis, but it is an issue when
the message come from a stream and already contains 8bit chars.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a message from stream.
Be sure that this message contains a "Content-Transfer-Encoding: 8bit" and
8bit content.
Send it to an smtpserver that do not support the ESMTP 8BITMIME extension.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When a MimeMessage is created from a stream, the stream contains 8bit
contents (Content-Transfer-Encoding: 8bit) and we send it to a remove server
not supporting 8bitmime Javamail should automatically convert the content to
7bit.
ACTUAL -
The message is not converted and is refused/corrupted by the remote server.
REPRODUCIBILITY :
This bug can be reproduced always.
Affected Versions
1.4.3
Environment
All
All
The text was updated successfully, but these errors were encountered:
@glassfishrobot Commented @bshannon said:
It would be expensive to check every message for this issue since it
rarely happens. There's currently an option to convert 7bit messages
to 8bit when possible. It's a bit of a kludge, and not perfect, but
a similar approach could be considered for this case.
@glassfishrobot Commented
javahollic said:
we're starting to see more and more 8bit mime messages, despite 8bit messages being illegal in SMTP use AFAIK. It would indeed be expensive to check a message recursively, however, as happens, I use the Message.writeTo anyway, we find this resolves quite a few syntax issues anyway, it would be perfect if this could also be made to convert the content to 7bit as it went.
(Originally submitted to Sun bug system, transferred to Oracle bug system,
and finally here for resolution.
Originally submitted by sun@bago.org on 2006-08-02 18:22:38.)
EXTRA RELEVANT SYSTEM CONFIGURATION :
Input mail contains 8bit parts, remote server does not support 8bitmime
A DESCRIPTION OF THE PROBLEM :
Javamail smtp transport does not check the remote server to see wether it
supports 8bitmime before sending 8bit mails.
This is not a problem with messages created via apis, but it is an issue when
the message come from a stream and already contains 8bit chars.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a message from stream.
Be sure that this message contains a "Content-Transfer-Encoding: 8bit" and
8bit content.
Send it to an smtpserver that do not support the ESMTP 8BITMIME extension.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When a MimeMessage is created from a stream, the stream contains 8bit
contents (Content-Transfer-Encoding: 8bit) and we send it to a remove server
not supporting 8bitmime Javamail should automatically convert the content to
7bit.
ACTUAL -
The message is not converted and is refused/corrupted by the remote server.
REPRODUCIBILITY :
This bug can be reproduced always.
Affected Versions
1.4.3
Environment
All
All
The text was updated successfully, but these errors were encountered: