☰

通过 Exchange 发送 Smtp 时某些邮件未完成但仍可发送 - 为什么？

tag-icon • tag-icon exchange smtp
通过 Exchange 发送 Smtp 时某些邮件未完成但仍可发送 - 为什么？

我有一个应用程序，它通过客户的本地 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，问题就消失了。

我们可以/应该改变我们的应用程序来解决这个问题，但我们有一个第三方组件使这个问题变得棘手，所以我们无法验证这是否会起作用。

相关内容