MTAは、宛先MXサーバーに接続できない場合、常にメールをキューに入れますか？
（小規模な）オフィスでは、MXレコードがローカルのExchangeサーバーを指すようにするかどうかを決定しています。ダウンタイムが少し心配だったので、バックアップMXサーバーを設置するべきだと思いました。次に、少し調べてみたところ、 カップル の 投稿 であることがわかりました。これは、送信するMTAがメールをキューに入れるため、必ずしも努力する価値がないことを示唆しています。諦める数日前。これはあなたの業務を整理するのに十分な時間であるはずです。
私はそれですべて満足していましたが、新しいサーバーを購入している地元のITプロバイダーは、サーバーが常にメールをキューに入れるとは限らないと主張しています。誰かがこの立場についてコメントできますか？
また、私は標準が問題について何を言っているかを見つけようとしています（実際の生活と標準が常に一致しているとは限らないことを私は知っていますが）。 バックアップMXレコードに関するウィキペディアの記事
SMTPプロトコルはストアアンドフォワードネットワークを確立し、ドメインのメールサーバーがすべてオフラインの場合、送信サーバーは、後で再試行するために、そのドメイン宛てのメッセージをキューに入れる必要があります。
見て RFC 821 その部分は見つかりませんが、スキャンしているだけです。関連する部分が存在する場合、誰かが指摘できますか？また、メールを破棄するまでの期間を処理する部分にも興味があります。
ITプロバイダーは正しいですが、すぐにバウンスするものもあります。ただし、私の経験では、すぐにバウンスするのはダムホストだけであり、スマートホストはキューに入れられます。 DSNを作成する前にMTAがメールをキューに入れる時間については、いくつかの事実上の標準があり、4時間が最も一般的です。そのようなすべての標準と同様に、多くの変動性があります。
ダムホスト経由で送信される傾向のあるメールの種類は、サーバーが例外を処理するのに十分賢いことを期待しているWebアプリケーションから直接送信されるメールです。これらは、Web上のマスメーラーへの独自のアプリケーションにすることができます。これらのメッセージは一般的に下位クラスの電子メールですが、常にではありません。
バックアップMTAを使用することにした場合は、スパム対策を適用する必要があります。スパマーは、一般的にプライマリほど保護されていないため、「バックアップ」MTAがターゲットに最適な場所であることを10年以上前から知っています。
必須ではないと思いますが、良い習慣です。
キューイングと再試行のかなり標準的な値は、「最初に30分後に再試行し、その後12時間経過するまで60分ごとに再試行します。その後、72時間経過するまで6時間ごとに再試行し、その後、12〜24時間間隔でさらに数回再試行します。 。7日以内にメールを配信できない場合は、メールをドロップして（オプションで、偽の発信者が多すぎるため、最近は「申し訳ありませんが、配信できませんでした」と返します。
確かに、これは主に経験によるものであり、多少古いものです。私は約4年間、仕事用のメールサーバーを実行していません。
メールサーバー[〜＃〜] should [〜＃〜]キューに入れますが、すべてのメールサーバーが正常に動作するわけではありません。しかし、電子メールで問題が発生する可能性のあるものは他にもたくさんあるため、私が知っているほとんどの非常に小規模な企業は、費用効果が高くないように思われるため、バックアップを気にしません。
これを行う場合は、ISPがバックアップメールサーバーのストアおよびリレーとして機能するかどうかを確認することをお勧めします。つまり、ISPはユーザーに代わってメールを受け入れ、利用可能になったときにサーバーに送信します。 （サーバーとバックアップサーバーの両方がオフラインになった場合は役に立ちません）。
私たち自身の経験から、私たちのISPはこのサービスを提供していますが、それは私たちが利用しないことに決めた追加費用です。 （10年以上問題は発生していません。顧客ベースは非常に小さく、技術的ではないため、メールの送信に問題が発生した場合は、電話を解除することになると確信しています）。