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
problems:
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
...
DATA
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:
https://glassfish.dev.java.net/source/browse/glassfish/mail/
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
props
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
