因此，我有一个简单的 bash 脚本，旨在向用户发送一条注释（例如，虚构的[电子邮件受保护]），其中所述注释包含一小段文本（包含在文件 message.txt 中）和一个附件（一个 PDF 文件，我将其称为 good.pdf 或 bad.pdf，如下所述）。
脚本（如下）中对 mutt 的调用（CentOS 7，官方存储库中提供的 mutt 版本“仅”1.5.21）工作正常（对于 good.pdf）...
/usr/bin/mutt -s "here is the file..." [email protected] -a good.pdf < message.txt
...除了某些 PDF 文件 (bad.pdf) 之外，当我尝试打开附件时（无论是在邮件客户端中，还是在首次将其与电子邮件分离后使用 PDF 阅读器），附件是空白的。
good.pdf 和 bad.pdf 在我拥有的众多 PDF 阅读器中的任何一个中都可以正常呈现（表明它们是“合法”PDF 文件）。如果我使用电子邮件客户端（如 Thunderbird）附加 good.pdf 或 bad.pdf，两个附件都可以正常通过（都不是空白）。
但是，bad.pdf 显示为空白如果我尝试使用 mutt 将其作为附件发送（至少，我可以从 CentOS 7 运行的 mutt 版本）。
如果我查看 mutt 正确发送的 good.pdf 的一些邮件标头，我会发现
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Here is the text piped in from message.txt
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="good.pdf"
Content-Transfer-Encoding: base64
因此，good.pdf 文件的 Base64 编码。
但对于 bad.pdf 文件（即将出现“空白”），我得到以下信息：
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Here is the text piped in from message.txt
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="bad.pdf"
Content-Transfer-Encoding: quoted-printable
因此，出于某种原因，mutt 认为 bad.pdf 的内容类型是 text/plain （而不是 application/octet-stream），我怀疑这就是为什么它随后使用quoted-printable 进行 Content-Transfer-Encoding （而不是 base64） ）。
同样，我所有的 PDF 阅读器都可以很好地打开 good.pdf 和 bad.pdf。而且，我所有的电子邮件客户端（Thunderbird 就是其中之一）都很好地附加了两个 .pdf 文件，并且两个 pdf 文件在收据上都是“可读”（不是空白）的。只有当我使用 mutt 时，bad.pdf 才会以空白形式发送。显然，PDF 文件之间存在一些“不同”（内部），但这不是我可以轻易弄清楚或控制的东西（我从各个用户那里收集 PDF 文件，并且不生成它们）。
那么，有什么建议吗？或者关于问题出在哪里的线索？ mutt 显然正在“阅读” bad.pdf 中的内部内容，这使它认为（错误地） bad.pdf 是不是PDF 文件（确实是）。相比之下，Thunderbird（以及 Outlook、Evolution 和许多其他“邮件客户端”）可以很好地附加它，而不会将其变为“空白”。
是否值得尝试强制使用 Base64 编码？如果是，我需要向 CLI 调用 mutt 提供什么以“实现这一点”？
非常感谢提前...