Bad to address when replying to message (jsmime problem?)

RESOLVED DUPLICATE of bug 1130248

Status

MailNews Core
MIME
--
major
RESOLVED DUPLICATE of bug 1130248
2 years ago
2 years ago

People

(Reporter: Jorg K (GMT+2), Assigned: rkent)

Tracking

({regression})

x86_64
All
regression

Thunderbird Tracking Flags

(thunderbird38 affected, thunderbird39 affected, thunderbird40 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8602700 [details]
EML file showing the problem

Import the attached messages and hit "Reply All".
What you get is a really badly formed to address.

As far as I can see, the message is not even malformed, the header:
To: =?iso-8859-1?Q?Hans-Joachim_Wollschl=E4ger_=28hj=2Ewollschlaeger=40t-onli?=
 =?iso-8859-1?Q?ne=2Ede=29?= <hj.wollschlaeger@t-online.de>
is legal and is also decoded successfully and displayed correctly in the message header display in the message pane.

The resulting address is:
"=?UTF-8?Q?Hans-Joachim_Wollschl=c3=a4ger_=28hj.wollschlaeger@t-online.de=29?=hj.wollschlaeger"@t-online.de

I think we have a problem if users can't reply to e-mail. I sent the message out without noticing.
(Reporter)

Updated

2 years ago
Severity: normal → major
(Reporter)

Comment 1

2 years ago
Sorry Kent, another one you won't like for your kind attention.
Looks a bit like bug 1130248, only that there are no quotes in the header.
The mangling is just the same as in the other bug.

Perhaps not a jsmime problem at all but a problem in the interface between jsmime and message compose window, refer to bug 1130248 comment #7.
status-thunderbird38: --- → affected
status-thunderbird39: --- → affected
status-thunderbird40: --- → affected
tracking-thunderbird38: --- → ?
Flags: needinfo?(kent)
(Reporter)

Comment 2

2 years ago
I'm sure Neil can help us here ;-)
Flags: needinfo?(neil)
OS: Unspecified → All
Hardware: Unspecified → x86_64
See Also: → bug 1130248
Version: unspecified → 38
(Reporter)

Comment 3

2 years ago
Regression: works OK in 31.6
Keywords: regression
(Assignee)

Comment 4

2 years ago
Thanks jorg for the clear example, I'll be looking at this.
Assignee: nobody → rkent
(Assignee)

Comment 5

2 years ago
According to my tests, I can see this bug in beta 4, but I do not see it when bug 1141446 is landed, as it will be in beta 5. So I believe this is just a duplicate of bug 1141446. Jorg can you confirm this?

(On another note, I changed the address that I use for BMO from kent@caspia.com to rkent@caspia.com so that the short form of my name would match my handle. Please do not cc kent@caspia.com, use rkent@caspia.com instead.)
Flags: needinfo?(neil)
Flags: needinfo?(mozilla)
Flags: needinfo?(kent)
(Reporter)

Comment 6

2 years ago
(In reply to Kent James (:rkent) from comment #5)
> According to my tests, I can see this bug in beta 4, but I do not see it
> when bug 1141446 is landed, as it will be in beta 5. So I believe this is
> just a duplicate of bug 1141446. Jorg can you confirm this?

I cannot confirm this.
I made the change that was made for bug 1141446 in my local build, and the bug is still there.
The change for bug 1141446 was rfc2047-decoding all quoted strings.

The header in question:
To:	=?iso-8859-1?Q?Hans-Joachim_Wollschl=E4ger_=28hj=2Ewollschlaeger=40t-onli?=
 =?iso-8859-1?Q?ne=2Ede=29?= <hj.wollschlaeger@t-online.de>
has no quotes, so the fix from bug 1141446 doesn't apply.

However, another change to jsmime was landed, bug 1069790. That was far more than a one line change, perhaps that fixed it. Bug 1069790 was landed after beta4, so that is more likely to have fixed it.
Reading bug 1069790 again: That must be it, since it had to do with parenthesis and the decoded header is: Hans-Joachim Wollschläger (hj.wollschlaeger@t-online.de) <hj.wollschlaeger@t-online.de>
Flags: needinfo?(mozilla)
(Reporter)

Comment 7

2 years ago
Something fishy here, Kent. I tried in a recent build with the bug 1141446 fix included. Still getting:
"Hans-Joachim Wollschläger (hj.wollschlaeger@t-online.de)hj.wollschlaeger"@t-online.de

You claim it's fixed and you also claim bug 1130248 is fixed which I also cannot confirm.

So what have you got that I don't have?

Note: trunk and beta are almost the same at the moment, only difference being
http://hg.mozilla.org/comm-central/diff/1cf79e3da57a/mailnews/mime/jsmime/jsmime.js

So for all intents and purposes, they should behave the same.

However, I'm not even sure this is a jsmime problen. Perhaps it got silently fixed some other way.
(Reporter)

Comment 8

2 years ago
Refreshed local build: $ hg pull -u ... (can't do python client.py checkout due to bug 777770)
added 10 changesets with 13 changes to 10 files (+1 heads)

Problem persists in locally compiled version.
(Reporter)

Comment 9

2 years ago
Ask for help again.
Flags: needinfo?(neil)
Flags: needinfo?(Pidgeot18)
(Reporter)

Comment 10

2 years ago
Sorry, my local build had a problem (I've cleaned it out now "hg up --clean -r default") but I still need to get TB to build, which is a pain due to bug 777770).
So perhaps I gave you the wrong answer and you are right that it's fixed.
To be continued in a few hours when I can check it again.
(Reporter)

Comment 11

2 years ago
With M-C a rev 617dbce26726 (due to bug 777770) and C-C at rev d3090583a3cb (due to compile problems after landing bug 1163331) I observe the following:
The problem persists, recipient still:
"Hans-Joachim Wollschläger (hj.wollschlaeger@t-online.de)hj.wollschlaeger"@t-online.de
Kent: I think you owe me one for the wild-goose chase you sent me on.
(Reporter)

Comment 12

2 years ago
Let's not confuse bug 1162477 and bug 1130248:
To reproduce this bug 1162477 do "Reply" all, for bug 1130248 do "Compose Message To".
The other way around it all works.
(Reporter)

Comment 13

2 years ago
Karsten, you worked on bug 1069790, could you help with this one?
Flags: needinfo?(mnyromyr)
(Assignee)

Comment 14

2 years ago
OK the nature of the problem changed from comment 0 in beta 4, but as you noted in comment 11 it was still incorrect.

But at the risk of being wrong again, I no longer see the issue with my patch from bug 1130248 applied. The bugs are similar, but in this bug the address is buried in a comment inside of RFC 2047 encoding. I believe that the previous code correctly handled an address inside of a comment (or at least that is included in one of the tests) without RFC 2047 encoding, so it must be the combination of comment-in-address with RFC 2047 that was confusing.

So I'm not exactly sure it is a duplicate, but unless you can show me another problem I won't block on this, at least given that we are blocking on bug 1130248.
tracking-thunderbird38: ? → ---
(Reporter)

Comment 15

2 years ago
I suspected it had to do with bug 1130248. So most likely you've hit two birds with one stone.
(Reporter)

Comment 16

2 years ago
With the patch from bug 1130248 this cannot be reproduced.
I applied the patch, problem went away, then I popped the patch, problem returned.

However, as stated in the other bug: The patch is suboptimal. Besides, I'd like to see an explanation why the patch fixes this problem too. "Works by accident" is possibly not a good solution.
(Reporter)

Comment 17

2 years ago
Sorry for my silly hasty comment #16. I can see now that this is a duplicate of bug 1130248 and how the patch fixes it. The common element is the e-mail address in the name part.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(neil)
Flags: needinfo?(mnyromyr)
Flags: needinfo?(Pidgeot18)
Resolution: --- → DUPLICATE
Duplicate of bug: 1130248
You need to log in before you can comment on or make changes to this bug.