Mail_mime 的已知问题会导致某些电子邮件提供商出现空行吗？答案

【问题标题】：Known problems with Mail_mime that cause empty lines at some e-mail providers?Mail_mime 的已知问题会导致某些电子邮件提供商出现空行吗？
【发布时间】：2014-04-24 08:53:25
【问题描述】：

我正在使用 Mail_mime 1.8.8 (+ Mail 1.2.0) 发送 PDF 和短信。几乎每次测试都没有问题。包括 GMail 和 Apple iCloud。

但似乎有些收件人无法阅读附件。 United Internet（1&1 和 GMX）的用户在正文中的所有行之间出现空行。

由于它是多部分/混合电子邮件，正文中有标题，附件已损坏。

Mail_mime 生成的电子邮件是否存在可能导致该问题的已知问题？不管电子邮件提供商是否使用忽略 Jon Postel 原则的软件来容忍其接收的数据？

【问题讨论】：

可能是crlf 和/或cr 的混合，或者只是错误的行终止符导致问题？可能您需要明确设置它？
@AxelAmthor 我检查了 Mail_mime 的来源，它使用 CRLF 作为行尾。可能在某些时候它不使用 CRLF 并且每个解析器都可以处理它，但来自 United Internet 的解析器除外。但我不知道如何检查这个。我用 mutt 阅读了一封测试电子邮件，并将其传送到 xxd：所有行结尾都是 LF。我猜想转换为接收主机的本机 EOL。
有一个 PHP 常量 CRLF，根据当前操作系统填充，PHP 正在运行。它当然可以明确设置，所以你需要检查一下。您在下面的自我回答指向同一个方向。

标签： php mail-mime

【解决方案1】：

PEAR 包 Mail 和 Mail_mime 不能在不调整 Mail_mime 参数的情况下一起工作：http://pear.php.net/manual/en/package.mail.mail-mime.mail-mime.php

您需要将 EOL 设置为单个换行符。

【讨论】：

对于这个项目，我使用了 1.5.3 版的 Mail_mime，来自 Ubuntu 10.04 LTS 的软件包。手动安装最新的软件包是最后的手段。有趣的事实：Mail_mime 的 tar 存档中的示例脚本具有相同的错误。几乎所有电子邮件提供商都使用对 EOL 具有容忍度的软件。只有 United Internet（1&1、GMX 等）存在问题。 Mime_mail 的代码以这种方式使用了 10 多年，没有人报告任何问题。

【解决方案2】：

检查您的语法（Multipart Content-Type，MIME）以及标题和正文的结构：

内容类型：多部分：https://www.rfc-editor.org/rfc/rfc2045#page-8
换行符的表示：https://www.rfc-editor.org/rfc/rfc2046#section-4.1.1
'MIME 版本：1.0'

如 RFC822 RFC2045 RFC2046 中所述

MIME 标头字段 .................................... 8
MIME-Version 标头字段 ................................... 8

https://www.w3.org/Protocols/rfc822/3_Lexical.html https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html https://www.rfc-editor.org/rfc/rfc822#section-3.2

【讨论】：