400 4.4.7メッセージの遅延

先週Exchange 2010が稼働し、キュービューア（Exchangeコンソール内）で、エラーが発生しているいくつかの電子メールが表示されていることに気づきました400 4.4.7 message delayed。

メンバーが受け取っているリベート応答は次のとおりです。

Delivery is delayed to these recipients or groups:

XXX@aol.com (XXX@aol.com)

Subject: test

This message hasn't been delivered yet. Delivery will continue to be attempted.

The server will keep trying to deliver this message for the next 1 days, 19 hours and 54 minutes. You'll be notified if the message can't be delivered by that time.

これは1つの具体的な例にすぎず、他のメールアドレスが機能する複数のドメインが複数存在します（同じドメインに対して）。

メールをフィルターでフィルタリングしてサーバーに送信しようとしていますが、今のところMXレコードはExchangeサーバーを直接ポイントしています。

これを解決する方法について誰かが何か考えを持っていますか？または、フィルターに移動すると（つまり、MXレコードのアドレスを変更すると）、これは解決しますか？

このエラーには多くの可能性があります。別の質問での私の答えから取ったものです（ただし少し変更されています）：

まず、telnetを使用してリモートメールサーバーとのSMTPセッションを確立し、さらに情報が得られるかどうかを確認します。

また、リモートサーバーに関連付けられているドメインまたはIPとの間のパケットのドロップ、変更、またはその他の微調整を行う、何らかの奇妙なファイアウォールルールが設定されている可能性もあります。ありそうもないが、私は見知らぬものを見てきました。ゲートウェイファイアウォールとExchangeサーバーのソフトウェアファイアウォールを調べて、リモートSMTPサーバーに何らかの影響を与える可能性のあるルールがないか確認します。リモートドメインに関連付けることができるドメイン、IP、およびアドレスの範囲を確認します。

別のスリムな可能性は、リモートドメインにDNSゾーンの問題があることです。MXレコードが古い可能性があります。おそらく、ゾーンの移行を実行しましたが、すべてを新しいDNSサーバーに移行していません。繰り返しになりますが、より奇妙なことが起こりました。

さらに別の可能性として、受信サーバーが送信IPで逆DNSルックアップを実行していて、MXレコードと一致していない可能性があります。MXレコードが192.0.2.1を指しているが、192.0.2.2であるファイアウォールの背後にあり、192.0.2.1を受け入れるようにファイアウォールで仮想IPが設定されている場合、送信トラフィックは192.0.2.1と見なされますが、RDNSはメールサーバーとして192.0.2.2を表示します。この不一致により、一部の受信サーバーがさまざまな方法でメッセージを拒否する可能性があります（ただし、受信者の電子メール管理者が通知メッセージを抑制せず、一般的なエラーメッセージを選択しないことを望みます）。

（補足として、上記のようなRDNSチェックは、送信メールのリレーを認証している人が多く、必然的に受信サーバーと一致しないため、ばかげています。メール管理者は怠惰にしないでください！）

最後に、確かに重要ですが、SPFレコードを使用してください！DKIMも。一時的な電子メールの問題の多くは、これらの2つを適切に設定すると消える場合があります。

もちろん、Shane Maddenを聞いて、メールキューを確認してください。

最後に、リモートドメインの管理者に連絡して、それらを管理します。あなたは彼らと協力して問題を理解する必要があるかもしれません。

Exchange管理コンソールの[ツールボックス]セクションでメールキューを確認します。

メッセージが配信されようとするたびに生成されている特定のエラーを掘り下げることができます。これにより、根本的な原因が明らかになります。ドメインキューで特定の問題メッセージを見つけ、メッセージを右クリックしてプロパティを開きます。「Last Error」セクションは興味深いものです。

考えられる原因は、ポート25 / tcp接続とDNS解決の問題ですが、問題が解決されず、根本的な原因の特定を支援できる場合は、質問で見つかったエラーを編集してください。

これ以上の情報がなければ、これは奇妙に見えません。一部の受信者のサーバーは、サーバーのフラッディングを防ぐレート制限制御を実装しています。一部のメッセージはすぐに通過し、他のメッセージは待機する必要があります（後で再試行します）。

この問題は（のは言わせて）より多くのための真であれば、あなたのメールの10％が、あなたは、DNS解決、内部ファイアウォールまたは上のメールフロー防ぐため、他の奇妙なネットワーク設定に問題を抱えてあなたのサイトを。

しかし、これはMX設定とはまったく関係ありません。

特にaol.comドメインの場合、会社がそれらに大量のメールを送信する場合（ブラックリストに登録するためのしきい値がわからない）、ポストマスターの連絡先にドメイン名を登録する必要があります。このウェブサイト：http : //postmaster.aol.com/Postmaster.Whitelist.php

Exchangeサーバーで設定されていたDNSは廃止されました。いくつかの遅延メールドメインにpingを実行しようとしましたが、解決策が返されませんでした。

サーバーのネットワーク設定に移動し、プライマリおよびセカンダリDNSを更新しました。

すべてが再びうまく流れ始めます。

お役に立てれば