Weird MimeMessage.HtmlBody content when replying to a mail with MultipartAlternative body

[DierkDroth]

@jstedfast I have a hard time describing the problem which I experienced today when trying to compose a reply to a mail, using your MailVisitor logic.

Let me try to explain:

• I got a mail (from an MacOS machine) which is a reply to an email which I sent
• (MimeMessage.Body as MultipartAlternative) .Count == 2
• (MimeMessage.Body as MultipartAlternative)[0] is the plain text version
• ((MimeMessage.Body as MultipartAlternative)[1] as MultiPart).Count == 3
• ((MimeMessage.Body as MultipartAlternative)[1] as MultiPart)[0] is TextPart = reply to my orginal mail
• ((MimeMessage.Body as MultipartAlternative)[1] as MultiPart)[2] is MimePart, not sure if that is relevant for this very problem
• ((MimeMessage.Body as MultipartAlternative)[1] as MultiPart)[2] is TextPart = my original mail
• MimeMessage.HtmlBody shows the reply to my orginal mail, which is the first TextPart -> likely expected, no?!?

Now, after processing by MailVisitor the resulting MimeMessage.HtmlBody points to the second TextPart -> this is wrong

I'm not sure where to start looking. Would you have any idea?

[jstedfast]

Are you using the ReplyVisitor code? I'm just trying to understand what you are doing.

Do you have an example message I can look at that causes this and what the "reply" message looks like at the end? You can censor all of the confidential info, all I really need to be able to see is the structure of the raw MIME.

[jstedfast]

A multipart/alternative is a container part whose direct children are meant to be interpreted as identical content when ignoring their MIME-Types. In other words, a multipart/alternative is how a mail client can send a text/plain and a text/html formatted version of the message body suitable for the receiving client to render whichever variant it supports.

Also important within a multipart/alternative is the order of the children: the children are listed in order of least faithful to most faithful in their representation of the sending client's editor in terms of WYSIWYG (what you see is what you get).

That means that if a multipart/alternative contains, in this order, text/html and then text/plain, it means that the text/plain part is actually more faithful in displaying the content exactly as it was seen in the sending client's editor.

Normally, however, the sending client will add these parts in the order of text/plain and then text/html because most modern email clients use an HTML editor for composing email replies and the HTML version of the message body is therefore the more faithful representation of what the user composing the message saw when composing it.

In your specific case, the message you are generating a reply for had the following structure:

• multipart/alternative
  • text/plain
  • multipart/mixed
    • text/html
    • application/pdf
    • text/html

In this particular case, the text/plain variation of the message body (listed as a direct child of the multipart/alternative) is the least-faithful representation of the message body. I think you are with me so far.

Where I think you are getting confused is the order of HTML parts in the multipart/mixed and thinking that only the first text/html part is the message body. That is not the case.

The alternative to the text/plain part is the full multipart/mixed, NOT the first text/html part.

The way the multipart/mixed is meant to be interpreted is for the receiving client to splice together the first text/html part, the application/pdf and the last text/html part into one "view".

When your code is constructing the reply, the result looks like this:

• multipart/alternative
  • text/plain
  • text/html
  • text/html

The reason that MimeKit's MimeMessage.HtmlBody is returning the content of the last text/html part is because the way you've constructed the reply, it is saying that the 2 text/html parts are alternatives of each other and the last text/html version of the message body is the most faithful representation.

[DierkDroth]

@jstedfast wow, thanks for your in-depth explanation. I have to chew on that...

However, here is what I don't understand right away when reading:

The way the multipart/mixed is meant to be interpreted is for the receiving client to splice together the first text/html part, the application/pdf and the last text/html part into one "view".

Are we on the same page this is not what MimeMessage.HtmlBody does? In the very case it 'only' yields the first text/html and does not splice together anything.

[jstedfast]

Yes, we are on the same page there. This is not something that MimeKit can easily do. I mean, how would MimeKit sandwich a PDF (which can contain images and other stuff) between 2 slices of HTML?

You can do it visually by rendering 2 HTML panes with an embedded PDF reader between them in the UI, but I have no idea how to return a string representation of that :-)

[DierkDroth]

Thanks again @jstedfast. Let me work with that...

[DierkDroth]

@jstedfast I wanted to maintain the structure of the original email as much as possible. Turns out I only had to change 2 sections in the code I copied from your MailVisitor.cs template. Please see screenshots below.

Do you think those changes might cause any unforeseen issue or should they be good?