web-dev-qa-db-ja.com

SMTPバナーが複数のMXレコードと一致しない

私の直感は、「これは問題ではなく、論理的に実際に修正することはできない」と言います。オンサイト交換メールサーバーで使用するバックアップISP接続を構成しています。

これは私が設定したものです：

198.51.100.30 -> primary ISP
203.0.113.40 -> backup ISP

以下は、example.comドメインDNSに追加されました。

mail.example.com. A 198.51.100.30
mail2.example.com. A 203.0.113.40
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.

関連するISPによって追加されたPTR：

198.51.100.30 mail.example.com
203.0.113.40 mail2.example.com

現在、メールサーバーは常にmail.example.comバナーとして、すべてが順調です。MXToolBoxは満足しています。ただし、フェイルオーバーMXに関するバナーはどうすればよいですか？明らかにフェイルオーバーPTRはmail2.example.comそして、MXToolBoxで「リバースDNSがSMTPバナーと一致しない」を生成します。

私はこれについて心配していませんか、または何かを正しく設定していませんか？

編集：SSL SANメールサーバーにインストールされた証明書には両方のmail.example.comおよびmail2.example.com。

domain-name-systememailmx-record
2
AngryCarrotTop

ベストプラクティス：2つのMXサーバーがある

最適なオプションは、2つのサーバーを使用することです。つまり、バックアップ/セカンダリMXサーバーとして、別のExchange（または、PostfixなどのオープンソースベースのSMTPサーバー）を構成します。ほとんどの場合、サーバー自体がインターネット接続よりも多くのダウンタイムを引き起こす可能性があります。バナーの不一致は送信メールの問題にすぎないため、このサーバーは現在の構成では完全にmail2.example.comである可能性があります。

2つのインターネット接続を備えた単一のサーバー

送信メールの構成

2番目のアプローチは、両方の接続を同じホスト名で構成することです。これは、実際には異なるホストへのIPアドレスとルートを持つ同じホストだからです。これは、ラウンドロビンDNS構成+一致するPTRレコードとSMTPバナーで実現できます。

mail.example.com. A 198.51.100.30
mail.example.com. A 203.0.113.40
40.113.0.203.in-addr.arpa. PTR mail.example.com.
30.100.51.198.in-addr.arpa. PTR mail.example.com.

両方のIPアドレスがメールを送信できるようにするSPFレコードを追加することを忘れないでください。

example.com. IN TXT "v=spf1 +ip4:198.51.100.30/32 +ip4:203.0.113.40/32 -all"

受信メールの設定

受信メールでセカンダリよりも最初のISPを優先する場合（たとえば、帯域幅が優れている場合）、MX構成をこれから分離できます。追加して

mx1.example.com. A 198.51.100.30
mx2.example.com. A 203.0.113.40
example.com. MX 10 mx1.example.com.
example.com. MX 20 mx2.example.com.

バナーの不一致はインバウンドメールでは問題ではないので、これで問題ありません。

証明書

両方の構成で証明書を有効に保つには、mail.example.com、mx1.example.com、mx2.example.comのすべてにSANが必要です。メールサーバーの証明書が実際に検証されることはめったになく、ほとんどのメールシステムは暗号化されていない接続へのフォールバックを許可するため、一般にこれはそれほど重要ではありません。

CAベースの証明書の検証の代わりに、名前付きエンティティのDNSベースの認証（DANE、 RFC 6698 ）は、自己署名の検証を可能にする提案された代替手段です証明書も。下位互換性のために、暗号化された接続のみを許可するようにSMTPサーバーを構成することはできません。これにより、TLSを介して確立される可能性のある接続に対するMitM攻撃の穴が残ります。 DANEを使用すると、接続にTLSを使用し、DNSゾーンで公開された証明書のみを許可することを宣言できます。

2
Esa Jokinen

Mail2を使用して送信メールを送信する場合は、バナー名が何であるかを気にするだけです。その場合でも、使用しているIPのリバースDNSと一致する必要があります。残っている唯一の確認事項は、SSL証明書で適切な名前が使用されていること（3つの名前すべてが各サーバーで一致している必要があります-バナー/ヘリ名、SSL証明書の名前、逆引き参照）、バックアップサーバーがリストされていることですすべてのSPFレコードなどで、私のSPFレコードは単に「このドメインのすべてのMX」をリストします。

だから、はい、あなたが投稿したもので私が知ることができる限り、あなたは行ってもいいでしょう。

6
ivanivan

次の2つの理由により、これは実際の問題ではないという直感を持っています。

  1. MXレコードは、メールの受信メールメッセージの受信場所を管理します。
    バックアップMXレコードは、メールの送信に使用するためのものではなく、受信メールを受信するためだけに使用されます。

    メールの受信は簡単です。たとえば、下位互換性のためにTLS証明書の内容を少し厳密にチェックしている送信者もいますが、ほとんどすべての送信者は、何かが両方をリッスンしている限り、単にMXレコードにメールを配信しますTCPポート25、SMTPプロトコルメッセージに正しく応答し、「250要求されたメールアクションが正常に完了しました "という応答を受け取ります。

（確実に電子メールを送信するだけなので、構成とプロトコルの順守ははるかに慎重に行う必要があります。）

  1. 着信SMTPサーバーは、それ自体を識別する必要はありません。受信したいメッセージを受け入れ、受信しないメッセージを拒否するだけです。 （送信者のみが自分自身を識別する必要があります。）

    私が知る限りほとんどすべてのサーバーメッセージの実際の SMTP応答の戻りコード番号のみがプロトコル自体に関連しています。バナーメッセージだけでなく、エラーやその他のほとんどのメッセージに含まれるSMTPサーバー応答コードに続くテキストは、デバッグの目的/人とのやり取りにのみ関係し、SMTPプロトコルの観点からはまったく関係がありません（ほとんど無視されます）。これはサーバーメッセージ専用であり、スパムSMTPサーバー自体に対抗するには、クライアント/他のメールサーバーからメッセージを受信する際に何を要求するかについて、はるかに厳格であることに注意してください。

から RFC 5321 ：

SMTPサーバーの実装には、220コードの後に​​接続グリーティング応答にソフトウェアとバージョン情報の識別を含めることができます。これにより、問題をより効率的に分離して修復できます。セキュリティの問題が発生するソフトウェアとバージョンのアナウンスを無効にするSMTPサーバーの実装を実装が作成する場合があります。

1
HBruijn