DNS設定が原因で一部の送信者からメールを受信しない
私のグーグルアプリドメインの奇妙な振る舞いに気づきました。ほとんどのメールは予想どおりに届きますが、しばらくすると、特定の送信者からのメールは届かないという結論に達しました。メールが届かない送信者を特定した後、私にメールを送信して「配信エラー」の応答を通常のGmailに転送するように依頼しました。
配信失敗の応答には、次のスニペットが含まれていました。
-----セッションのトランスクリプトが続きます-----
_<[email protected]>_...遅延：ghs.l.google.comで接続がタイムアウトしました。
これは、Google Appsヘルプフォーラムで このページ にアクセスするためのクイック検索を行うことで問題を特定するのに役立ちました。実際、ドメインのDNSレコードを確認したところ、_@_はghs.google.comに設定されていました。 （CNAME）、それはすべきではありません。これを@ 74.125.93.121 (A) *に変更すると、問題が解決しました。
メールが届かない場合、ドメイン名がCNAMEルックアップを通じて正規名に置き換えられたため、メールは_[email protected]_ではなく_[email protected]_に送信されたと理解しています。 しかし、それが送信者の大多数で機能したのはなぜですか？メールが届かない送信者は、別の種類のメールプロトコルを使用したり、奇妙なDNS設定、またはそれは何でしょうか？
グーグルで問題を調査することによって私が見ることができたものから、これは広範囲に及ぶ問題であるように思われます（battle.netからのメールが届かないという多くの人々は、1つの人気のある例です）、人々はそうではないようです問題は送信者側ではなく、独自のDNS設定にあることに注意してください。
これはどのように説明できますか？
*私が読んだもの here のためにこのIPを使用しましたが、どのIPでもうまくいくと思います。誰かがこれを確認できますか？ _@_レコードを削除しただけでは問題が解決せず、変更する必要があったことに注意してください。
RFC 2821「Simple Mail Transfer Protocol」のセクション5「アドレス解決とメール処理」から：
ルックアップでは、最初に名前に関連付けられたMXレコードを見つけようとします。代わりにCNAMEレコードが見つかった場合、結果の名前は、それが初期名であるかのように処理されます。
一般的に、これはCNAMEが機能する方法です。多くの場合、誤用、誤解、実装の誤りです。 :-)
ドメインがexample.comの場合、通常のGoogle Appsホストを指す既存のMXレコードがある可能性があります。
example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.
次のようなエントリもあるようです：
example.com. CNAME ghs.l.google.com.
RFC 1034の「ドメインの概念と機能」では、セクション3.6.2「エイリアスと正規名」に次の構成を推奨しています。
CNAME RRがノードに存在する場合、他のデータは存在しません。これにより、正規名とそのエイリアスのデータが異なることがなくなります。
貼り付けたエラーの場合、送信側のメールサーバーやDNSサーバーがドメインexample.comのMXレコードを検索しようとして、ghs.l.googleを指すCNAMEを見つけました。 com。次に、ghs.l.google.comのMXレコードを検索しようとしました。そのドメインには現在MXレコードがないため、メールサーバーはghs.l.google.comのAレコードにフォールスルーすることになります。そのIPアドレスはSMTPポートでリッスンしていなかったため、「ghs.l.google.comで接続がタイムアウトしました」というエラーが発生します。
CNAMEレコードを削除すると、メールの問題が修正されます。その場所で定義したIPアドレスがGoogle側で変更されると、問題が発生する可能性があります。
代わりに、www.example.comのcnameを定義できます。
www.example.com. CNAME ghs.l.google.com.
そして、example.comが指すIPで小さなWebサーバーを実行します。これは、HTTPリダイレクト http://www.example.com/ を実行するだけです。
それが機能したのと同じように機能したのは少し意外です。ポステルの法則はそこにある程度の信用を置いていると私は信じています。 :-)
RFC 1034 2.6.2に戻る：
CNAME RRはDNSソフトウェアで特別なアクションを引き起こします。ネームサーバーは、ドメイン名に関連付けられたリソースセットで目的のRRを見つけることができない場合、リソースセットが一致するクラスを持つCNAMEレコードで構成されているかどうかを確認します。その場合、ネームサーバーは応答にCNAMEレコードを含め、CNAMEレコードのデータフィールドで指定されたドメイン名でクエリを再開します。このルールの1つの例外は、CNAMEタイプに一致するクエリが再起動されないことです。
したがって、この場合、MXレコードが見つからない場合を除いて、DNSサーバーはMXルックアップでCNAMEを追跡する/しないべきであると主張することができます。
メールを送信するとき、Sendmailとqmail（およびその他の可能性が高い）はデフォルトで、メールアドレスの右側に使用されているCNAMEを正規名に書き換えようとします。
実際、一部のサイトはこの動作に依存していました。 djbは、なぜ彼が "CNAME records in mail" document で人々がそれに依存するのをやめるべきだと考えるのかについて詳しく説明しています。
BINDレコード内の@記号は、ドメインを記述するための簡単な方法です。 example.comのレコードを作成している場合、@はexample.comの単なるエイリアスです。 @レコードはIPである必要があると言っているのは、重要な情報が欠落しているステートメントです-それがどのタイプのレコードであるかを知らせていませんでした。
配信レポートから、リモートメールサーバーがドメインをghs.l.google.comに書き換える原因となった可能性があると思われます-非常に奇妙です（PS、Aレコードmust IPであること、CNAMEレコード必須 IPまたは別のCNAMEレコードであってはなりません）。
なぜその人のメールサーバーがあなたのアドレスを書き換えているのかがおかしいのです。 MXレコードはメールサーバーがメールの送信先を特定する方法であるため、MXレコードが見つからない場合を除いて、ドメインのIPが何であるかについてもまったく気にする必要はありません。
提供された情報が非常に少ないため、メール用にDNSを適切に構成する方法に関するGoogleの指示に従わなかったように思えます。ゾーンファイルにエラーが発生している可能性もあります-有能なゾーン管理者にチェックしてもらいます。