在几个例子中，我有两个电子邮件地址发送给我们，比如说“[email protected]”和“[email protected]”（两个不同的收件人，在两个不同的域）。 在这种情况下，发送方是Exchange 2007，然后通过内容过滤系统（思考MessageLabs-esque）。
在第一个例子中，我尝试发送一封电子邮件，两天之后，我收到拒绝
Diagnostic-Code: smtp;550 4.4.7 QUEUE.Expired; message expired 在第二个例子中，我尝试发送一封电子邮件，在6天后，我收到了一个拒绝的诊断代码如下：
Diagnostic-Code: smtp; 5.4.7 - Delivery expired (message too old) '[Errno 61] Connection refused' (delivery attempts: 0)
我的问题基本上是这样的：不pipe返回的具体消息是什么，大规模的事情，（a）当一个消息被拒绝时 – 即在失败之前尝试多久，（b）发送vs在确定这些延迟/超时/失败的时候接收结束？
我在猜测，如果发送出现问题，发送服务器的重试策略将适用，而如果SMTP连接则应答，但在接收服务器发挥更大作用的情况下不会收到。
谢谢！
许多人希望电子邮件像即时消息一样工作。 但是，使用存储转发机制是一个非常不同的机制。 实质上的延误是可能的，可以提供更可靠的交付，但不是即时通知问题。
在反弹之前，电子邮件等待的速度在正在反弹的服务器上configuration。 这可以让你的服务器，客户端系统上的服务器之一，或者两者之间的服务器。 通常，电子邮件将被重试近一周。 RFC中包含重试机制和重试时间表的build议。 （不记得具体的一个。）通常每个小时左右几个小时，然后在更长的时间间隔更长的延迟。
一些服务器将发送一条或两条消息，通知发送者其消息被延迟。 这是可选的，通常最后的延迟信息将在一两天之内发送。
由于被认为是永久性的原因，消息也可以立即反弹。 我应用一些我不会改变的政策，这会导致电子邮件被退回。 这些通常应用于服务器configuration，表明电子邮件有几乎100％的机会被垃圾邮件。 发送电子邮件到本地不是本地的帐户也被认为是永久性的（仅限收到的邮件）。 尺寸限制通常也被认为是一个永久性的问题。 有永久性的信息会立即反弹，除非它们已经被暂时延迟了。
如果我因为其他原因拒绝交付，则该消息被推迟。 这告诉调用服务器，情况是暂时的，并且可能被修复。 正确configuration的服务器将在几天内重试。 这里有一些可能的垃圾邮件条件。 如果我注意到合法的服务器configuration不正确，我调整我的configuration并允许它传递消息，并尝试通知另一台服务器的pipe理员更正其configuration。 这适用于一些垃圾邮件，因为它不能正常重试。
取决于发送者和接收者的错误。
如果接收者错误是最终的（即错误意味着无法进一步尝试，例如“帐户不存在”，它具有特定的SMTP代码），那么它将失败。
如果服务器只是断开连接/不可达，则在发送方上进行configuration（尝试将消息放置在某个位置多长时间）。
如果是通过中继（最终服务器脱机，备份服务器接受），那么它在备份服务器上configuration…因为你的服务器实际上拿走了电子邮件，并摆脱它。
在你的情况下，接收者不需要你/你的服务器，所以它拒绝连接（服务器存在，TCP连接失败 – 可能是其中一个easons，反垃圾邮件模块，其中防火墙），所以你的服务器不知道（没有最后的否），并重试，只要它被configuration为这样做。
我会认为这是一个可configuration的偏好在任何一方。 一旦你传递了邮件，当你从另一端的处理程序得到一个传递通知时，你将无法控制。 这些都取决于MTA的所有者，你自己包括在内。