I have been using Mailkit library to receive emails and so far it has been great. However, we found a problem with messages that are sent via Mail app on Mac. For instance, a message that we sent with a pdf attachment and html-formatted body, is being received (throgh IMailFolder.GetMessage) as an object without any attachments and only HtmlBody being null (only TextBody is received)
I am attaching sourcecode of this mail (without some personal information headers) from a web email client (the message is displayed ok there)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CA0BDF81-AE2A-4E1A-9D37-8B30B5220C77"
Subject: Test
Date: Thu, 11 Jun 2015 07:00:29 -0700
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
--Apple-Mail=_CA0BDF81-AE2A-4E1A-9D37-8B30B5220C77
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
Hello goodbye pdf
--Apple-Mail=_CA0BDF81-AE2A-4E1A-9D37-8B30B5220C77
Content-Type: multipart/mixed;
boundary="Apple-Mail=_FA44F8C6-5F68-44EF-9537-8E8651DAAC0C"
--Apple-Mail=_FA44F8C6-5F68-44EF-9537-8E8651DAAC0C
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><b class=""><i class="">Hello</i></b></div><div class=""><b class=""><i class="">goodbye pdf</i></b></div></body></html>
--Apple-Mail=_FA44F8C6-5F68-44EF-9537-8E8651DAAC0C
Content-Disposition: inline;
filename*=utf-8''Zamo%CC%81wienie%20ZAM21%2D150528%2D01.pdf
Content-Type: application/pdf;
x-unix-mode=0644;
name="=?utf-8?Q?Zamo=CC=81wienie_ZAM21-150528-01=2Epdf?="
Content-Transfer-Encoding: base64
(here is a base64-encoded pdf that is being decoded correctly)
--Apple-Mail=_FA44F8C6-5F68-44EF-9537-8E8651DAAC0C
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""></body></html>
--Apple-Mail=_FA44F8C6-5F68-44EF-9537-8E8651DAAC0C--
--Apple-Mail=_CA0BDF81-AE2A-4E1A-9D37-8B30B5220C77--
Has anyone faced this kind of problem with Mailkit? Or maybe it isn't library-dependant, just specific apple mail?
The MimeMessage.TextBody and MimeMessage.HtmlBody properties are convenience properties that use common practices to determine what the appropriate text body parts of the message are. Unfortunately, there is no strict definition of "this 1 part and 1 part only is the text body, and this other 1 part is the html body".
The structure of this message is as follows:
Normally, in a
multipart/alternative, you'll have 1 of the following 2 cases:or
The
multipart/alternativedefines alternative views (I know, I'm stating the obvious here). MimeKit finds thetext/plainpart because it follows the general conventions. But the next alternative is amultipart/mixed. That's not HTML, so MimeKit cannot return it as theHtmlBody. MimeKit's logic for determining theHtmlBodyonly understandsmultipart/relatedinside of amultipart/alternativebecause the spec formultipart/relateddefines which part is the root document (which is generally an HTML document).In the case of your message, what this means is that the
multipart/mixedis your alternate view and the sending agent intended for those 3 parts to be rendered in sequence as the alternate message body. You can't really just pick one of those 2 html parts and use it as the html body because it would be incomplete without the other (and without the pdf).That said, MimeKit does not limit you to the use of the
TextBodyandHtmlBodyproperties to get your message body. MimeKit provides a number of ways to iterate over the MIME structure yourself to use your own logic to get what you need.Refer to the following documentation:
FAQ / MessageBody
Working With Messages