我们为一些客户运行电子邮件服务器，最近我们遇到了一些难题。
我们有一位用户向错误的电子邮件地址发送了一封电子邮件。不幸的是，错误指定的域确实存在。它没有 MX 记录，并且该域的 A 记录发送到不支持 SMTP 的服务器。因此，电子邮件服务器尝试投递，但由于没有电子邮件服务器正在运行，因此没有成功。
因此，我们的电子邮件服务器完全按照 SMTP RFC 进行操作，在五天内尝试重新投递，在 5 天的投递失败后最终放弃并向发件人发送通知。
RFC5321（简单邮件传输协议）第 4.5.4.1 节说：
重试持续到消息传送完成或者发送者放弃为止；放弃时间一般需要至少4-5天。
因此，在这种情况下，邮件服务器的默认配置是按照 RFC 运行的，这意味着在这种情况下指定错误电子邮件地址的用户将在五天后才会收到通知。
此时，我的老板问我是否可以将放弃时间缩短到更短的时间，比如 1 天。他的理由是，最好尽早通知用户未送达，这样用户可以稍后尝试重新送达，或者通过其他渠道送达。这听起来很合理，但总的来说，我对执行任何与 RFC 中的内容相矛盾的配置更改持谨慎态度。
除了说“RFC 另有规定”之外，还有什么不明显的理由可以说明将放弃时间缩短至 24 小时不是一个坏主意吗？
那么，大型电子邮件提供商（Google、Microsoft、AOL 和 Yahoo）在这种情况下会做什么呢？
答案1
为什么你不应该在一天后就放弃发送电子邮件？一个很好的理由是周末。
电子邮件现在不再是，而且从来不是，特别是可靠的在互联网发展的早期，也就是 20 世纪 80 年代，电子邮件完全可能需要几天的时间才能到达目的地，因为有些网络链接不是 24x7 的，需要通过昂贵的长途拨号通话（当时每分钟费用拨打两个城镇以外的电话（更不用说从悉尼拨打洛杉矶的电话费用了），甚至通过业余无线电也很难做到。因此，发送电子邮件可能需要一段时间，而且协议必须应对不可靠和不定时的连接。它们在这方面做得很好，但即便如此，邮件也可能会延迟或丢失。
当然，今天，电子邮件给人一种可靠的错觉，只是因为底层传输更可靠，而且许多不知情的人（比如我们的大多数用户）都有期待相信它是可靠的，但这种期望与现实不符。如果不对电子邮件传递协议进行重大改变（这可能永远不会发生），电子邮件就像人类制造的任何事物一样，永远都不会 100% 完美。
有时，我们系统管理员会利用这一点。
例如，在办公室里，每个人只在周一到周五上班，如果有必要，我可以让电子邮件中断整个周末。当然，实际上没有必要这么长时间，但在极少数情况下，我不得不让电子邮件中断超过 24 小时。
在这种情况下，如果你在 24 小时后放弃，周五下午发送的电子邮件可能无法到达收件人。发件人直到周一早上才会发现，但如果你继续尝试，收件人将在周一早上收到邮件。
此外，正确设定用户期望也非常重要。尽管我们愿意认为互联网电子邮件是 100% 可靠的，但我们必须清楚地认识到这一事实：互联网电子邮件并非 100% 可靠，也永远不会 100% 可靠。
RFC 建议你继续尝试，确切地说因为事情出错了，如果可能的话，邮件最终还是会被送达，但到了某个时候你不得不放弃。也许可以将其简化为三天。我一直认为，在全天候互联网环境下，大多数信息需要等待五天才能送达，这实在是太长了。
至于您给定的邮件服务器：
Postfix 可以在电子邮件延迟时通知发件人，但默认情况下此功能处于关闭状态。此警告足以让您的用户知道可能出了问题（例如电子邮件地址输入错误），并且邮件将比老板建议的 24 小时更早到达。
要启用它，请设置delay_warning_time到 中的所需值main.cf。
delay_warning_time=4h
从 3.0 版开始，Postfix 可以还当延迟的消息最终送达时通知相同的发件人。默认情况下，此功能也是关闭的，因为它可能会导致大量通知。但如果您想要此功能，请启用confirm_delay_cleared在main.cf。
confirm_delay_cleared=yes
答案2
我打算采取与这里的大多数答案相反的观点。
我工作的 ISP 为大约 3000 名客户提供服务，并使用 Qmail 作为这些客户邮箱的 MTA。
我们的系统已运行了近 2 年，队列生命周期为 2 天，没有收到任何投诉，也没有出现邮件投递问题。它降低了队列大小，这使得发现被盗账户（很少见，但确实存在）并清理它们变得更容易。
队列生存期超过一天只是 Cargo Cult 系统管理，是互联网远非“始终在线”时的遗留问题。优秀的系统管理员遵循“最佳实践”，但更优秀的系统管理员了解为什么它是最佳实践，并在情况与之前的“最佳实践”开发情况不同时将“最佳实践”更改为更好的实践。
答案3
我建议不要更改放弃时间。假设收件人的办公室（有现场电子邮件）在周末被\龙卷风|地震|火灾\摧毁。如果公司使用异地磁带备份进行灾难恢复计划，您最好相信从龙卷风到再次接受电子邮件需要超过 24 小时的时间。在这种情况下，5 天太长了，但这不是问题的根源。
无论是 5 天、48 小时还是 24 小时，所有这些时间段的延迟都太长，无法提醒未发送电子邮件，而所有这些时间段都太短，无法容纳服务器故障的所有可能原因。如果不使用 sendmail，也许可以按照 MadHatter 的建议研究一下 sendmail。至少，如果队列中有邮件停留时间超过几个小时，您应该为自己（和/或其他人）配置一些警报。