1264477 - Message with multipart/related RFC 2387 part using start parameter won't display in Thunderbird - just a white screen

Status: RESOLVED DUPLICATE of bug 471402

(MailNews Core :: MIME, defect)

Description

[Matthew Morley]

Attachment: ascii-email.eml

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

Received an email and it was just white, no body shown (subject was OK though).
Went to Hamburger > View > Message Source
Saw the message content was intact with both plain text and html versions. Both were encoded with us-ascii characterset: Content-Type: text/plain; charset=us-ascii and Content-Type: text/html; charset=us-ascii



Actual results:

No email displayed BUT other email clients (Type Mail on Android, gMail) were able to display the email correctly.


Expected results:

The email body should have shown.

I also tried: Hamburger > View > Character Encoding but none of those made a difference and there was no 'ASCII' option in there.

The emails are sent out by PHPBB forum software.

I've attached a sample .eml (with personal details edited)

Comment 1

[Corey 'linuxmodder' Sheldon]

The attached sample worked fine in my instance  of TB 38  with us-ascii (I am US User).

Any other logs or error messages seen if so please add..

Comment 2

[Jorg K (CEST = GMT+2)]

Confirmed:
I imported the attached e-mail (attachment 8741155 [details]) and it shows completely blank in TB 38 and TB 48 (Daily). I've fiddled around with the MIME headers, but so far I haven't been able to see any message content regardless of the "View > Message Body As" setting. I can't even get the plain text part to display.

Needs further investigation.

Corey: You can see the message? On which platform? I'm on Windows 7.

Comment 3

[Matthew Morley]

I'm a UK user and it's blank in both the Mac version and Windows 10 version (both TB 38).

Corey, out of interest: when you go to Hamburger > View > Character Encoding   do you have any options in that list that say ASCII? I don't.

I don't know enough about the regional/localised differences with TB but I'm wondering if ASCII support is missing from the GB version?Or are the localisations simply just text translations for the menus etc?

Comment 4

[Matthew Morley]

(In reply to Corey 'linuxmodder' Sheldon from comment #1)
> Any other logs or error messages seen if so please add..

No error messages. Just the blank email body shown.

Nothing shown in the Error Console when the email is opened/viewed.

Comment 5

[Jorg K (CEST = GMT+2)]

Attachment: Message with original plain text and HTML parts transplanted into a TB created message

I took a "normal" TB generated multipart/alternative message (plain text + HTML) and transplanted the plain text and HTML part from the message that is mysteriously not displayed, also using charset=us-ascii.

Result: it displays, see enclosed.

So it's got to do something with the message headers, not with the content.

In the original message I can see a lot of strange structure:

Content-Type: multipart/alternative; boundary="outer-boundary"
This is a MIME-encoded message. If you are seeing this, your mail
reader is old.
--outer-boundary
Content-Type: text/plain; charset=us-ascii

--outer-boundary
MIME-Version: 1.0
Content-Type: multipart/related;
  type="text/html"; start="<body@here>"; boundary="inner-boundary"

--inner-boundary
Content-Type: text/html; charset=us-ascii
Content-Disposition: inline
Content-ID: <body@here>

--inner-boundary--

--outer-boundary--

A few observations:
1) The boundaries are declared to be "outer-boundary" and "inner-boundary",
   but the actual boundaries start with --
2) The Content-Transfer-Encoding: 7bit is missing.
3) The second alternative part is multipart/related, but there is no related part.
4) The Mime line usually reads: This is a multi-part message in MIME format.
5) I've never seen a start=
6) The MIME version is usually stated at the front.

As I said in comment #2: I've fiddled with the MIME headers, but so far I wasn't able to make the mysterious message visible.

One thing is clear: The BeardedDragon forum generates message with a weird structure.

Comment 6

[Jorg K (CEST = GMT+2)]

OK, found it, it's the start="<body@here>"; If you take this out, the message is displayed.

According to RFC 2387 https://tools.ietf.org/html/rfc2387 that points to the first part of a multipart/related.

As already mentioned, the multipart/related is defective, since there is no related part.

Magnus, what should we do with this? Do we have processing for the start parameter in the box?

Comment 7

[Magnus Melin [:mkmelin]]

Seems so
http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimemrel.cpp#425
http://mxr.mozilla.org/comm-central/ident?i=HEADER_PARM_START

Comment 8

[Jorg K (CEST = GMT+2)]

I'm making this major. It's pretty poor that we don't display a message at all only because it contains a rarely used header. What is the user supposed to do? Read the message source instead?

Comment 9

[Matthew Morley]

As an absolute minimum I would expect the plain text to be shown. The fact that the html version displays correctly in other email clients shows that it's certainly manageable. I'm pretty sure that Firefox will display badly formatted HTML. 

I'm in discussion with the owner of the forum and he says it's a standard PHPBB email that he's not amended. Yes, it may be an issue mainly with the email being sent but at the same time other clients manage to ignore the   start="<body@here>";  successfully.

I wonder if it could be a placeholder from a template? I'll pass on the info from here and see if they can look into it too.

Comment 10

[Matthew Morley]

I'll leave it in the hands of the experts.

Comment 11

[Jorg K (CEST = GMT+2)]

(In reply to Matthew Morley from comment #10)
> I'll leave it in the hands of the experts.
Are you referring to the TB team as experts? Well, we are overworked and under-paid, in fact, not paid at all. TB 45 has just been released, so, assuming we can find a willing volunteer to fix it, unless we slip it into a point release, it won't be out before TB 52 around Christmas.

Comment 12

[Matthew Morley]

(In reply to Jorg K (GMT+2) from comment #11)
> (In reply to Matthew Morley from comment #10)
> > I'll leave it in the hands of the experts.
> Are you referring to the TB team as experts? Well, we are overworked and
> under-paid, in fact, not paid at all. TB 45 has just been released, so,
> assuming we can find a willing volunteer to fix it, unless we slip it into a
> point release, it won't be out before TB 52 around Christmas.

I'm Basically saying you know much more than I do.

I wouldn't know where to begin. I can do PHP and MySQL, going to learn Android coding soon. Happy to report bugs and also fully aware that things take time to be looked ät. It's not a major security issue and it's free software. If it's done by Christmas then great, of its longer then no big deal.

Comment 13

[Matthew Morley]

OK, done a bit more digging with this and it seems like it is the < and > that cause the issue with the start tag as opposed to having a start tag at all.

Changing <body@here> to body@here for the start tag works.

The forum admin has now removed the triangular brackets and the email displays correctly.

So it looks like for the start tag, TB just needs to filter/ignore the < and >

Comment 14

[Jorg K (CEST = GMT+2)]

Thanks for the update. We're glad you can see your e-mail again ;-)

Comment 15

[Jorg K (CEST = GMT+2)]

Just noticed that we have such a bug already.