要約

  • RFC 821の任意コマンドTURNは、開いているSMTPチャネル上でクライアントとサーバーの役割を入れ替えた。間欠接続には便利だったが、認証されないホスト名に保管メールの行き先を委ねた。
  • RFC 1985のETRNは要求を小さくした。クライアントは名前付きキューの処理を促すだけで、サーバーが認可を保ち、別の送信接続を開き、配送が判明する前に応答する。

一度つながった回線を往復に使う

小規模サイトに常時到達できる受信経路があるとは限らなかった。事業者へダイヤルしたとき、自分の送信メールを渡すだけでなく、オフライン中に積まれたメールも受け取りたい。通常の再試行時刻を待てば、短い接続機会を失う。

RFC 821のTURNでは、呼び出し側がsender-SMTP、事業者がreceiver-SMTPとして始まる。事業者が250を返すと同じチャネル上で役割が逆転し、元の呼び出し側はサービス準備完了の挨拶を送り、受信側として待つ。事業者は502で拒否でき、実装も任意だった。

回線は節約できた。しかし、その回線が証明していない信頼まで再利用した。

HELOで名前を言っても保管権は得られない

サーバーは新しい受信側にどのキューを渡すか決めなければならない。初期SMTPは相手が名乗るホスト名を認証しなかった。攻撃者は別サイトの名前を使ってTURNを要求し、そのサイト宛ての保管メールを現在の接続へ流させ得た。

偽のヘッダーより影響は大きい。メッセージ全体の保管先が変わる。RFC 1985はこれを大きなセキュリティ上の穴と呼び、確認規則がないため多くの実装がTURNを避けたと記した。

一つの未検証主張が、想定身元、両者の役割、接続方向、キューの配送先をまとめて変えることが問題だった。

ETRNは作業を頼み、メールを受け取らない

RFC 1985は必要性を残して権限を縮めた。サーバーはEHLO後にETRNを広告し、クライアントはノード名を指定して対応キューの処理開始を求める。セッション確立後に使えるが、MAIL FROMからDATA完了までの取引途中には入れられない。

サーバーは範囲を調べ、許可するかローカルに決める。受け入れると再試行キューを起動し、指定サイトへ別のSMTP接続を作る。要求者は制御接続の要求者のままであり、名前を知っているだけでは一通も受け取らない。

別接続は完全な認証ではない。DNS、経路、接続、受信側SMTP取引が宛先と受理を改めて決める独立証拠面である。トリガー接続の自己申告だけに依存しない。

受理応答は配送受領書ではない

キュー処理には不定の時間がかかる。RFC 1985は接続が必ず起きるとも、期限内に起きるとも要求しない。そのためETRNはすぐ応答する。

通常の250は要求が妥当で処理が始まったことを示す。メールの存在、送信接続の成功、受信者の受理は証明しない。任意の251、252、253はローカル情報を増やすが、エンドツーエンド配送証拠ではない。

監視が250を「配送済み」にすれば、仕様が残した不確実性を消す。トリガー受理、接続試行、SMTP転送、最終配送は別イベントである。

キュー名の意味はサーバーに残った

基本パラメーターは完全なノード名である。@ドメインは配下のサブドメインを含むキューを起動でき、#名前はUUCPなどローカル定義キューを選べる。

広い選択子は危険も増す。@comのような範囲は大量作業と輻輳を招く。#名に世界共通辞書はなく、クライアントが一覧を得る方法もない。サーバーは自らの保管モデルに基づき、要求者と範囲の組合せを認可する。

IANAはETRNという語を調整しても、キュー権限を与えない。

廃止は信頼予算を減らした

RFC 2821はTURNを非推奨とし、RFC 5321も、役割交換を求めるクライアントを強く認証できない限り使わないとした。暗号化だけでは足りず、認証主体が特定メールを受け取ってよいかが必要である。

RFC 5321はさらに小さい工夫も示す。あるホストからメールを受け取った事実を、そのホスト向けキューの再試行を早めるローカルな手掛かりにできる。スケジュールは変わっても、キューの所有は移らない。

現在のIANAレジストリはTURNとETRNを歴史的項目として残す一方、メール投稿サービスでの利用を禁止する。587番ポートの利用者資格はSMTP配送キューの起動権ではない。

間欠接続の需要は消されなかった。依頼する者、認可・実行する者、配送を受理する者が分かれた。どの事実も他の事実を代行しない。

出典