我想知道为什么 SMTP 的设计允许在邮件路径上使用中间 MTA。根据 RFC 5321，
简单邮件传输协议 (SMTP) 的目标是可靠、高效地传输邮件。
虽然我并不完全理解这里在效率和可靠性方面有什么好处。例如，当用户代理将消息提交到邮件系统时，据我所知，无法保证该消息最终会进入目标邮箱。根据上面提到的 RFC，MTA 可能会通过电子邮件消息回复发件人，报告传递错误（DSN）。但是，服务器也可能无法传递此报告错误。那么 RFC 所说的可靠性是什么？在我看来，更可靠的方法是连接到终端服务器并直接提交消息。如果连接失败，或者服务器拒绝该消息，则发件人肯定知道传递失败了。
我一直在 SMTP RFC、A. Tanenbaum 的“计算机网络”以及网络上的许多资源中寻找这种邮件传输方案的原理。它们都没有让我清楚地了解电子邮件路由的目的。不过，我能想到以下解释：
1) 发送消息所需的连接数更少。假设我们身处公司网络，其自己的 MTA 充当中继。许多人可以向 gmail.com SMTP 服务器发送消息。如果每个人都直接连接到 gmail.com，服务器上的连接数就会增加。相反，我们公司的中继服务器可以打开到 gmail.com 的单个 TCP 连接，并通过单个连接传输所有消息。因此，目标服务器的负载会降低。
2) 可以在中间 MTA 上配置一些流量/反垃圾邮件控制，从而也减轻目标服务器的负载。
3) 如果有多个目的地，可以使用多个中间 MTA 来删除重复消息。例如，将消息的单个实例传递到 top.com，然后将其拆分到两个服务器 mid1.top.com 和 mid2.top.com，依此类推。否则，我们必须打开到每个目的地的不同 TCP 连接，并将消息复制到每个目的地。
以上都是我的猜测。问题是这是否属实，以及 SMTP 设计中是否存在电子邮件路由的其他原因。
答案1
一种常见的使用情况是，如果目标目的地暂时离线，发送者可能会尝试将邮件投递到具有更高 MX 记录编号的中间主机（通常是目标目的地的服务提供商）。中间主机会定期尝试投递，当目标目的地主机重新上线时，邮件就会被投递。
可靠在这里的意思只是“不会丢失或丢弃消息，尝试通知发送者”。当然，使用应用程序或消息队列你控制，想要立即了解错误（快速失败）是正常的。其他人之前也观察到，SMTP 消息在中间主机的排队可能会产生不良结果，因为您经常在几天后才知道消息未送达。但这是我们的系统，由接收系统和他们选择使用的中介来判断消息应该排队多长时间，而不是发件人。
您对 #2 的说法是正确的，MessageLabs 等服务正是这样做的。如果垃圾邮件/恶意软件在到达目标目的地之前就能被拦截，那么目的地的工作量就会减少。在这种情况下，中间主机的 MX 记录编号会低于实际目标。