我想知道为什么SMTP的devise方式允许邮件path上的中间MTA。 根据RFC 5321，
简单邮件传输协议（SMTP）的目标是可靠有效地传输邮件。
虽然我不完全明白在这里效率和可靠性有什么好处。 例如，当用户代理向邮件系统提交消息时，就我所知，不能保证消息最终进入目标邮箱。 根据上面提到的RFC，MTA可能会用发送错误（DSN）的电子邮件回复发件人。 但是，服务器也可能无法提供此报告错误。 那么RFC讲到哪个可靠性呢？ 海事组织，更可靠的方法将连接到最终服务器，并直接提交消息。 如果连接失败，或者服务器拒绝了该消息，则发送者确定知道传送失败。
我在SMTP RFC，A.Tanenbaum的“计算机networking”以及网上的许多资源中一直在挖掘这种邮件传输scheme的基本原理。 没有人给我清楚的电子邮件路由目的。 不过，我可以想一下下面的解释：
1）发送消息所需的连接较less。 想象一下，我们在一个公司的networking中，有自己的MTA作为中继。 许多人可以发送消息，例如，gmail.com SMTP服务器。 如果每个人都直接连接到gmail.com，那么服务器上的连接数就会增加。 相反，我们公司的中继服务器可以打开一个到gmail.com的TCP连接，并通过一个连接传输所有的消息。 因此，目标服务器的负载降低。
2）在中间MTA上可能会configuration一些stream量/反垃圾邮件控制，从而减less目标服务器的负载。
3）在多个目的地的情况下，可以使用多个中间MTA来消除重复消息。 例如，消息的单个实例被传递给top.com，然后被分割为两个服务器mid1.top.com和mid2.top.com等等。 否则，我们将不得不打开不同的TCP连接到每个目标，并将消息复制到每个目标。
以上所有都是我的猜测。 问题是这是否属实，以及在SMTPdevise中是否有任何其他电子邮件路由的原因。
一个常见的用例是，如果目标目标处于暂时脱机状态，则发件人可能会尝试将MXlogging号码提供给中间主机（通常是目标目标的服务提供商）。 中间主机会定期尝试发送，当目标主机回到联机状态时，会发送消息。
在这种情况下的可靠性仅仅意味着“不要试图通知发件人而丢失或丢弃该消息”。 当然，在你控制的应用程序或消息队列中，正常情况下要马上知道错误（快速失败）。 而其他人之前观察到，在中间主机上的SMTP消息排队可能会产生不希望的结果，因为您经常在几天后才知道该消息未被传送。 但是，这是我们的系统，取决于接收系统和他们select使用的中介机构来判断消息应排队多长时间，而不是发送方。
你在＃2上是正确的，像MessageLabs这样的服务正是这样做的。 如果垃圾邮件/恶意软件在到达目标目的地之前可以被拦截，那么对于目的地而言，这是较less的工作。 在这种情况下，中间主机的MXlogging号会低于实际目标。