- 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.
I have switched to IIS by the other problems, but also I think that it would
have to go in the 2.3 for all users.
- 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).
correct.
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.
ok.
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?
I only have the attachs. I don't known how these applications work
internally, but in my machines I have tested JVM/James with ISO-8859-1 and
ISO-8859-15
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.
Well, a stone more... is... a stone less (philosophy) :-)
[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.
Have sense, all is difficult, all depends/question of time, "more things,
few time"..., I understand, we will see that we can do :-)
[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?
In this case, depends, if remove 8bits chars, works.
But are more causes (down I explain them).
About the 8bit sender client can you confirm that your client is using
HELO (like you reported in the attached test) *AND* *NOT* EHLO?
Client uses ONLY HELO (is behind a Cisco-PIX)
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?
IMHO think that client "would not have to" send the text/plain if already
send multipart. but I don't know.
----
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.
This is conversation send to James, at this time, no corruption found, the
corruption is made in the first Mailet that modify any header/mail.
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?
----
I don't know, but there is my tests and results:
** With Mailets that set/remove a mime header **
-If manually I substitute chars>8bit for low 7bits, no problem. This works.
Javamail sets 7bits header.
-If manually I sets header Content-Transfer-Encoding with: 7bit o 8bit, This
works. Javamail don't touch the content.
-If manually I remove "Content-Type: text/plain; charset=iso-8859-1", This
works. Javamail don't touch the content.
-If manually I don't touch anything, Javamail set "Content-Transfer-Encoding
with: quoted-printable"
** Without Mailets that set/remove a mime header **
-This works in all cases. Javamail don't touch the content.
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.
Agreed. :-)
Thanks.
Guillermo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
