停止发送错误给我

我选择的桌面电子邮件客户端可以渲染 text/plain 和 text/html 格式的电子邮件。我恰好更喜欢 text/plain 版本。你说得对，我应该跟上时代。但当你错误地使用 multipart/alternative 向我发送错误时，你并没有帮我，也没有帮其他人。实际上，你做的正好相反。古代的文献将 multipart/alternative 记录为以多种可互换的形式提供相同的信息。最常见的是，这用于发送电子邮件的 HTML 版本和它的纯文本对应版本。换句话说，multipart/alternative 并不是用来发送你该死的错误。如果我的电子邮件客户端无法处理你的电子邮件，那就应该由客户端来报告这些错误。今天早上，我收到了一封电子邮件，内容为：纯文本版本不可用。在切换到 HTML 版本后，我没有看到如下内容的已呈现等效：<!DOCTYPE html> < html > < head > < title > ... </ title > </ head > < body > < p > 纯文本版本不可用 </ p > </ body > </ html > 而是看到了实际的电子邮件内容。如果这不是如此普遍，我可能会感到惊讶。让我们考虑一下用户展示 text/plain 版本的场景：场景：他们正在使用一款古老的非 MIME 电子邮件客户端，因为他们是来自‘80年代的时间旅行者。结果：他们看到一些胡言乱语，然后是“纯文本版本不可用”，接着是类似 HTML 的胡言乱语。如果他们还不知道发生了什么，那么这条消息将无法帮助他们修复任何问题。假设他们能在胡言乱语中找到它。场景：他们使用一款支持 MIME 的电子邮件客户端，但无法处理 text/html。结果：他们看到这个“错误”，而由于他们的客户端理解 MIME，它推测这个“错误”与它无法理解的部分可能是可互换的并显示出来。也许客户端提供了一种抓取 HTML 的方法，但也不一定。用户甚至可能不知道这种情况是可以恢复的。如果没有 text/plain 部分，他们的客户端可能的表现不亚于你的“错误”消息，甚至可能提供真正的恢复路径。如果效果更差，你需要再次问问自己，你的消息是否真的能帮助他们。场景：他们使用一款支持 MIME 的电子邮件客户端，能够同时处理 text/html 和 text/plain，但他们配置为偏好 text/plain。结果：与场景 2 非常相似，只是如果你简单地不添加一个错误作为文本/plain 部分，他们会立即获得预期的体验。现在他们必须依赖对情况的理解和对自己的电子邮件客户端的知识，去找到切换到他们明确配置不去偏好的格式的选项。你只是让他们的生活变得更困难。如果你的电子邮件系统无法生成有用的 text/plain 版本的电子邮件，那么告知他们并没有帮助。如果场景 1 听起来令你向往，你可以使用 HTML 注释来给你的 HTML 电子邮件受害者提供更多或更少同样令人困惑的体验，而不违反 RFC 或让随机的网络小人物感到生气。“但是，”我听到你大喊，“我把 text/plain 版本放在了第一位，text/html 版本放在了最后。就像古籍所说的那样，我应该标明我的首选表示。”这很好。我明白你喜欢 HTML，但我更喜欢纯文本。当正确使用 multipart/alternative 时，纯文本部分可以比我从 HTML 部分渲染出的任何内容要干净得多。如果我没有在我的电子邮件客户端中注册我的 text/plain 偏好，我将面临场景 3 的镜像情况。幸运的是，所有这一切都有一个简单的解决方案：只需停止发送实际上不是替代的 text/plain 替代品。这不仅会让我们这 10 个高兴，还能帮助避免将你的电子邮件标记为垃圾邮件。它甚至不仅限于错误。以下是我最近收到的一些 multipart/alternative 电子邮件的真实 text/plain 部分（逐字，除了方括号中的内容）：这封电子邮件包含 HTML 内容。请配置你的电子邮件客户端以使用 HTML，或访问 <site.website>[sic] 获取最新演出时间。text/html 在消失之前使用它 [50 个空白行] [... 更多内容 ...] [... 随机 CSS 样式表单行 ...] [100 个空白行] [... 等等 ...] [标题] 嗨，汤姆 /, 感谢你的订单！ [日期] 你的收据附在这封电子邮件中。如果你不想通过电子邮件收到收据，你可以 <a style="text-decoration:none;" href="https://[domain]/optOut/receiptOptOut?businessId=[id]&emailAddress=[my-email]&token=[token]">取消订阅<a/>。脚注我很怀疑任何可能对这种情况感到困惑的人会在 2026 年使用不支持 MIME 的电子邮件客户端，甚至是不支持 text/html 的客户端。