Zammad: 可选禁用对 HTML 电子邮件的支持

嗨@MichaelHierweck

让我更清楚。 HTML 电子邮件有什么问题（用例）？

注意：只有代理可以编写 html 电子邮件，并且所有外发电子邮件都附加“纯文本”附件（因此，如果您使用 pine/mutt 等，则没有劣势）。

-马丁

我们的业务合作伙伴有点老式和安全意识。 他们希望电子邮件是文本/纯文本和 GnuPG 签名的。 但也许老式是 2016 年的遗产......;)

GnuPG 很好，也适用于 html 电子邮件（其中包含文本 + html 的多部分）。 :)

我们保持这个问题开放，看看是否有人也对纯文本电子邮件感兴趣。

我通常也使用纯文本电子邮件。 在我的电子邮件程序中，我只在特殊情况下才切换到 HTML 邮件。

一般来说，我会说今天像我这样的老式用户必须接受这样一个事实，即 HTML 邮件是标准的。

就 zammad 而言，我认为拥有纯文本电子邮件编辑器仍然会有所帮助：内置编辑器在编辑 HTML 时有很多问题......今天，我一遇到这样的错误，我就打开 zammad用 Thunderbird 发送消息并从那里回答。 这种情况经常发生。

我非常支持这个请求。 不仅因为我原则上从不写 HTML 邮件，还因为我习惯于向客户发送表格概述和缩进格式的信息，例如

 | row 1    | row 2    |
 +----------+----------+
 | field 11 | field 21 |
 |   sub 11 |          |
 | field 12 | field 22 |
 +----------+----------+

在格式化的环境中查看时，它看起来很糟糕，不可读且不专业：

+-----------+-----------+
| 第 1 行 | 第 2 行 |
+-----------+-----------+
| 字段 11 | 领域 21 |
| 子 11 | |
| 第 12 场 | 第 22 场 |
+-----------+-----------+

理想的情况是，如果可以为每个邮件选择具有默认格式的格式，该格式可以由每个代理设置。

我不完全确定应该如何处理收到的邮件，但我可能会建议：

• 传入的邮件是文本/纯文本：以等宽/电传类型字体显示。 回复只能以文本/纯文本形式发送
• 传入的邮件是 text/html _and_ text/plain：应显示并保留 HTML 格式的部分。 对于回复，代理应该能够在纯文本和 html 之间进行选择。 然后将原始邮件的相应部分用于引用部分。 引用 html 邮件的纯文本部分通常会使这部分无法使用（尤其是当它包含表格、列表等时）。 因此，我们应该可以选择保持格式
• 传入邮件仅为文本/html：与普通/html 邮件相同

只是我的 2c

这非常重要，我刚刚创建了我的 github 帐户来对此发表评论。 HTML 邮件使我无法将 Zammad 用于我的业务。 如果我们发送 HTML 邮件，我的公司就会显得很愚蠢。

大多数专业人士认为电子邮件的 HTML 是邪恶的。 它在维基百科中有解释，所以我希望这是常识。

HTML 的使用过于频繁并导致了太多的问题，其中包括：

• 安全问题。 （嵌入式跟踪项、JS、CSS...）
• 对电子邮件的错误期望加上糟糕的沟通方式（例如使用颜色而不是正确的引用）
• 更复杂的自动处理（需要通过 MIME 容器找到自己的方式，然后摆脱标签......）
• 更大的尺寸
• 兼容性问题（不要指望 MUA 处理 HTML！）
• 残障人士的无障碍问题。 想想色盲或全盲用户。
• 非常笨拙的编辑。 Zammad实际上是最好的例子。 那些 HTML 邮件是编辑器中的 PITA。
• 引述。 您如何插入“>”以及在哪里插入？ 如果中间有块引用、p 或 div 标签，甚至是 img，你会怎么做？
• 德国 BSI 建议将 HTML 显示为纯文本。 因此，未来可能会出现合规性问题。

