我有一个应用程序，它通过客户的本地 Exchange 服务器发送 smtp 电子邮件。所有电子邮件都发送成功（到达收件人），但有些电子邮件被发送多次，因为我的应用程序从未收到 221 响应代码来表示它已成功运行，因此会重试。我们可以取消重试，但通常这是真正的问题所需要的。
它在某些目标电子邮件地址上更常见，并且一旦发生就会在该电子邮件上反复发生。
我捕获了其中一个能正常工作的 TCP 流和一个不能正常工作的 TCP 流。显然，名字被改了，以保护罪魁祸首。
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 日志（管理员甚至不知道它们在哪里），但我找到了！因此相关行是：
由于“DelayedAck”已过期；超时，Tarpit 为“0.00:00:32.619”
看起来可能是由于以下原因：
https://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
必须先尝试进行测试。
答案1
似乎有时你的应用程序会发送QUIT命令前接收邮件“最后一个点”的回复（250 表示 OK）。
似乎 MTA（MS Exchange）在发送回复之前会忽略收到的命令。
建议的修复方法：
1）增加等待回复的超时时间，在收到回复之前不要发送 QUIT（即使宣传了 PIPELINING 扩展）。2
）不要如果收到250“最后一个点”的回复，请重新发送。在这种情况下，MTA（MS Exchange）将负责传递邮件。
答案2
问题的原因在于 Exchange 传输中的“DelayedAck”设置。中继“另一侧”的接收服务器响应时间过长（超过 30 秒），因此我们建立的连接超时，SMTP 对话从未完成。（请参阅我在问题中添加的网址）。
Exchange 管理员关闭了内部传输上的 DelayedAck，问题就消失了。
我们可以/应该改变我们的应用程序来解决这个问题，但我们有一个第三方组件使这个问题变得棘手，所以我们无法验证这是否会起作用。