我一直在使用Mailkit库来接收电子邮件,到目前为止它一直很棒。但是,我们发现通过Mac上的Mail应用程序发送的邮件存在问题。例如,我们使用pdf附件和html格式的主体发送的消息(throgh IMailFolder.GetMessage)作为没有任何附件的对象被接收,只有HtmlBody为空(仅接收TextBody)
我从网络电子邮件客户端附上此邮件的源代码(没有一些个人信息标题)(消息显示在那里)
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--
有没有人遇到过Mailkit的这类问题?或者它可能不依赖于库,只是特定的苹果邮件?
答案 0 :(得分:3)
MimeMessage.TextBody和MimeMessage.HtmlBody属性是便利属性,它们使用常见做法来确定消息的相应文本正文部分。不幸的是,没有严格的定义&#34;这1部分和1部分只是文本正文,而另外1部分是html正文&#34;。
此消息的结构如下:
multipart/alternative
text/plain
multipart/mixed
text/html
application/pdf
text/html
通常,在multipart/alternative
中,您会遇到以下两种情况中的一种:
multipart/alternative
text/plain
text/html
或
multipart/alternative
text/plain
multipart/related
text/html
application/pdf
multipart/alternative
定义了替代视图(我知道,我在此处陈述了明显的观点)。 MimeKit找到text/plain
部分,因为它遵循一般约定。但下一个选择是multipart/mixed
。这不是HTML,因此MimeKit无法将其作为HtmlBody
返回。 MimeKit确定HtmlBody
的逻辑只能理解multipart/related
内的multipart/alternative
,因为multipart/related
的规范定义了哪个部分是根文档(通常是HTML文档)。
如果是您的消息,这意味着multipart/mixed
您的备用视图,并且发送代理旨在将这3个部分按顺序呈现为备用消息身体。你不能真正选择这两个html部分中的一个并将其用作html主体,因为没有另一个(并且没有pdf)它将是不完整的。
也就是说,MimeKit并不限制您使用TextBody
和HtmlBody
属性来获取邮件正文。 MimeKit提供了许多方法来自己迭代MIME结构,使用你自己的逻辑来获得你需要的东西。
请参阅以下文档: