Mailkit - 接收Apple邮件发送的邮件时没有附件或html正文
[英]Mailkit - no attachments or html body when receiving message sent from apple mail
问题描述
I have been using Mailkit library to receive emails and so far it has been great. 
我一直在使用Mailkit库来接收电子邮件，到目前为止它一直很棒。 However, we found a problem with messages that are sent via Mail app on Mac. 但是，我们发现通过Mac上的Mail应用程序发送的邮件存在问题。 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) 例如，我们使用pdf附件和html格式的主体发送的消息（throgh IMailFolder.GetMessage）作为没有任何附件的对象被接收，并且只有HtmlBody为空（仅接收TextBody）
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? 有没有人遇到过Mailkit的这类问题？ Or maybe it isn't library-dependant, just specific apple mail? 或者它可能不依赖于库，只是特定的苹果邮件？
1 个解决方案
解决方案1
3 已采纳 2015-06-15 11:50:58
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. MimeMessage.TextBody和MimeMessage.HtmlBody属性是便利属性，它们使用常见做法来确定消息的相应文本正文部分。 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". 不幸的是，没有严格的定义“这1部分和1部分只是文本正文，而另外1部分是html正文”。
The structure of this message is as follows: 该消息的结构如下：
multipart/alternative
text/plain
multipart/mixed
text/html
application/pdf
text/html
Normally, in a multipart/alternative , you'll have 1 of the following 2 cases: 通常，在multipart/alternative ，您将拥有以下两种情况中的一种：
multipart/alternative
text/plain
text/html
or 要么
multipart/alternative
text/plain
multipart/related
text/html
application/pdf
The multipart/alternative defines alternative views (I know, I'm stating the obvious here). multipart/alternative定义了替代视图（我知道，我在这里陈述了明显的观点）。 MimeKit finds the text/plain part because it follows the general conventions. MimeKit找到text/plain部分，因为它遵循一般约定。 But the next alternative is a multipart/mixed . 但下一个选择是multipart/mixed 。 That's not HTML, so MimeKit cannot return it as the HtmlBody . 这不是HTML，所以MimeKit不能将它作为HtmlBody返回。 MimeKit's logic for determining the HtmlBody only understands multipart/related inside of a multipart/alternative because the spec for multipart/related defines which part is the root document (which is generally an HTML document). MimeKit的用于确定所述逻辑HtmlBody只能理解multipart/related一个的内部multipart/alternative ，因为该规范multipart/related定义哪些部分是根文档（它通常是一个HTML文档）。
In the case of your message, what this means is that the multipart/mixed is your alternate view and the sending agent intended for those 3 parts to be rendered in sequence as the alternate message body. 对于您的消息，这意味着multipart/mixed 是您的备用视图，并且发送代理旨在将这3个部分按顺序呈现为备用消息正文。 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). 你不能真正选择其中一个2 html部分并将其用作html主体，因为没有其他部分（并且没有pdf）它将是不完整的。
That said, MimeKit does not limit you to the use of the TextBody and HtmlBody properties to get your message body. 也就是说，MimeKit并不限制您使用TextBody和HtmlBody属性来获取您的邮件正文。 MimeKit provides a number of ways to iterate over the MIME structure yourself to use your own logic to get what you need. MimeKit提供了许多方法来自己迭代MIME结构，以使用您自己的逻辑来获得您需要的东西。
Refer to the following documentation: 请参阅以下文档：
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.