web-dev-qa-db-ja.com

Exchangeメッセージレート制限について理解する-4.4.2このクライアントのメッセージ送信レートが構成された制限を超えました

Exchange 2010のポート587を介して電子メールをリレーするアプリケーションにこの問題があります。エラープロンプトは4.4.2でしたこのクライアントのメッセージ送信レートが構成された制限を超えました。

これは私の受信コネクタのMessageRateLimitが原因であると理解しています。制限が5でユーザーごとの制限（MessageRateSource）であることを確認したところ、制限を50または100に増やすことで問題が解決されると考えられます。明日も同じエラーが発生しましたか？）

MSサイト に基づいて、これは「単一のソースから送信できる1分あたりのメッセージの最大数」を制限するスロットル設定です。だから私はPowerShellスクリプトを使用してテストしました（それが問題になるかどうかわからないので、以下の部分的なコードを含めます）：

$SMTPClient = New-Object System.Net.Mail.SmtpClient( $emailSmtpServer , $emailSmtpServerPort )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($emailSmtpUser , $emailSmtpPass );
#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
$SMTPClient.Send( $emailMessage )

このスクリプトでは、最初に別のユーザーIDでメールを送信します。その結果、同じ受信者に1分以内に5回以上メールを送信できます。では、なぜこのケースに制限が適用されないのですか？

その後、自分のアプリケーションIDでスクリプトを試しましたが、同じエラー（4.4.2）が表示されました。次に追跡ログエクスプローラーを確認したところ、そのアプリケーションIDで送信された他の電子メールがないことがわかりました。それでは、Exchangeストアのユーザー数をリセットする必要がある場所に保存しますかまた、電子メールの送信を追跡するにはどうすればよいですか？追跡ログエクスプローラーには表示されないようです。以前の懸念として、50に変更しても同じエラーが発生する可能性があります。追跡できないと、さらにトラブルシューティングを行うことができません。

質問が少し長いので申し訳ありません。

誰かが私にいくつかの手がかりを提供できるかどうか感謝します。

exchangeexchange-2010
4
nlks

私はこの質問を裏返します。クライアントがこの問題を抱えて来たとき、私が最初に尋ねるのは、メッセージがExchangeを介して中継されるのはなぜですか？ Exchangeは大量の電子メールを非常に貧弱にし、より良いオプションがあります。アプリケーションがメール自体を送信しない、またはExchangeではなく独自のサーバー経由で送信しないのはなぜですか？

外部の受信者に大量のメールを送信するアプリケーションがあり、それがスロットル制限を超えている場合は、Exchangeの近くにそれを配置したくないでしょう。ブラックリストに登録されるのは時間の問題です。自分のIPアドレス、自分のPTRとDNSを持ち、電子メール自体を送信します。

あなたが探している答えは私が認めるものではありませんが、しばしば問題を別の方法で考えると、問題に対処するためのより良い方法が得られます。

3
Sembee

エクスチェンジ内のスロットリングは非常に強力ですが、追跡するのが困難です。

私の経験では、コネクタに制限を設定することは非常に問題があります。大容量を送信しているユーザーのごく一部しかいない可能性があるためです。少数のユーザーのコネクタの制限を押し上げると、セキュリティが侵害されたアカウントによる悪用のリスクが高まります。

調整ポリシー

より大きなボリュームで作業する場合は、最高のメッセージレートを決定し、これらを受信コネクタに設定する必要があります。これはglobalの制限です。

次に、organizationalポリシーとして、制限を中程度の値（5 msg/minなど）に戻すスロットルポリシーを最初に確立する必要があります。

最後に、特定のユーザーの送信制限を引き上げるポリシーを追加できます。

これは、特定のコネクタにアクセスできるすべてのユーザーに「大量メール送信」の制限を公開せず、より詳細な制御を可能にします。

ドキュメント でポリシーに関する詳細情報を取得できます。

検出限界

これは診断には良いポイントですが、サーバー側の制限に達した場合の処理​​は始めません。

メールを送信するときに失敗したことを示す結果は、おそらくもっと多くあります。レート制限への到達はその1つにすぎません。そして、あなたのアプリケーションはこれらと、いくつかのダウンタイムのためにメールサーバー全体に到達できないシナリオを処理する必要があります。

したがって、アプリケーションでの適切なエラー処理とキューイングメカニズムに焦点を当てることを強くお勧めします。 SMTPダイアログメッセージを取得する方法を確認し、障害が発生した場合にログに記録します。これにより、この特定のケースだけでなく、プロダクションですばやく簡単に診断できます。

@seembeeが言ったように、大量に送信すると、ブラックリストに登録されるリスクが高まります。このリスクは、交換をバイパスし、専用の大量メール送信ホストを使用する場合にも発生します。ニュースレターのようなものを送信すると、私は完全に同意します。しかし、請求書などの重要なメールを送信する場合、メールフローに法的な制限さえあるかもしれないので、交換インフラストラクチャをバイパスすることはお勧めしません。

0
Daniel Nachtrub