首先，我发现出站邮件队列生存期标准并阅读https://www.rfc-editor.org/rfc/rfc5321#section-4.5.4
我很难理解为什么我们要将消息排队这么久。当最终用户的消息在队列中消失 4 天、5 天或 7 天时，这难道不会让他们感到困惑吗？尤其是当他们期望消息在 3 分钟内（甚至可能是“立即”）到达时？
我曾尝试过设想一个“恐怖故事”场景，即队列生命周期较短可能会导致问题，最终用户会将问题归咎于 SMTP 服务器管理员。但我并没有成功。以下是我所能想到的最好的场景：
- 有人错误配置了其邮件服务器的 DNS，TTL 为 86400。
- 我们服务器上的一个帐户被盗用并被用来发送垃圾邮件。我们被列入 DNSBL 黑名单。（这会被视为暂时故障吗？还是会被视为永久故障？）
我觉得，如果远程服务器真的宕机了，我们的某个收到退回邮件的用户会很乐意把责任推到远程服务器管理员身上，而不是我们身上。而且，似乎最终用户甚至可能更愿意收到退回邮件，而不是让他们的邮件“消失”几天。
我听说过灰名单，但我的理解是它只持续很短的时间，可能最多延迟 15 分钟。
队列生命周期约为 12 小时会有什么坏处？甚至 6 小时？队列生命周期超过 4 天有什么好处？或者只是Cargo Cult 系统管理？
答案1
首先，遵守 RFC 绝不是系统管理的过度依赖。相反，它只是一种良好的做法。
话虽如此，请考虑以下几点：
- 这种做法已有几十年历史。是的，如今大多数邮件服务器的恢复速度比 20 年前快得多，但这并不能保证。
- 并非每个人都可以或想要组建一支合适的“随叫随到”团队。小公司或私人运营商存在，需要考虑工作时间法律，并且并非每个人都可以或想要出于各种原因使用第三方提供商为他们做到这一点。互联网（和邮件）旨在与小型独立系统配合使用。
- 并非所有邮件都是人与人之间的交流。各种自动系统都会发送邮件，但大多数都无法合理处理邮件退回，而且它们也不应该这样做。
有人可能会认为减少初始“消息延迟”警告的时间是一个好主意，但 4-5 天的退回期限是经过时间考验的良好做法，不应改变。