This is getting off-topic IMO; we should probably take this thread to email-sig.
Glenn Linderman writes:
I recall being surprised when first seeing messages generated by Apple Mail software, that are multipart/related, having a sequence of intermixed text/plain and image/jpeg parts. This is apparently how Apple Mail generates messages that have inline pictures, without resorting to use of HTML mail.
(Are you sure you mean "text/plain" above? I've not seen this form of message. And you mention only "text/html" below.)
This practice (like my suggestion) is based on the conjecture that MUAs that implement multipart/related will treat it as multipart/mixed if the "main" subpart isn't known to implement links to external entities.
Other email clients handle this relatively better or worse, depending on the expectations of their authors!
Sure. After all, this is a world in which some MUAs have a long history of happily executing virus executables.
I did attempt to determine if it was non-standard usage: it is certainly non-common usage, but I found nothing in the email/MIME RFCs that precludes such usage.
Clearly RFCs 2046 and 2387 envision a fallback to multipart/mixed, but are silent on how to do it for MUAs that implement multipart/related. RFC 2387 says:
MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type should give the user the option of suppressing the entire Multipart/Related body part shall be. [...] Handling Multipart/Related differs [from handling of existing composite subtypes] in that processing cannot be reduced to handling the individual entities.
I think that the sane policy is that when processing multipart/related internally, the MUA should treat the whole as multipart/mixed, unless it knows how links are implemented in the "start" part. But the RFC doesn't say that.
Several of them treat all the parts after the initial text/html part as attachments;
They don't implement RFC 2387 (promoted to draft standard in 1998, following two others, the earlier being RFC 1872 from 1995). Too bad for their users. But what I'm worried about is a different issue, which is how to ensure that multipart/alternative messages present all relevant content entities in both presentations. For example, the following hypothetical structure is efficient:
multipart/alternative text/plain multipart/related text/html application/x-opentype-font
because the text/plain can't use the font. But this
multipart/alternative text/plain multipart/related text/html image/png image/png
often cost the text/plain receiver a view of the images, and I don't see any way to distinguish the two cases. (The images might be character glyphs, for example, effectively a "poor man's font".) OTOH, if the message is structured
multipart/related multipart/alternative text/plain text/html image/png image/png
the receiver can infer that the images are related to both text/* parts and DTRT for each.
Steve