要約

  • RFC 5383は、ホテルなどが本来の宛先ホストにかかわらずポート25への接続を横取りし、利用者が気づかないまま機微な通信を未知の第三者サーバーへ渡し得ると記した。
  • ポート587はユーザー投稿とサーバー間転送を分ける運用上の境界である。番号だけでは相手の身元、TLS、投稿権限、キュー受領、転送、最終配送を証明しない。

エラーが出なかったことが問題だった

普通の障害なら、接続はタイムアウトするか拒否される。利用者は送れなかったと分かり、管理者も経路やポリシーを調べられる。横取りは逆である。別のサーバーがSMTPとして自然に応答するため、画面上では処理が前進する。

RFC 5383の第3節は、当時のメールユーザーエージェントが投稿にもポート25を使っていた事情と、ISPや組織がその送信を制限していた事情を並べる。さらに、一部のホテル等が接続先ホストを無視してポート25を横取りし、利用者が知らない第三者へ通信を渡す危険を指摘した。

この文書は現在の発生率も、特定事業者の事件も示さない。だが、設計上の境界は明確である。ネットワークが接続を成立させたことと、端末が指定したサービスを維持したことは別の事実だ。

横取りしたアクセス事業者は、単なる運搬者ではなくアプリケーションの相手を決める者になる。その権限が見えなければ、利用者は誰に資格情報や本文を渡したかを判断できない。

投稿口を転送路から独立させる

メールは一つの処理ではない。利用者のアプリが文章を作り、投稿サービスへ渡す。投稿側はアカウントを認証し、方針を適用し、引き受けるか拒否する。その後に転送エージェント、宛先システム、メールボックス、閲覧が続く。

RFC 2476はMessage Submissionを独立したサービスとして定義し、RFC 4409が改訂、RFC 6409が現行の後継となった。587はユーザーからの投稿口、25は主に転送のための口として役割を分ける。RFC 5383がLemonadeクライアントに587への到達性と既定利用を求めたのは、この分離を実装上の現実にするためだった。

分離によって、認証方式、拡張、制限、引受け証跡を投稿サービスの責任として扱える。ファイアウォール側も、許可するサービスを明示できる。しかし587という数字は、背後の組織を認証しない。これは共通語彙であって、身分証ではない。

証跡を一つの「送信済み」に畳まない

検証すべき対象は連続しているが同一ではない。設定されたホスト名、DNS応答、実際のTCP peer、TLSの参照ID、証明書検証、SMTP認証主体、トランザクションの受理、後続転送、宛先での結果である。

後年のRFC 8314はメールアクセスと投稿でTLSを推奨し、465のsubmissionsサービスを記載しつつ、587上のSTARTTLSという既存経路も扱った。この更新は「587なら安全」という読み方を否定する。暗号化と身元確認は、クライアントが正しい参照IDを検証し、失敗時に停止して初めて成立する。

監査ログには、意図したホスト名、解決先、接続先、ポート、TLS方式、証明書、検証結果、SMTP bannerとcapability、認証方式と主体、応答コード、キューID、時刻を別々に残す必要がある。「接続成功」だけでは、最も重要な差し替えを消してしまう。

正直な拒否は、不透明な成功より回復しやすい

ポート25を止めること自体には、spam対策や感染端末の封じ込めという運用理由があり得る。問題は拒否ではなく、拒否を別サーバーへの接続成功にすり替えることだ。

明示的なblockなら、クライアントは587や465へ移り、利用者に通知し、管理者は方針を直せる。横取りでは、選ばれていないシステムが内容を受け取り、端末だけが成功を記録する。本来のメール事業者には何の記録も残らない。

SMTP拡張を部分的にしか理解しないアプリケーションfirewallも、片側だけに交渉を見せて後の状態をずらす。本稿はRFC 2979の一般的なfirewall透明性やRFC 3093のHTTP tunnelを再論しない。焦点は、最初の投稿で誰が相手になったかという証拠である。

受理と配送を別の判定にする

正しい投稿サーバーが肯定応答を返しても、それは当該ポリシー下で引受けたという限定された証拠である。後続relay、メールボックスへの保存、表示、閲覧までは証明しない。

事故対応では、endpoint選択、保護されたchannelのidentity、認証アカウント、envelopeと本文の受理、queue custody、転送試行、宛先応答を順に接続する。横取りがあれば、queue IDは差し替え先の管理領域にしか存在しない。精密な番号でも、本来のサービスとの関係は自動では生まれない。

検証環境では、管理した投稿サーバーへ企業網、携帯網、家庭網、guest網から接続し、設定先と実peerを比較する。誤証明書、STARTTLS欠落、capability減少、未知のbanner、明示blockを発生させる。許されるのは、正しいidentityを確認した成功か、理由の分かる失敗である。緑の表示を守るためのsilent downgradeは受入れ条件にしてはならない。

出典