The problem is that:
1. It's not an attachment. That is:
Content-Disposition: inline; filename="0001-doc_wip-diff.txt"
explicitly says it's not an attachment.
So the reason it's not listed as an attachment (per the subject of the
email) is because it *isn't* an attachment.
2. We only show the first plaintext part of messages
This is the actual problem. Our archives don't know how to merge
multiple plaintext parts when they are set to be viewed inline and not
as attachments.
It would be nice if our archive viewer conformed on the point that anything showing inline show up, in order, in the "body" section of the viewer. We'd probably add some structural separators to distinguish the parts.
If that is not possible then every part except the first needs to be made accessible as an attachment regardless of the Content-Disposition suggestion.
There is an argument for making every individual part of the message individually downloadable, even inline ones, the first part included. I think this would be nice, instead of the only way to save the message body locally being to copy-paste, or to download the raw message which contains more data than one probably wishes to download. This would be my preference. We'd name the inline parts which lack filenames something like "inline_n.ext" and decide the extension from the Content-Type. This does bring up the question - what are we doing if an attachment doesn't also have a filename?
If that UI choice goes too far, and we solve the multiple inline problem, then we should at least provide a download option for any part that has a filename provided. Inline parts with filenames would be shown on the webpage body and would also have a download option. Frankly, for many patches (small-ish ones at least) this would be an ideal combination, but I doubt most people have fine enough control provided by their mail clients to make these decisions intentionally and on a per-message basis.
I haven't tried to reconcile this with the cf bot's needs.
I also haven't worked through any dynamics involving child message parts that are themselves multi-part messages. That seems like a "let the user download it and figure it out themselves" thing instead of trying to make our viewer interactive to the extent necessary to actually handle such a message. Having some stats on whether we even encounter this situation would help.
David J.