DNS設定が原因で一部の送信者からメールを受信しない

私のグーグルアプリドメインの奇妙な振る舞いに気づきました。ほとんどのメールは予想どおりに届きますが、ある期間、特定の送信者からのメールが届かないという結論に達しました。メールが届かない送信者を1人特定した後、私にメールを送信して「配信失敗」の応答を通常のGmailに転送するように依頼しました。

配信失敗の応答には、次のスニペットが含まれていました。

-----セッションのトランスクリプトが続きます-----
<myusername@GHS.L.GOOGLE.COM>...遅延：ghs.l.google.comで接続がタイムアウトしました。

これは、Google Appsヘルプフォーラムのこのページに私を導いたクイック検索を行うことによって問題を特定するのに役立ちました。実際、ドメインのDNSレコードを確認したところ、@ghs.google.comに設定されていました。（CNAME）、それをすべきではありません。これを@ 74.125.93.121 (A)*に変更すると、問題は解決しました。

メールが届かない場合は、CNAMEルックアップによってドメイン名が正規の名前に置き換えられたため、myusername@ghs.l.google.comではなくにメールが送信されたと理解していますmyusername@mydomain.com。しかし、それが送信者の大多数で機能したのはなぜですか？メールが届かない送信者は、別の種類のメールプロトコル、奇妙なDNS設定を使用していましたか、それとも何ですか？

グーグルで問題を調査することで私が見ることができたものから、これは広範囲にわたる問題であるように思われます（battle.netからの電子メールが届かないという多くの人々は、1つの人気のある例です）、人々はそうではないようです問題は送信者側ではなく、独自のDNS設定にあることに注意してください。

これはどのように説明できますか？

^{* ここで読んだことから、この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：//www.example.com/へのHTTPリダイレクトを行うだけです。

それが機能したのと同じように機能したのは少し意外です。ポステルの法則は、そこにある程度の信用を得ていると私は信じています。:-)

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」ドキュメントで人々がそれに依存するのをやめるべきだと考える理由について詳しく説明しています。

@BINDレコード内のシンボルは、ドメインを記述する簡単な方法にすぎません。のレコードを作成する場合example.com、@はの単なるエイリアスですexample.com。@レコードがIPである必要があると言うことは、重要な情報が欠落しているステートメントである-それがどのタイプのレコードであるかを私たちに言わなかった。

配信レポートから、おそらくDNSでリモートメールサーバーがドメインをghs.l.google.comに書き換える原因になったようです-非常に奇妙です（PS、Aレコードは IP、CNAMEレコードでなければなりません） IPまたは別のCNAMEレコードであってはなりません）。

なぜその人のメールサーバーがあなたのアドレスを書き換えているのかがおかしいのです。MXレコードはメールサーバーがメールの送信先を特定する方法であるため、MXレコードが見つからない場合を除き、ドメインのIPが何であるかについてはまったく気にする必要はありません。

提供される情報が非常に少ないため、電子メール用にDNSを適切に構成する方法に関するGoogleの指示に従わなかったように思えます。ゾーンファイルにエラーが含まれている可能性もあります-有能なゾーン管理者にチェックしてもらいます。