On Sat, 27 Apr 2019 22:32:51 -0400, Ken Hornstein said: > >> Only if I follow the hint "Invoke menu with right button." I will > >> get a menu: > >> > >> Decode part as MIME > >> Save a multipart/alternative... > >> Print a multipart/alternative as text... > >> Show alternative 1: text/plain > >> Show alternative 2: multipart/mixed > >> > >> Selecting alternative 2 will then show all parts, in the example > >> here: > > > >That's actually standards-compliant. If the attachments are part of > >the multipart/mixed, they should not be displayed if the MUA is displaying > >the text/plain. > > Well, I agree it is "standards compliant", in that it's a validly-formatted > MIME message, but is it RIGHT? I am not sure. > > My understanding is that the alternative parts are supposed to be different > versions of the same thing. So text/plain vs text/html, fine, that makes > sense. But is text/plain vs 'text/html plus a few extra files with a > disposition of "attachment"' the RIGHT idea? I would argue that it is not, > that the multipart/alternative should just encapsulate the text/plain and > the text/html.
Well, back when multipart/alternative was being discussed, there was at least one person saying that an alternative between text/plain and text/html was *always* incorrect, because if the two were semantically identical, only text/ plain was needed, and if they were semantically different, the info in one part was *wrong* and should not be sent. :) The working group thinking was (as best I remember it, RFC1341 *was* decades ago :) that the "correct" way to do text plain/htm would be as a multipart/ alternative, where text/plain was one part, and the other would be a multipart/ related package of text/html, plus image/* for embedded images, other parts for fonts/CSS included, etc etc - only parts required by the text/html. Attached PDFs and the like that were relevant to both variants should indeed be outside the multipart/alternative. But apparently we have code in the wild that will stick those PDFs into one side of the alternative rather than outside the alternative. Blech. So it's totally unclear what unpacking/rearranging of pieces of an alternative is OK (especially given that a digital signature could be over something other than the entire message. This is in fact common if a signed message goes through a Mailman based list that wants to append a footer, it will take the signed object and encapsulate it and the text/plain footer as a multipart/mixed Additionally, there's a lot of code inside exmh that assumes that the MIME structure is fairly fixed - if you look in /tmp/$USER while exmh is displaying a multipart, you'll see the unpacked pieces. Trying to change the nesting is almost certainly going to cause lots of code breakage. Bottom line - it shouldn't be too hard to expose the MIME nesting info for the non-displayed part(s) of a multipart/alternative. But trying to second-guess it and redo the nesting looks like a can-o-worms indeed. _______________________________________________ Exmh-users mailing list Exmh-users@redhat.com https://www.redhat.com/mailman/listinfo/exmh-users
