james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jira] Commented: (JAMES-648) Corrupted MIME message with 8bit in body
Date Wed, 04 Oct 2006 07:39:46 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message