I recall an example recently [ digs... ] ah, here:
https://www.postgresql.org/message-id/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com
There is a patch in there, but it looks like the boundary line
for the preceding section might be messed up?
IIUC...(I am by no means experienced here, and also haven't tried to examine other good ones this evening. Just skimming RFC 1341 and trying to make sense of what is shown)
Root uses a boundary of [42], which is structured as multipart/alternative and has two mutually exclusive children:
Text Body (structured as text/plain)
HTML Body + Attachment (structured as a multipart/mixed [64]) - to make the html (structured pointlessly? as multipart/related [86] and an embedded text/html) and a attachment (structured as text/x-patch) independent
So a viewer displaying the text body alternative should not present the attachment. But one presenting the HTML body would present the attachment. Apparently the multipart/alternative section that makes text and html mutually exclusive should ideally be in a multipart/mixed container so that the shared attachment can be considered "mixed" with whichever one of them is chosen.
We basically present the plain text version on our archive viewer so the absence of the attachment is technically correct. Gmail for me defaults to displaying html and so I too get the attachment download option.
Probably the archive should deal with the html branch in a better way than a complete ignore. This does seem to indicate a need for at least somewhat better handling of nested multipart messages - my advice in the prior email to "let the user download and deal with it on their own" is probably insufficient. The UI part of this, aside from agreement on what would be nice to do, seems straight-forward enough; I don't have much feel for the complexity of implementation though. We probably need to at least pull out any explicit text attachments regardless of which branch we are showing. Whether to extend that to any attachment type is probably easiest but worth discussing. That would fall under "bug fix" for me. Converting the html body branch into a download option would an improvement worth considering along the lines of "everything is either displayed on the page or is an attachment". Or, taken further, everything on the page (each part) can be individually downloaded as content only.
Done for tonight...will probably explore a "good" example in light of my understanding tomorrow.
David J.