减少电子邮件投递的放弃时间是个好主意吗？

Question

我们为一些客户运行了一个电子邮件服务器，最近我们遇到了一个难题。

我们有一个用户将电子邮件发送到错误的电子邮件地址。不幸的是，错误指定的域存在。它没有 MX 记录，并且域的 A 记录转到了不使用 SMTP 的服务器。因此，电子邮件服务器尝试传送但未成功，因为没有电子邮件服务器正在运行。

出于这个原因，我们的电子邮件服务器完全按照 SMTP RFC，在五天内尝试重新投递，最终在投递失败 5 天后放弃并向发件人发送通知。

RFC5321（简单邮件传输协议）的第 4.5.4.1 节说：

重试一直持续到消息被发送或发送方放弃；放弃时间一般至少需要4-5天。

因此，邮件服务器在其默认配置中，在这种情况下按照 RFC 运行，这意味着在这种情况下指定错误电子邮件地址的用户将不会收到通知，除非在五天后。

在这一点上，我的老板问是否可以将放弃时间缩短到更短的时间，比如 1 天。他的理由是，最好提前通知用户未交付，并且用户可以尝试在以后重新交付，或通过替代渠道交付。这听起来是一件合理的事情，但总的来说，我对执行任何与 RFC 中的内容相矛盾的配置更改持谨慎态度。

是否有任何不明显的原因为什么将放弃时间减少到 24 小时是一个坏主意，而不仅仅是说“RFC 另有说明”？

此外，在这种情况下，较大的电子邮件提供商（Google、Microsoft、AOL 和 Yahoos）会做什么？

Answer 1

为什么不应该在一天后放弃发送电子邮件？一个很好的理由是周末。

电子邮件现在不是，也从来不是，特别可靠。在互联网的早期，即 1980 年代，电子邮件完全有可能需要几天的时间才能到达目的地，因为有些网络链接不是 24x7，通过昂贵的长途拨号电话（当时每分钟拨打两个城镇，更不用说从悉尼打电话到洛杉矶的费用），甚至通过业余无线电。因此，传送电子邮件可能需要一段时间，而且协议必须处理不可靠的兼职连接。他们在这方面做得很好，但即便如此，邮件也可能会延迟或丢失。

当然，今天，电子邮件具有可靠性的错觉，这仅仅是因为底层传输更可靠，而且许多不知情的人（如我们的大多数用户）都期望它是可靠的，但这种期望与现实不符。如果电子邮件传输协议没有重大改变（这可能永远不会发生），电子邮件就像人类构建的任何东西一样，永远不会达到 100% 的完美。

有时，我们系统管理员会利用这一点。

例如，在一个每个人都只在周一至周五上班的办公室里，如有必要，我可以让电子邮件中断整个周末。当然，几乎从来没有必要出去那么久，但在极少数情况下，我不得不将电子邮件关闭超过 24 小时。

在这种情况下，如果您在 24 小时后放弃，周五下午发送的电子邮件可能无法到达收件人。发件人要到周一早上才会发现，但如果您一直尝试，收件人会在周一早上收到。

此外，适当地设置用户期望非常重要。需要清楚地了解互联网电子邮件不是也永远不会是 100% 可靠的事实，即使我们喜欢认为它是。

RFC 说你应该继续尝试，正是因为事情出错了，如果可能的话，它打算最终发送邮件，但在某些时候你不得不放弃。这可能是确定这种减少的三个天。我一直认为，对于 24x7 全天候 Internet 上的大多数邮件，五天的等待时间太长了。

至于您给定的邮件服务器：

Postfix 可以在电子邮件延迟时通知发件人，但此功能默认关闭。此警告应该足以让您的用户知道可能出现问题（例如错误输入电子邮件地址），并且会比您老板建议的 24 小时更早到达。

要启用它，请在 中设置delay_warning_time为所需的值main.cf。

delay_warning_time=4h

与3.0版开始，后缀可以同时通知那些相同的发件人时延迟的消息被最终交付。默认情况下这也是关闭的，因为它可能会导致大量通知。但是如果你想要这个，请confirm_delay_cleared在main.cf.

confirm_delay_cleared=yes

Answer 2

我建议不要更改放弃时间。假设收件人的办公室（带有现场电子邮件）在周末被\龙卷风|地震|火灾\摧毁。如果公司为其 DR 计划使用异地磁带备份，您最好相信从龙卷风到再次接受电子邮件将需要超过 24 小时。在这种情况下，5 天太长了，但这不是问题的根源。

无论是 5 天、48 小时还是 24 小时，所有这些时间段的延迟都太长，无法收到未发送电子邮件的警报，而且所有这些时间段都太短，无法容纳服务器故障的所有可能原因。如果不使用 sendmail，也许可以按照 MadHatter 的建议查看 sendmail。至少，如果队列中的任何内容超过几个小时，您应该为自己（和/或其他人）配置一些警报。