I stumbled upon this problem today, again. Typically I let Thuderbird display the message body as plain text. And there was a new email, written with Mac Mail, where Thunderbird did not display any attachments

I looked a bit closer and if I understand the standard correctly Apple Mail with multipart/mixed and multiplart/alternative.
I assume that Thunderbird simply does not parse the alternative/HTML part at all and therefore does not see the other attachments at all. Maybe Thunderbird should always at least parse the MIME structure of the whole email even when in "plain text only" mode.

This is how Apple Mail does the "Content-Type" structure

(in the header)
Content-Type: multipart/alternative

Content-Type: text/plain

[plain text email]

Content-Type: multipart/mixed
Content-Type: text/html

[html formated email]

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document

[attached word file]

This is the way it should be (at least the way I understand the standard)

(in the header)
Content-Type: multipart/mixed

Content-Type: multipart/alternative
Content-Type: text/plain

[plain text email]

Content-Type: text/html

[html formated email

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document

[attached word file]

Maybe Thunderbird should always at least parse the MIME structure of the whole
email even when in "plain text only" mode.

Maybe the multi-billion dollar company Apple should honour international standards and do it the way you pointed out as "the way it should be".

I do not like the discussion about who is responsible and where the bug is and where not. The attitude "open a bug a Apple" is quite similar to Apples unaccapteable behaviour. This attitude do not help the FOSS movement the and "open and free internet" goal of mozilla.

I am coding in the area of RSS/Atom/Newsfeeds where standards are very flexibel interpreted by generators and servers. It sucks! But my primary goal is the user which results in two things:

1. Be awar of non-standard behaviour of servers/generators and try to find a way/workaround that do not break the workflow of the users and the intended use of my software.
2. Try to be a kind teacher: While offering a workaround I also inform the user that there is something wrong and who should be contacted. Such workaround should not do their job hidden in the background - the users should be aware of it.

Remember the TSL and certifacte warnings generated by some browser. We should act like this too.

Now I attache my informations to that bug report:

I am using TB 68.6.0 (32-bit) on Window 10 64-bit. Plain text view is default.
I recive mails from a "X-Mailer: Apple Mail (2.3445.9.1)".

Plain text has no attachmend but html view has.

I can not add the whole mail here but I give you some snippeds of the code.

From the header
"Content-Type: multipart/alternative;
boundary="Apple-Mail=_453E9E2C-31B0-487D-A150-2F5FF10F42AC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 (3445.9.1))"

The end(?) of the body and the beginning of the attachment:

</div></body></html>=

--Apple-Mail=_0ED75D0F-8539-4E8C-8F2B-5A068F4A80D1
Content-Disposition: attachment;
filename="main document Paper DS 03032020.docx"
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
x-unix-mode=0644;
name="main document Paper DS 03032020.docx"
Content-Transfer-Encoding: base64

UEsDBBQABgAIAAAAIQDBDZRG5wEAAIwMAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

I can confirm that this problem still exists in TB 78.

Luckily the "Allow HTML Temp" plugin works again in TB 78 so I can switch to HTML view to check for "hidden" attachments more quickly. It's still not a good user experience.

I'm hitting this in Thunderbird 68.12.0. I tried enabling 'mailnews.display.show_all_body_parts_menu' however this did not change the result. "Plain Text View" still lacked the attachments.

All it did was add an additional menu item which rendered the HTML, exposing me to the very thing I wanted to avoid (possibly tainted HTML) in the process. If it just offered them as attachments to download and nothing more, it'd be fine, but listing them and rendering them inline is highly dangerous.

So, we have two ways forward:

1. patch Apple Mail to fix its broken MIME envelope handling
2. patch Thunderbird to handle attachments in oddball MIME envelope structures

If someone can tell me how to do (1) remotely from my Linux workstation for every Apple user that chooses to send me an email with an attachment, I'll look into fixing it. Maybe sending a .mp4 recording of me saying "Hey Siri, can you fix your email client to send MIME emails properly?" might work? Maybe the user is just holding the phone wrong when they click SEND? Who knows?

Option (2) seems a lot more doable. It beggars belief why this should be sitting in the queue for so many years.

TB (68.10.0 on Linux mint 20.1)set to read plain text received an apple mail message with an attachment that does not show.
When I tell TB to forward this to yahoo mail and CLAWS mail the attachments are listed in the attachments pane and once sent can be read in both Yahoo mail and CLAWS mail.

As the code to list attachments is functional it should be only a small job to fix this long standing problem.

I can report that the problem still exists in TB 87b3.

The issue is made worse by the fact that the "Allow HTML Temp" plugin that provided a kind of workaround does not work in TB 87b3 and it is not clear if it is going to be ported forward (see https://bugzilla.mozilla.org/show_bug.cgi?id=1598857 and https://bugzilla.mozilla.org/show_bug.cgi?id=1602201)

The workaround of switching the view mode in the menu or using "Allow HTML Temp" is still really bad user experience because you have to know that the mail has an attachment that you can't see to get the idea to switch the view mode and check if it really has one :-(

Can this be addressed? Apple products are quite popular and I don't see Apple fixing this bug despite being reported. While it's not perfect to allow incorrect structure, we don't live in a perfect world and it's annoying to miss attachments in a team where everyone uses Mail.app.

Thunderbird should be functional first…

(In reply to c.buhtz from comment #22)

[...]
2. Try to be a kind teacher: While offering a workaround I also inform the user that there is something wrong and who should be contacted. Such workaround should not do their job hidden in the background - the users should be aware of it.

Remember the TSL and certifacte warnings generated by some browser. We should act like this too.
[...]

I agree with c.buhtz. At the moment for users it just seems like thunderbird is broken and doesn't get fixed. So I would suggest, that an (optional) "apple compatibility"-mode for attachments is added and a warning about non-standard-emails is displayed. This would allow thunderbird users to choose if they prefer correct email-function (which I definitively do) or if in their circumstances it is more important to see every attachment. By still showing a notification about the standard-corrupting behaviour of apple awareness of the problem would be raised so that the pressure of correcting the issue would increase for apple at the same time.

Yes, we have to expect Apple to engage in annoying nonstandard behavior (remember hard-formatted 3.5" floppy disks? ok, so I'm old). Lack of a headphone jack, which is just really polite to those who wear hearing aids. Even the distinction between "garbage can" and "recycle bin" causes endless problems.

But that doesn't fix the problems for users of Thunderbird. Especially when we're dealing with stuff sent from an iPhone from an overseas location because that's the only way to get past national firewalls. (Which is another rant for another time, and even less likely to change behavior at the source.) I read e-mail in plain text mode precisely to avoid problems with unwanted webbugs, malware, phishing, etc. The less-tech-savvy people to whom I provide technical support avoid a lot of problems by never seeing this crap. (If you can't see the kewl graphic but do see the ".ru" address on the "Click here to validate your account now!" link...)

This is a SERIOUS problem for me, when trying to deal with clients' legal issues (like "I just got this IRS notice in the mail," and there's almost nothing more certain to cause panic). And it's not just iPads; it's ALL IOS devices (and getting worse with more-recent versions of IOS, which I'm seeing as some clients upgrade to newer iPhones and iPads). It's not just that there's no icon in the message listing; it's that both the existence of an attachment and the attachment itself don't show up in plain-text view AT ALL. So unless the body of the message makes clear reference to the attachment, I don't know to switch views to HTML (and then get bombarded with graphical signature blocks, etc.).

So I suggest:

(1) It's ok to blame Apple's noncompliance when that's the actual cause. It's also ok to suggest filing a bug report with Apple, for all the good that will do. FOS is antithetical to Apple's "walled garden" approach, so they won't care... until they end up hiring enough engineers who've benefited from FOS before joining Apple to quietly change things in future versions. (That's how Apple began to grudgingly support multibutton pointing devices. One literally could not plug a two-button mouse into 1980s/1990s Macs and get it to work without lots of fragile hacked software.)

(2) It's NOT ok to then act as if the problem is either solved or too inconvenient to solve in Tbird. Please at least force the message listing to show something in the "attachments" column so that I know to process the message specially. THIS change should be minimal, as it has nothing to do with actual message display and therefore shouldn't upset too much (if any) code.

Preferences :
mailnews.display.show_all_body_parts_menu = true
doesn't help.

(In reply to hg7 from comment #32)

Preferences : mailnews.display.show_all_body_parts_menu = true doesn't help.

Yes, it does, but you need to switch the view to "All Body Parts". You can of course view the original HTML instead. The screen shot uses attachment 8864992 [details].

(In reply to José M. Muñoz from comment #33)

Created attachment 9229183 [details]
all-body-parts-on.png

(In reply to hg7 from comment #32)

Preferences : mailnews.display.show_all_body_parts_menu = true doesn't help.

Yes, it does, but you need to switch the view to "All Body Parts". You can of course view the original HTML instead. The screen shot uses attachment 8864992 [details].

...which fails to hide the dodgy HTML that using plain-text view hides, and drags in graphics, etc. This is not a solution; this is resistance.

(In reply to hg7 from comment #32)
Preferences : mailnews.display.show_all_body_parts_menu = true doesn't help.

Preferences :
mailnews.display.show_all_body_parts_menu = true
doesn't help
This is true whenever PlainText-View ist activated.

But it helps if the switch in menu "view": "All Body Parts" or "HTML" is activated.
German:
im Menu "Ansicht" muss irgendwas mit "HTML" oder "Alle Teile des Inhalts"
ausgewählt werden.

Same function and not function ist with emails from bugzilla, probably not Apple, for example an attachment in an information about change of password or anything else.

It would be nice if plain-text shows an infobutton about any attachments.

Please, devs, adapt to the fact that Apple will not fix it, and finally provide a working Thunderbrid!

Meanwhile, here a dirty hack (which I accidentally discovered in TB 91; but likely also working with older versions) for all the suffering people out there:

• step 1 (in GUI): View -> Message Body As -> Plain Text
• step 2 (in config editor): set mailnews.display.prefer_plaintext == false
• [optional] step 3 (in config editor): confirm that mailnews.display.html_as == 1

This "break" somthing in TB because after restarting TB I don't see any selected option under "Message Body As", but at least I see plaintext emails and attachments from Apple as expected and all other mails seem to be shown in plaintext as before.

I can confirm this problem for Thunderbird 102.15.0 (64-bit) running on Linux (newly installed Linux Mint 21.3).

Thunderbird should learn to be more tolerant when handling incorrect MIME boundaries.