Why would received message not show an attachment when view of message body is plain text, but does show when view of body is HTML?
I have encountered the situation where Thunderbird (v52) did not show an attachment which turned out to be present. I default to 'View -> Message Body As -> Plain Text' and normally have no problem.
In this case the Inbox list does not indicate an attachment, nor does the message itself. But if I change the message body view to HTML from Plain Text then both message and Inbox show the attachment exists.
Should not Thunderbird show that an attachment is present no matter what the setting for viewing the message body?
Alle antwoorden (5)
That depends on how the message attachment is encoded in the message, and if the message truly has a plain text part or Thunderbird is trying to extract plain text from HTML source.
Do you have the source of a message I can have a look at?
The attachment is a 3.1MB PDF document. The e-mail is multi-part with text/plain and text/html sections as well as the base64 encoded document. Certainly can forward to you if desired.
BWNZ said
The attachment is a 3.1MB PDF document. The e-mail is multi-part with text/plain and text/html sections as well as the base64 encoded document. Certainly can forward to you if desired.
Please do, but save it as a file (ctrl+S) and attach or forward as an attachment. Do not simply forward I do not need the added complexity to the message body doing so will create.
email unicorn dot consulting at gmail dot com
After further looking, I see that the e-mails which do not show the attachment until viewing the body as HTML, are all Content-type: multipart/alternative (and all through Apple systems). There appears to be no problem with Content-type: multipart/mixed.
To borrow some words from http://www.freesoft.org/CIE/RFC/1521/18.htm
The multipart/alternative type is syntactically identical to multipart/mixed, but the semantics are different. In particular, each of the parts is an "alternative" version of the same information.
Based on that I guess Apple are producing non RFC compliant mail. The attachment is NOT an alternative view of the main mail body. (at least I hope it is not) So each of the parts is not an alternative.
Microsoft appear to be saying something similar here
The best description of the issue I found here https://stackoverflow.com/questions/3902455/mail-multipart-alternative-vs-multipart-mixed