我有一个应用程序通过客户端的本地Exchange服务器发送smtp电子邮件。 所有的电子邮件发送好（它到达收件人），但一些电子邮件被多次发送，因为我的应用程序永远不会收到221 respose代码说，它已经工作正常，所以重新尝试。 我们可以避免重试，但这往往是真正的问题。
这种情况通常发生在某些特定的电子邮件地址上，一旦发送，该电子邮件就会重复发生。
我已经捕获了一个工作的TCPstream，一个没有。 明显的名字改变，以保护有罪。
Did work: 220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:51:16 +0100 EHLO example-PC 250-SBS4S1.example.local Hello [192.168.111.15] 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-AUTH 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250 XSHADOW RSET 250 2.0.0 Resetting MAIL FROM:<[email protected]> 250 2.1.0 Sender OK RCPT TO:<[email protected]> 250 2.1.5 Recipient OK DATA 354 Start mail input; end with <CRLF>.<CRLF> --DATA Here, identical other than MIME/Content IDs in both emails-- . 250 2.6.0 <[email protected]> [InternalId=26602] Queued mail for delivery QUIT 221 2.0.0 Service closing transmission channel 。
Did NOT work: 220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:43:39 +0100 EHLO example-PC 250-SBS4S1.example.local Hello [192.168.111.15] 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-AUTH 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250 XSHADOW RSET 250 2.0.0 Resetting MAIL FROM:<[email protected]> 250 2.1.0 Sender OK RCPT TO:<[email protected]> 250 2.1.5 Recipient OK DATA 354 Start mail input; end with <CRLF>.<CRLF> --DATA Here, identical other than MIME/Content IDs in both emails-- . QUIT 250 2.6.0 <[email protected]> [InternalId=26573] Queued mail for delivery --This then times out but never gets the 221--
除了缺失的221以外，我所能看到的唯一区别是250和QUIT是在“失败”的消息中反过来的。 这是我们必须解决的一个已知的Exchange怪癖吗？我们可以在应用程序中解决或应对某些问题，或者我们可以要求在邮件服务器上进行更改？ 我们不想为正常，普遍的情况破坏任何东西。
更新：我认为我们将无法获得Exchange日志（pipe理员甚至不知道他们在哪里），但我有！ 所以相关的路线是：
由于“DelayedAck”，已过期，超时而导致“0.00：00：32.619”的Tarpit
看起来可能是由于：
https://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
必须先尝试先testing它。
看起来，有时你的应用程序在接收到消息的“最后一个点”（250为OK）的回复之前发送QUIT命令。
似乎MTA（MS Exchange）忽略收到的命令发送答复之前。
build议的修正：
1）增加等待回复的超时时间，在收到之前不要发送QUIT（即使发布了PIPELINING分机）。
2）如果您收到250 “最终点”的回复，请不要重新发送。 在这种情况下，MTA（MS Exchange）接pipe传递消息的责任。
问题的原因是Exchange交换机上的“DelayedAck”设置。 中继“另一侧”的接收服务器花了很长时间来响应（超过30秒），所以我们正在进行的连接超时，SMTP对话从未完成。 （我在问题中添加了url）。
Exchangepipe理员closures了内部传输上的DelayedAck，问题消失了。
我们可以/应该已经改变了我们的应用程序来解决这个问题，但是我们有一个第三部分的组件，使得这个技巧变得棘手，所以我们无法validation这是否可行。