通常，接收者定义她希望如何呈现/格式化电子邮件。 HTML 打破了这条规则，允许发送者定义花哨的（不可读的？）字体、背景图像和其他花哨的东西，而这些将在接收者的客户端中部分或完全消失，具体取决于她的设置。 这意味着没有满足发件人的期望，而收件人不知道邮件是否按发件人的预期显示。 这不能用纯文本发生。

我认为明文处理在开发中应该始终排在第一位并具有更高的优先级。 HTML 被认为是额外的，而不是相反。

我同意并因此支持这个问题

dito，自第一条评论以来一直在等待此选项。

首先，非常感谢您参与 Zammad 开源项目。 我们认识到您对此的需求。 但是，它目前不在您即将推出的功能（简短）列表中。 这意味着除非我们找到赞助商，否则至少在明年我们可能不会进行这项工作。 另一种选择是发送拉取请求。 我们很高兴在这方面为您提供支持，使其达到所需的质量和形式，以按照 Zammad 的方式进行。
由于在定义的需求上没有新的输入，这些已经很清楚了，我请你把你对这个功能的渴望限制在最初的帖子中的表情符号上。 发送评论会产生大量噪音，分散我们对 Zammad 工作的注意力并减慢我们的速度。 否则我必须锁定对话。 随时在我们的社区委员会https://community.zammad.org/上开始生动的讨论，这是正确的地方。
感谢您的理解和支持！

把这个问题带回聚光灯下。 来自 Github 的地址确认电子邮件现在是格式错误的 html，因此导致 ProofPoint 等产品在传输过程中损坏电子邮件。 应该再次审查对纯文本电子邮件的需求，因为脆弱的 html 格式会导致商业电子邮件过滤器出现问题。 我同意期望 GitHub 对每个供应商进行回归测试是不合理的，但缺乏控制电子邮件交付格式的能力有点让 GitHub 有责任进行这种回归测试

https://useplaintext.email/
https://useplaintext.email/#why -plaintext

我愿意投入一点钱来添加此功能，但可能不足以靠我自己筹集资金。 我环顾四周，看到了许多其他的 GitHub 问题，并带有prioritised by payment标签； 我认为这意味着它可以为用户基金的特定功能，他们希望看到什么？

我也很想支持纯文本邮件。 最好的是，如果它像@fthommen指出的那样灵活。

对不起，这又超出了我的雷达。
请联系销售[at] zammad [dot] com。

我们的同事会计算出成本，如果它太多，还要检查它是否有资格为几个人进行支付池。

我的猜测是，这目前被未来成为 Zammad 的编辑所阻止。
Zammad 目前无法判断您是否可以格式化邮件，目前我认为这可能很麻烦。

这是一个非官方的快速 hack，它试图完全禁用在所有电子邮件中发送 html 部分。
警告：尚未在生产中进行测试，可能会破坏其他东西，您的里程可能会有所不同。

这是一个专供专家自己运行 Zammad 并知道如何应用、测试和调试他们的安装的补丁。
但是，如果您只想发送文本/普通邮件（例如出于安全原因），您可以尝试一下。

```补丁
--- app/models/channel/email_build.rb.org 2021-03-18 17:43:54.776830273 +0100
+++ app/models/channel/email_build.rb 2021-03-18 17:49:45.262137627 +0100
@@ -63,4 +63,9 @@
# 生成普通部分
attr[:body] = attr[:body].html2text
+

• # 只发送文本/普通邮件的黑客，请参阅功能请求
• # https://github.com/zammad/zammad/issues/325
• # 删除生成的 html_alternative 部分，使其无法发送：
• html_alternative = 假
  结尾

``` (applied against zammad Version: 3.6.0-1615986441.da478686.buster from the official Debian Buster package, /opt/zammad`)

不久前，我们确实就此功能联系了 Zammad 销售人员，看起来它必须成为一个真正的小项目，这超出了我们的预算。 相反，我们自愿向 https://www.zammad-foundation.org/ 支付了一小笔三位数的款项，以便他们为他们出色的自由软件产品取回一些东西并对其进行维护。 如果你喜欢这个补丁，请考虑支付 Zammad 基金会。 :)