MINFO (Mailbox Information) レコード検索
RFC 1035で実験的プロトコルとして定義されているMINFO (Mailbox Information) レコードは、メーリングリストや個々のメールボックスに非常に詳細な管理ルーティングメタデータを付加するように設計されています。インターネットのダイヤルアップ時代、ネットワーク接続は絶えず切断され、メールサーバーは頻繁にクラッシュしていました。自動化されたバウンスメッセージ (配信不能レポート、またはNDR) はしばしばサーバー間で無限にループし、ARPANETの限られた帯域幅を圧迫していました。MINFOレコードは、DNS層で直接エラー処理の厳密なルーティングルールを提供しようとする試みでした。
RMAILBXおよびEMAILBXパラメータ
単一のターゲット文字列を使用する標準レコードとは異なり、MINFOのペイロードには2つの異なるポインターが必要でした。1つ目は RMAILBX (Responsible Mailbox) です。このパラメータは、特定のメーリングリストに関連付けられた自動エラーメッセージとサーバーバウンスを受信する責任があるドメインまたはメールボックスを明示的に定義しました。2つ目のパラメータは EMAILBX (Error Mailbox) であり、リストを担当する人間の管理者またはメンテナーを定義しました。外部サーバーがバルクペイロードを配信しようとして致命的な障害に遭遇した場合、送信者の実際のアドレスをバイパスして、エラーログを正確にどこに送信すべきかを見つけるためにMINFOレコードをクエリすることになっていました。
アウトオブバンド (Out-of-Band) シグナリングの失敗
MINFOレコードのコアとなるアーキテクチャの欠陥は、「アウトオブバンド」のシグナリングに依存していたことでした。これにより、すでにSMTPトランザクションの処理の途中にあったメールサーバーは、実行を停止し、新しいUDP接続を開き、MINFOレコードについてDNS層に照会し、伝播を待ってから、エラーのルーティングパスを書き換えることを余儀なくされました。これは、実際の電子メール送信中に単純に「インバンド (In-band)」でエラールーティングを処理するよりも著しく遅く、信頼性が低いことが証明されました。
SMTPヘッダーによるDNSロジックの置き換え
エンジニアたちは、SMTPプロトコル自体がDNS層よりもバウンスメタデータを処理するのにはるかに適していることにすぐに気付きました。特定のSMTPエンベロープヘッダー、特に Return-Path および Errors-To ヘッダーの導入により、MINFOレコードの必要性は完全になくなりました。今日、バルク送信者がニュースレターを発送する際、バウンス処理アドレスを電子メールの非表示ヘッダーに直接埋め込みます。受信サーバーでエラーが発生した場合、ローカルでヘッダーを読み取り、外部のDNSルックアップを必要とせずに即座にバウンスメッセージを返送します。その結果、本番環境のMTAはMINFOペイロードを完全に無視します。