附件可以在 MIME 中的嵌套多部分中吗?
Posted
技术标签:
【中文标题】附件可以在 MIME 中的嵌套多部分中吗?【英文标题】:Can attachments be in a nested multipart in MIME? 【发布时间】:2016-02-14 19:31:48 【问题描述】:我知道多部分电子邮件的每个部分本身都可以是多部分。附件是仅作为***部件添加的,还是也可以在嵌套的多部件中添加?
例如我的意思,这里attachment1.doc
是嵌套的,而attachment2.doc
将是***部分。
我问是因为我遇到了来自https://***.com/a/27556667/492336的这段代码:
# Iterate the different parts of the multipart message.
for part in msg.walk():
# Skip any nested multipart.
if part.get_content_maintype() == 'multipart':
continue
它在 Python 中,它们会遍历邮件的不同部分以搜索附件,但会跳过本身是多部分的任何部分。
他们这样做是否正确?我尝试阅读RFC3501,但找不到任何明确的说明文件附件是否可以嵌套。
【问题讨论】:
【参考方案1】:限制没有规定,您很难为所有multipart
类型争论一个单一的策略——它们有完全不同的目的。
例如,像这样的消息
multipart/mixed
+-- multipart/alternative
| +-- text/plain
| +-- multipart/related
| +-- text/html
| +-- image/png
| +-- image/png
+-- application/octet-stream; name="attachment.pdf"
...对于大多数想要提供消息的 HTML 视图的客户端来说,理智的行为是在 multipart/alternative
中选择 multipart/related
及其所有附件,并使用它来显示消息,同时显示PDF 作为单独的附件。如果您只处理***multipart/mixed
,您只会看到附件,这似乎不是一个理智的方法。
另一种可能发生完全任意嵌套的情况是message/rfc822
,其中附加的消息是它自己的完整 MIME 消息,它可能依次包含另一个 message/rfc822
,等等。
任何带有(显式或隐含)Content-Disposition: attachment
的内容都是“附件”;您有时确实会在内部看到“附件”,例如multipart/alternative
这意味着附件只有在您显示消息的替代视图时才有意义——我很难想出一个例子来证明这是真的,并且实际上可能推测它应该被视为一个错误,并在呈现另一个替代方案时显示附件,以防万一。
【讨论】:
它不依赖于用于撰写邮件的电子邮件客户端应用程序吗?在那种情况下,Thunderbird、Outlook 和 GMail 的行为应该涵盖 99% 的情况……也许有一个分解标准,谁知道呢。到目前为止,我发现的唯一嵌套文件是旨在显示在电子邮件本身中的图像。哦,谢谢你的回答! Outlook 可能很常见,但适应它的行为并不是我会轻松做的事情。可悲的是,Thunderbird 和 Gmail 在某些地方也表现出完全无视标准。如果您确实想涵盖常见情况,可以将 Apple 的 Mail.app 添加到您的列表中。【参考方案2】:嵌套多部分是合法的,并且在一些用例中很常见。最重要的是,如果您使用 S/MIME 对包含文本和图片的多部分消息进行签名,您通常会有一个***的 multipart/signed 包含一个 multipart/mixed 和一些其他部分,而 multipart/mixed 又包含文本/纯文本和图像/jpeg。
【讨论】:
谢谢。你知道它在 RFC 中的描述吗?我假设它在 tools.ietf.org/html/rfc2045#section-2.3 某处。 2045 表示多部分包含零个或多个部分。而已。没有任何相关限制,因此允许将 multiparts 包装在 multiparts 中。 (在这种情况下,S/MIME 所做的只是提供一个相关的例子。)以上是关于附件可以在 MIME 中的嵌套多部分中吗?的主要内容,如果未能解决你的问题,请参考以下文章
将 MIME 中的附加数据嵌入到电子邮件的 HTML 部分。未链接到附件