# 电子邮件通知错误地将附件分配为 multipart/alternative

**URL:** <https://meta.discourse.org/t/email-notifications-incorrectly-assign-attachments-into-multipart-alternative/141844>\
**Category:** Bug\
**Created:** [2020 年2 月 17 日 22:06 UTC](https://meta.discourse.org/t/email-notifications-incorrectly-assign-attachments-into-multipart-alternative/141844 "2020-02-17T22:06:47Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

作者： ![djr013](https://avatars.discourse-cdn.com/v4/letter/d/e68b1a/32.png) [@djr013](https://meta.discourse.org/u/djr013)\
发布日期： [2020 年2 月 17 日 22:06 UTC](https://meta.discourse.org/t/email-notifications-incorrectly-assign-attachments-into-multipart-alternative/141844/1 "2020-02-17T22:06:47Z")

</div>

发送带有附件的电子邮件通知时，生成的多部分 MIME 结构存在格式错误。附件被包含为“替代（alternative）”部分，而非“混合（mixed）”部分。因此，某些电子邮件客户端（如 Thunderbird）不会显示这些附件，因为它们被解释为邮件内容的另一种格式（类似于纯文本与 HTML 之间的关系）。

[以下引用来自针对 [Mailer 的几乎完全相同的错误报告](https://github.com/hanami/mailer/issues/78)，该报告同样依赖 Mail 模块。]

> 我期望的电子邮件结构如下：
> 
> ```plaintext
> multipart/mixed
> multipart/alternative
> text/plain
> text/html
> application/pdf（即 PDF 附件的情况）
> 
> ```
> 
> 我实际收到的结构：
> 
> ```plaintext
> multipart/alternative
> text/plain
> text/html
> application/pdf（即 PDF 附件的情况）
> 
> ```
> 
> 实际影响：  
> Thunderbird 会根据用户偏好（纯文本或 HTML）正确渲染邮件正文，但不会将附件显示为附加文件（尽管它确实存在于邮件源代码中，作为一个 base64 编码的数据块）。iOS 邮件客户端则显示空白的邮件正文，仅显示 PDF 附件文件，因为它是最后一个条目，而该邮件客户端似乎只渲染此部分。

针对 Discourse 所依赖的 [Mail 模块](https://github.com/mikel/mail) 存在一些可能相关的错误报告。其中一些报告已关闭，隐含的结论是以特定方式传递各部分即可解决问题。我不确定此处是否属于这种情况，但我上面引用并链接的报告已关联了其中几份报告。

---

_[View the full topic](https://meta.discourse.org/t/email-notifications-incorrectly-assign-attachments-into-multipart-alternative/141844)._