+++ This bug was initially created as a clone of Bug #149771 +++

One year or little more after my last glance in my eight-years-old daily growing archive of automatically generated monitoring messages from a portal, I've just noticed that no message body is displayed any longer: empty window.
Yet, message list, headers and even message sources are correctly displayed in their own windows.

I noticed only that they are all multipart/mixed content-types with one text/plain part. A sample message is attached (after saving it as "file").

Maybe that could be somehow related to Bug #149771.

I dragged the attached message file to a folder in "Local Folders" of TB. It opens OK for me. It appears to be just a text email with no attachments. Is there something special I need to do to duplicate the problem?
Probably need more details like how many messages are in the folder that you obtained the sample message from. Do you mean literally tb "Local Folders" or locally stored imap or pop folders, etc...

Hi,
I mean literally Local Folder (where messages get moved from a POP3S mailbox). I'm trying to attach a sample zip with message archive and its msf index.

From Local Folders, a sample archive (along with its .msf index) of messages with one mixed/multipart part (text/plain content)

(In reply to gene smith from comment #1)

I dragged the attached message file to a folder in "Local Folders" of TB. It opens OK for me. It appears to be just a text email with no attachments. Is there something special I need to do to duplicate the problem?
Probably need more details like how many messages are in the folder that you obtained the sample message from. Do you mean literally tb "Local Folders" or locally stored imap or pop folders, etc...

I've just tried the same operation, unsuccessfully, eventafter disabling extensions in "safe mode". Maybe my installation is messed up: TB 68.7.0 (64-bit) on macOS 10.13.6, with enabled extensions Display Mail User Agent T , LookOut (fix version) , Mail Summaries , Manually sort folders , Nostalgy , Remove Duplicate Messages (Alternate) , Toggle Headers , and XNote++ ,

I re-tested on macos with 68.6 and and tb trunk and I see the problem now. Totally blank display if I drag the sample message to a Local Folder or if I drag it to an imap folder. I will try to determine what the problem is. (Before I was testing on tb 60.9 on a ubuntu LTS. Forgot that it was not updated. Sorry about that.)

I haven't looked at the full mailbox files you attached yet, but the sample email seems to have some problems. It claims it is multipart but I only see one part. Also, it says it is quoted-printable and it looks like just all plain text. Maybe this is OK, don't know for sure.

Anyhow, I found a workaround for the sample file. Set mail.inline_attachments.text to true in config editor. This causes the sample email to appear. This pref was added as part of the 68 release to avoid showing huge plain text attachments inline. Apparently tb is seeing your file as just a text attachment.

Also, FWIW, removing the line

Content-Disposition: quoted-printable

from the file causes the message to be seen without changing the pref.
Possibly other tb coding changes in the MIME code in version 68 are affecting this.

Edit: I imported the mbox and msf file to local folder and see the problem on all the emails I looked at: displays blank. Setting mail.inline_attachements.text to true fixes the problem.
Note also that for every email in the reporter's mailbox (total 7679) I see a paperclip icon indicating each has an attachment. However, the message displays, with default setting, empty with no attachment link visible along the bottom. I've noticed the paperclip icon before and there would be no linked attachment, not just on the reporter's mailbox.

Magnus, I think the pref mail.inline_attachements.text was added by aceman so maybe he should handle this if he's still working on TB. See Bug 1509709. Otherwise, my recommendation would be to default it back to true so that messages like the reporter's that look like text attachments still display. If someone is annoyed by large inline text attachments then just let them set the pref false to fix their problem.
Then again, there may be other MIME changes that contribute to this that I'm not aware of.

quoted-printable is Content-Transfer-Encoding not Content-Disposition. I suppose that's the real bug here - that if Content-Disposition is something other than inline or attachment, we don't show it?

Something like this fixes it. Treat non-existing, invalid or "inline" Content-Disposition as inline. This fixes the reporters message display with the new pref mail.inline_attachments.text remaining at the default setting of false.

Well, now I'm not sure. Re: https://tools.ietf.org/html/rfc2183#section-2.8
This says Unrecognized disposition types should be treated as `attachment'.
What I'm proposing essentially treats unrecognized disposition (e.g., quoted-printable) as inline. So tb is currently doing the "right thing" according to the rfc. It treats it as an attachments and, since it is text, doesn't show show it when pref mail.inline_attachments.text is at the default setting of false.
Edit: Then again the rfc uses the term "should" so not really a hard requirement.

Do you mean "show that attachment" at the bottom so you can click it to open or download it? I think maybe the problem with the message is that there is also no filename parameter on the Content-Disposition so tb doesn't show the attachment link at the bottom. I've seen other emails where the footer on the email is a separate text part with no filename and tb thinks it's an attachment (shows paperclip icon) and the aceman pref doesn't affect it.

Yes. Don't we show "part1" or something like that for such cases?

(In reply to Magnus Melin [:mkmelin] from comment #13)

Yes. Don't we show "part1" or something like that for such cases?

Don't see any link at the bottom to "part1" or anything at all. The only way I ever see a link is if I set the email source so it contains:

Content-Disposition quoted-printable; filename=t.txt

Then I see the empty email body and the link at the bottom to save-as the "attachment" as file t.txt. I can then save or view the email in a text editor.

I also reduced the "fetch by parts" threshold down so that maybe parts were fetched. I now do see tb asking for the BODYSTRUCTURE but still the whole thing is fetched because there is only one part and there is no link to "part1" at the bottom. Email remains empty. This is also with attachments not inline and with no offline storage.

(In reply to Magnus Melin [:mkmelin] from comment #8)

quoted-printable is Content-Transfer-Encoding not Content-Disposition. I suppose that's the real bug here

Full agreement. So that would be Bug 1283731

that if Content-Disposition is something other than inline or attachment, we don't show it?

Bug 1283731 comment #3 has a workaround.

(In reply to gene smith from comment #10)

Well, now I'm not sure. Re: https://tools.ietf.org/html/rfc2183#section-2.8
This says Unrecognized disposition types should be treated as `attachment'.
What I'm proposing essentially treats unrecognized disposition (e.g., quoted-printable) as inline.

See also Bug 1288335

So tb is currently doing the "right thing" according to the rfc. It treats it as an attachments and, since it is text, doesn't show show it when pref mail.inline_attachments.text is at the default setting of false.
Edit: Then again the rfc uses the term "should" so not really a hard requirement.

The point is: the message from attachment 9139247 [details] is broken. TB has no way of knowing if the content is even useful. It could also be a picture. Maybe also an attempt to hide SPAM.
Only we should not ignore the content.
My vote: View it as attachment.

The point is: the message from attachment 9139247 [details] is broken. TB has no way of knowing if the content is even useful. It could also be a picture. Maybe also an attempt to hide SPAM.
Only we should not ignore the content.
My vote: View it as attachment.

We currently treat invalid "content-disposition" headers as an attachment. But since there is no filename in the header either, we don't show a link to save the attachment. So we need to provide a default filename for when these invalid "content-disposition" are present so that a link appears.

There are places in the code where the "content-disposition" header is decoded and "filename" is looked for and if not found just returns null for filename so no link appears Maybe if instead of returning null, return a default name (maybe default.txt) so a link appears and the non-visible "attachment" can be saved and examined.

Re: comment 14.