web-dev-qa-db-ja.com

Exchange経由で送信するSMTPは、一部のメールが完了せずに送信します-なぜですか？

顧客のローカルExchangeサーバーを介してSMTP電子メールを送信するアプリケーションがあります。すべての電子メールは正常に送信されます（受信者に届きます）が、アプリケーションが正常に機能したことを示す221 resposeコードを受信しないため、一部の電子メールは複数回送信されます。再試行を削除することはできますが、多くの場合、これは真の問題のために必要です。

これは、特定の宛先の電子メールアドレスでより一般的に発生し、一度取得すると、その電子メールで繰り返し発生します。

動作するものと動作しないものの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'、Expired; Timeoutによる '0.00：00：32.619'のターピット

次の原因が考えられます。

https://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/

最初にテストしてみてください。

exchangesmtp
1
Dominic Fitzpatrick

アプリケーションがQUITコマンドを送信する場合があるようですbeforeメッセージの「最後のドット」に対する応答を受信します（OKの場合は250）。
MTA（MS Exchange）は、応答を送信する前に受信したコマンドを無視しているようです。

推奨される修正：
1）応答を待機するためのタイムアウトを増やし、受信する前にQUITを送信しないでください（PIPELINING拡張機能がアドバタイズされている場合でも）。
2）しないでください「最後のドット」に対する250応答を受け取った場合は再送信してください。このような場合、MTA（MS Exchange）がメッセージの配信を引き継ぎます。

2
AnFi

問題の理由は、Exchangeトランスポートの「DelayedAck」設定でした。リレーの「反対側」にある受信サーバーが応答するのに時間がかかりすぎたため（30秒以上）、接続がタイムアウトし、SMTP会話が完了しませんでした。 （質問で追加したURL）。

Exchange管理者は、内部トランスポートでDelayedAckをオフにし、問題は解消されました。

これを回避するためにアプリケーションを変更することもできたはずですが、これをトリッキーにした3番目の部分のコンポーネントがあるため、これが機能するかどうかを確認できません。

1
Dominic Fitzpatrick