バックアップ メール サーバーが大量のメッセージを消費してしまったので、450すべてのメッセージを送信するための単純なサーバーを構成したいと考えています。
ただし、再試行時に送信サーバーが優先度の高いサーバーへの送信を試みない場合、メッセージは配信されないため、これが良いアイデアであるかどうかはわかりません。
これについては RFC で何も見つけられませんでしたが、サーバーはより優先度の高いサーバーで再試行するのでしょうか、それとも応答した同じサーバーで永久に試行するのでしょうか450?
答え1
SMTP配信が失敗した場合（受取人常駐なし5xy否定完了 SMTP 応答）代替/バックアップMXが定義されていないと、RFCは送信側の実装に任せている再度の配送試行が行われるかどうか、また、その後の配送試行の頻度と期間はどのくらいか。標準では、送信側の実装に委ねられている。一時的な配送遅延通知はどのくらい早く届くか元の送り主に返送されるか、永久的な配信失敗エラー通知がどれだけ早く届くかが返されます。
複数のMXレコード受信者ドメインに定義されている場合、標準に準拠した送信者は、すべての配信試行ごとに、いずれかのMXがメッセージを受け入れるまで（送信者は2xx肯定的な完了 SMTP 応答）、または1つのMXがメッセージを拒否する（永続的な5xy否定完了 SMTP 応答) またはすべてに連絡するまでです。
いずれの (プライマリおよび/またはバックアップ) MX レコードもドメインのメール メッセージを永続的に受け入れたり拒否したりしていない場合、代替 MX レコードが存在しない場合と同じ、送信者の実装固有の失敗パスが実行されると考えられます。 言い換えると、次のようになります。「送信者はメッセージをキューに入れて後で配信するか、諦めるかを選択できます」。
やるかやらないか
複数の MX レコードと独自の管理下にあるバックアップ メール サーバーの全体的な概念は、それを自分で管理し、元の送信者のキューイングおよび再試行ポリシー、またはその欠如に依存する必要がないということです。
その制御を望まないとき;バックアップ MX でメールをキューに入れたくないが、キューと配信の再試行を送信者に任せたい場合は、バックアップ MX レコードをまったく構成しないでください。これは、エラーを生成するだけで、実際には電子メールを受け入れてキューに入れないサーバーを指すバックアップ MX を設定する場合と同じ効果 (またはそれ以上の効果) があるはずです。
私の意見では、バックアップMXの本来の目的は
プライマリ サーバーがオフラインになったり、停止や計画メンテナンスのために使用できなくなったりした場合、RFC と送信者による SMTP プロトコルの正しい実装によって、ドメイン宛ての電子メール メッセージがバックアップ MX に送信され、そこでメールが受け入れられ、(計画された)停止が終了するまでキューに入れられることが保証されます。バックアップ
メール サーバー (送信者ではありません) が、メール配信の遅延/失敗通知を元の送信者に送信するかどうか、
またいつ送信しないかを制御します。停止が終了し、プライマリ メール サーバーとメールボックスが再びオンラインになったら、バックアップ MX のキューをフラッシュして、キューに入れられたすべてのメールを (ほぼ) 即座に受信できます。ETRNたとえば SMTP コマンド。
答え2
jcaron のコメントで示唆されているように:
2 番目の MX が 450 を送信する理由はありますか? 何もしない場合 (つまり、そのポートでサーバーが応答しない、または 2 番目の MX がまったくリストされていない場合) も同じ結果になり、作業が少なくなります... ただし、どのような解決策でも、送信者はメールを永久に保存するわけではないことに注意してください。 多くは数日間再試行しますが、タイムアウトがはるかに短いものもあります (最初のエラーでアドレスをブラックリストに登録するものもあります)。
XY 問題に対する正しい解決策は、バックアップ MX を用意しないことです。複数の MX を用意する必要はまったくありません。正当な送信者であれば、1 日以上、多くの場合 1 週間以上、配信を再試行します。サーバーがダウンしてメールをすぐに受信できない場合は、怪しいサード パーティのキュー サービスではなく、送信者のメール システムに任せるのが、明らかに正しい方法です。メールが「食べられてしまう」のを防ぐだけでなく、メールを傍受する権限を持つサード パーティを信頼することも避けられます。また、非常に長い停止によってメールが配信不能になった場合に、送信者に (送信者のメール システムによって) 通知が届くようになります。
実際の質問ですが、SMTPの再試行の仕組みは十分に規定されておらず、保証準拠した送信者は、一時的な失敗を報告しながら偽のセカンダリMXに配信を試み続けるのではなく、到達不能と分かった後、プライマリMXを試すためにループバックするはずです。したがって、上記の理由がなくても、すべきではないセカンダリ MX をお持ちの場合は、この特定のハックを試すのは悪い考えだと思います。
関係があるかもしれないが、私の経験では、個人/小規模サイトのメール システムを 22 年以上継続的に運用しており、複数の MX を使用したことは一度もない。