> (multipart/signed) >1. (multipart/alternative) >There are alternative views of the following: (Invoke menu with right button.) >------ > (text/plain) >Message text. >------
Marc explained that it's the OPPOSITE problem ... certain mail he sends out has the recipients not seeing the attachments. But I am familiar with the problem you are talking about (the attachments only show up after the the HTML part of the multipart/alternative). Sigh. I have no answer to that one, but I do have some insight. I was idly looking at the REST API that Outlook exports to see if it is possible to have support for that in nmh (answer: yes, but a lot of work). But if you look at details of the API, you see a fundamental problem and the reason email is kind of screwed up. Whatever your feelings about IMAP, the people who developed the IMAP protocol made it possible to represent all valid MIME messages inside of it. But if you look at the Outlook network protocol, what it is exporting is "Messages". "Messages" contain a "Body" and zero or more "Attachments" (the body might consist of a text or a HTML part). So it's not possible to represent all valid MIME messages in Outlook/Office 365. So those users (and there are a lot of them) never generate messages that don't follow the "Body plus zero or more attachments" model, and you can't SEND messages that don't fit that model to Outlook users (or if you do the results are undefined). So everything has been devolving to a "Body plus zero or more attachments" model of email due to a shitty network protocol. I have no solution to this, I just hope the background might be useful. And I just lament the way things have ended up. --Ken _______________________________________________ Exmh-users mailing list Exmh-users@redhat.com https://www.redhat.com/mailman/listinfo/exmh-users
