Guillermo Grandes (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JAMES-648?page=comments#action_12439680 ]
Guillermo Grandes commented on JAMES-648:
-----------------------------------------
Anyway... My big problem is not the "ó" corrupted in an "ó", my problem is the corrupted
Mime Boundary "------_=_NextPart_000_01C0B2DF.DE9D0F20"
IMHO... this is not... "normal"
if I add the missing header "Content-Transfer-Encoding: 7bit" or "8bit", the
mime-boundaries are OK and message is not corrupt, this is my question, why JavaMail use
"quoted-printable" for missing header instead of Xbit?
IMO, if a char >127 is found in the stream and no header is set, we have 2
options:
1) recode the chars with =HH and set quoted-printable
2) set header to 8bit
this is the correct, right?
Sorry but I didn't understand where is currupted the mime boundary: I
just looked at message source and it seems that the mime boundary is
untouched. Can you tell me more?
Btw, I read all of your story but you are concentrated on a non-issue:
the problem is that most other mail servers support 8bitmime while we
don't: if we correctly supported 8bitmime your message would probably pass.
Now we should probably reject it: I think this is what most non-8bitmime
servers did in past (now there are really few of them around).
So IMHO the solution is make 8bitmime to work in an RFC compliant way:
and I bet this will solve your issue. Otherwise you don't have enough
information to deal with the corrupted incoming message without
corrupting it even more.
I worked a lot to make 8bitmime working in 2.3.0 but we had to
disable/revert my changes because I found a lot of bugs in javamail that
prevented us to work safely with 8bit data. I still am the assignee of
the 8bitmime support issue (JAMES-52) but I cannot invest more time on
it until javamail will fix blocking issues.
https://issues.apache.org/jira/browse/JAMES-52?page=all
Please consider that I'm not against relaxed interpretation of the RFC
(and you can read my opinion on the bracket thing, or any other topic in
past) but I think that supporting a relaxed interpretation is MUCH MORE
difficult and HAVE TO BE carefully designed to be sure you don't
introduce more problems than you solve them and I think that if you
start reading non-7bit data without even to decide what charset to use
to read that 8bit char or anything similar you already decided to
corrupt the message and you are only lucky if this does not happen.
Btw, can you tell me what is the client that generate such a message
(8bit content sent to a non 8bitmime server and not specifying the
content-transfer-encoding)?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
