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 14:47:05 GMT
Guillermo Grandes wrote:
> [20 comments on Jira]
> Well, In measure that I discover anything I comment these on Jira.
> [Use mailing]
> Ok, but I supposed that comment in Jira was better for register of work
> done. I use Jira for track info and Mailing for oppinions.

Ok, I just wanted to keep conversations/opinions for the mailing list. 
TO be clear I'm guilty for this, also. So it was a "please" for 
everyone, including me.

> [Reject]
> Good, in some cases is better, but... In many others... the mails are
> generated by automatic systems, examples:
> - James-642, missign brackets, by Oracle / Facturation Systems, nightly 
> this
> send mails with new registers, notifies facturation state's.

I already said my opinion: imho we should support this by default. But 
other committers don't agree, so we have probably to vote about this, 
and for sure this won't happen for 2.3, so there is no hurry now.
I hope that the patch temporarily works for you, in the mean time.

> - James-648, missing 7/8bit header, by HP OpenView ServiceDesk (management
> of incidences, seemed to Jira, but greater), mail arrives and now user can
> see the NextPart-boundary in the mail-reader (this is the corrupt efect,
> mail is interpreted as plain-text instead of multipart in the mail-reader).
> - non-issued, also missing 7/8bits header, process of register (automatic)
> in a system of tickets for management of work orders, this send a url to
> mail: "http://pepe/register.dll?user=41223483" to confirm the sign-in, but
> the mail-reader see: "http://pepe/register.dll?usera223483" and register
> can't be completed, I suppose that the problem is like James-648 (the
> problem with this application is that the company that made the
> development... closed -bankruptcy-, We can't correct this).

Yes, they are both the same issue and it is the result of a serie of 

1. Your client is issuing 8bit chars in an HELO conversation (RFC2821 
don't allow this).

2. Javamail when have to serialize a parsed message try to understand 
wether it was 8bit or not, and if it was 8bit it try to convert it to 
quoted-printable: there is a bug that prevent this from working and make 
javamail to add the quoted-printable header and to not convert the content.

3. Once saved javamail reopen it, and it is a quoted-printable having an 
"=41" in the content so it reads it as an "a" and corrupt it.

A similar problem also exists with some email client writing 8bit chars 
in headers: Unfortunately there is not a clean way to handle this. What 
encoding should you use? How should you convert them?

> These are only comments/examples of why don't reject if another option is
> possible...

Agree, but if another "GOOD" and compliant option is possible.
Currently I don't have such an option for this problem but waiting for 
javamail to fix the bug and for us to correctly support 8bitmime.
Maybe you have this option, or maybe we can find this tomorrow or the 
next month.

> [I think that supporting a relaxed interpretation is MUCH MORE difficult]
> Yes, I know,... the life is thus.

You trucated the line. This way make no sense.
I said that supporting the relaxed intepretation was much more difficult 
than supporting 8bitmime that is an rfc spec and would have probably 
solved your problem anyway. But this was only a consideration: I don't 
have time to work on any of this issue now.

> [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?]
> Yes, the message always is untouched (and is received/interpreted well by
> mail-reader) EXCEPT when you modify mail in a mailet/use:
>    mail.getMessage().saveChanges();
> In this moment JavaMail change headers (sets the missing header:
> Content-Transfer-Encoding: quoted-printable) and... the outbound mail 
> -seems
> good at first- is not good. My try to fix this is set missing header with
> 7bit/8bit (and work. Norman question if JAMES-638 is related. is possible?
> that affect locally-generated or modified?. I don't known)

But does it happen only when there is an 8bit char or always?

About the 8bit sender client can you confirm that your client is using 
HELO (like you reported in the attached test) *AND* *NOT* EHLO? Sorry if 
I ask again but I don't want to fix a problem I don't understand.
Furthermore I see that in the first attachment the input mail has 2 
Content-Type headers: how can we know what is the right one to use?

> 220 ESMTP Server
> HELO xxxxxxXX.com
> 354 Ok Send data ending with <CRLF>.<CRLF>
> MIME-Version: 1.0
> Reply-To: <xxxxx>
> From: "xxxxxx" <xxxxx>
> To: <xxxxx>
> Date: Thu, 28 Sep 06 18:26:46 +0200
> Subject: xxxx #xxxx xxxx
> X-Mailer: hp OpenView service deskMail Manager 4.5
> Content-Type: text/plain; charset=iso-8859-1
> Content-Type: multipart/mixed; 
> boundary="----_=_NextPart_000_01C0B2DF.DE9D0F20"
> ------_=_NextPart_000_01C0B2DF.DE9D0F20

It seems that the boundary is not corrupted and that the problem of the 
not-parsed message is not related to any bug but with the fact that the 
input mail has 2 Content-Type headers and the results depends on what 
header is considered when parsing it.

Here the problem with not converted quoted-printable corrupt even more 
the message but either way the 2 Content-Type headers is a non 
deterministic problem: do you agree?

> X-Gmail-Received: 26fbd7e0457be0aef010efa76cd5441d171d805f
> [...]
> Content-Transfer-Encoding: quoted-printable
> [...]
> Content-Type: text/plain; charset=iso-8859-1
> Content-Type: multipart/mixed; 
> boundary="----_=_NextPart_000_01C0B2DF.DE9D0F20"
> ------_=3D_NextPart_000_01C0B2DF.DE9D0F20

I see that project glassfish started to fix a few of the bugs I reported 
against javamail: imho it worth investigating more on this as soon as 
they will release a new beta.

If you have time to work on this here is the link:
And here is the last commit comment (from 2 weeks ago):
Issue number:
Cummulative changes since JavaMail 1.4:
4107594 IMAP implementation should use the IDLE extension if available
6423701 Problem with using OrTerm when the protocol is IMAP
6431207 SMTP is adding extra CRLF to message content
6447295 IMAPMessage fails to return Content-Language from bodystructure
6447799 encoded text not decoded even when mail.mime.decodetext.strict 
is false
6447801 MimeBodyPart.writeTo reencodes data unnecessarily
6456422 NullPointerException in smtptransport when sending MimeMessages
         with no encoding
6456444 MimeMessages created from stream are not correctly handled
         with allow8bitmime
<no id> fix performance bug in base64 encoder; now even faster!
<no id> throw MessageRemovedException from getContent for IMAP messages
<no id> MimeUtility.decodeText should not discard trailing whitespace
<no id> SSLSocketFactory should be used for imap and smtp STARTTLS commands
<no id> added mail.<prot>.ssl.protocols and mail.<prot>.ssl.ciphersuites


Obtained from: JavaMail 1.4.1ea

6447801 and 6456444 may both be related to what we are talking about.
Not sure if this sources are the same of 1.4.1ea (like the comment say) 
or not.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message