Thunderbird truncates forwarded messages and I know why [involves missing comment closure --> in MSO HTML mix]
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: informatica, Unassigned)
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
Steps to reproduce:
Sometimes, when I have a multi-email conversation with another person, when I forward the email, the other person sees the message truncated (not complete email) if they don't use thunderbird.
Actual results:
The reason is that somewhere in the message code there are the characters "less(<) exclamation mark(!) dash(-) dash(-)" but there aren't the close characters "dash(-) dash(-) higher>" anywhere. And any mail manager(except thunderbird) interprets it as "comment" and stops showing the text in that place. (<!--) but no (-->)
Expected results:
HTML composer should insert character "-->" for close comment
Comment 1•5 years ago
|
||
Hi Miguel, what makes you think that this is a problem of the Thunderbird HTML composer?
The source including the comment tags is clearly produced by an MS-Office application like Outlook or Word.
Thunderbird message editor does not produce comment tags afasik.
Even if you'd copy MSO HTML mix into TB editor and start deleting around, I doubt you would succeed just to remove the closing --> - if you think that is what happens, please provide reproducable steps and test case message.
(In reply to Miguel from comment #0)
Actual results:
The reason is that somewhere in the message code there are the characters "less(<) exclamation mark(!) dash(-) dash(-)" but there aren't the close characters "dash(-) dash(-) higher>" anywhere. And any mail manager(except thunderbird) interprets it as "comment"
It's not true that Thunderbird ignores comment tags: Press Ctrl+A in TB composition, Insert > HTML from the menu, then manually insert <!--foobar--> anywhere: It will be correctly hidden from your composition.
Expected results:
HTML composer should insert character "-->" for close comment
Not sure how you arrive at that expectation, but that's impossible for comment tags which TB hasn't produced, and we don't produce any.
Sorry, but this does not look like a bug in TB --> invalid.
OK, I found a solution.
If Thunderbird option "mail.strip_sig_on_reply" is setting on true, thunderbird supress HTML characters "-->" on reply message and other mail apps doesn't show complete message.
If Thunderbird option "mail.strip_sig_on_reply" is setting on false, thunderbird doesn't suppress nothing on reply message and mail is sent correctly.
I send you two emails on eml format, it's same message, first with true option and second with false option. You can see lines 173-176 for example on both files and check difference
But, yes is thunderbird who change HTML code, not word or Outlook
Bad news. It works until 68.12 version, from 78.0 and succesive doesn´t work. Always supress "-->" on reply emails
Comment 6•5 years ago
|
||
I can confirm the bug. I attach the e-mail sample (msb2011...). In the attached sample in line 299 you can see: <style><!--
Comment tag is open. In line 388 comment tag is closed: --></style>
If you forward this message, in the forwarded mail you can see that a closed comment tag is deleted: see line number 386: It is only </style> without -->. I attach the forwarded e-mail (Fwd_ msb2011…).
You can reproduce this bug. Forward an e-mail msb2011… from TB (78.5.0 32bit) and you’ll see it yourself.
In the TB or in the Outlook App you can see the forwarded mail as well. But in the Outlook Web Application (OWA) you can not see the forwarded mail, because OWA sees the open comment tag and waits for a closed comment tag. But the closed comment tag is deleted by TB. This is the TB bug.
Comment 7•5 years ago
|
||
original mail with closed comment tag
Comment 8•5 years ago
|
||
forwarded mail without closed comment tag. TB remove closed comment tag
Comment 9•5 years ago
|
||
This sounds like a bug stripping off email signatures, where the boundary should match the regexp /^-- $/ (see https://tools.ietf.org/html/rfc3676#section-4.3), or a MIME boundary separator parsing bug, where the boundary matches the regexp /^--(\S+)$/ (see https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) where the matched string should equal the boundary value from the Content-Type header.
Email signature boundary should be "-- " (with a single whitespace following the two "--") so if implemented correctly, a string matching /^-->$/ should NOT match because of the missing space, and the extraneous ">". If TB isn't matching the signature boundary exactly, this could be a problem.
And, with MIME boundary matching, the boundary string should be (but does not have to be) long enough to prevent false-positives. In other words, it would be an unfortunate thing for a MUA to generate a multipart MIME with "Content-Type: multipart/mixed; boundary=>" so that /^-->$/ would be the boundary separator.
I haven't dug into the TB code to see what's going on, but this is stuff I'd rule out, first.
Comment 10•5 years ago
|
||
Sounds like bug 1675507.
Description
•