要約

  • SMTP AUTHはメール取引の前にSASL交換を置き、投稿サーバーが接続元IPではなく、認証・認可された主体に限定した中継権を与えられるようにした。
  • 成功が示すのは、そのセッション境界での判断だけである。認証ID、認可ID、エンベロープ送信者、表示上の著者、本文、後続経路は別々の主張として残った。

接続元を知ることは、利用者を知ることではなかった

初期のSMTPは、協力関係にあるホスト間でメールを運ぶ仕組みだった。ローカル宛てを受け取り、必要なら別のホストへ中継する。ところが、到達できる誰にでも任意の宛先への中継を許せば、公開サーバーはオープンリレーになる。

送信元IPによる許可も、移動する利用者には合わなかった。正当な契約者が外出先のネットワークを使うと拒否され、許可済みのアドレス帯にいる端末が特定の送信者を名乗る権限を持つとは限らない。POP-before-SMTPは別プロトコルの直前のログインをIPと時間で結び付けたが、メール投稿そのものを認可したわけではなかった。

1999年の拡張を引き継いだRFC 4954は、判断をSMTPセッション内へ移した。サーバーはEHLO応答でAUTHとSASLメカニズムを広告し、クライアントはMAIL FROMより前に一つを選んで交換を完了する。成功して得られるのは普遍的な本人証明ではない。サーバーが資格情報を受け入れ、ローカル方針の下で認可IDを決めたというセッション事実である。

その事実は中継の入口を制御できる。しかし、誰が文章を書いたかは答えない。

SASLは二種類の主体を残した

SASLでは、認証IDと認可IDを区別する。認証IDは検証された資格情報の主体であり、認可IDはクライアントが代行を求める主体である。まず資格情報を確かめ、その後で前者が後者として行動してよいかをサーバーが決める。

共有サービスのアカウントが複数利用者のメールを投入することもある。秘書が一つのメールボックスだけを代理送信できる場合もある。侵害された資格情報は認証には成功しても、要求した送信範囲まで許されているとは限らない。このためログイン名をMAIL FROM、表示上のFrom、人間の著者と同一視できない。

認証が答えるのは「どの主体がどのメカニズムでこのセッションを作ったか」、認可が答えるのは「ここで何をしてよいか」である。エンベロープと内容は次の問いだ。運用ログがこれらを一つの「ユーザー」に畳めば、プロトコルが守った境界を失う。

投稿サービスは転送サービスから分かれた

RFC 6409は、メールユーザーエージェントからメール投稿エージェント（MSA）への新規メッセージ投入を、MTA間転送とは別のサービスとして整理した。ポート587のMSAは、利用者側の誤りを拒否または修正し、受け取ったメールをMTA網へ渡す。

セッションにSMTP AUTHも保護されたサブネットなどの独立した認可もなければ、MSAは原則としてMAILを認証要求の状態で拒否する。これはインターネット上の全MTAに、上流ピアを人間の利用者として認証させる規則ではない。提供者と投稿クライアントに直接の関係がある地点へ、強い入場管理を置く設計である。

利用者は自社回線のIPに見せかけず、外出先から資格情報で投稿権限を得られる。受信MTAは自ドメイン宛てのメールを受け続けながら、任意宛先への中継を開かずに済む。IANAが登録するのはAUTHという拡張名やSASLメカニズム名であり、あるアカウントが財務部門やメーリングリストを名乗ってよいかではない。

TLSの前後では見える能力も変わる

認証メカニズムが資格情報を自動的に暗号化するわけではない。RFC 4954は、十分な保護がない状態で平文型メカニズムを広告しないことを求め、STARTTLS後のEHLOではメカニズム一覧が変わり得ると定めた。「AUTH対応」は固定の一ビットではなく、TLS状態、証明書、クライアントの降格耐性によって安全な選択肢が変わる。

RFC 8314は後に、メール投稿・アクセスの平文を過去のものとし、587上のSTARTTLSと465上の暗黙TLSを位置付けた。暗号化が守るのは資格情報交換とその一ホップであり、本文に対するエンドツーエンド署名ではない。

AUTH=は不明を消さない

RFC 4954のMAIL FROMにはAUTH=パラメーターがあり、主張された元の投稿者を次のサーバーへ渡せる。ただし、信頼できる形で主体を決められないならAUTH=<>を使う。空欄を自分の名前で埋める規則ではない。

これは証拠の由来を保つ。どのホップが認証し、どこが転記しただけかを区別できなければならない。RFC 3848のESMTPAとESMTPSAも、受信した一ホップで認証、または認証とTLSが使われたことを示すにすぎない。経路全体も著者も保証しない。

SMTP AUTHの強さは、ログイン成功が署名より小さいことにある。入口を開き、方針を選び、監査可能な一ホップの証拠を残せる。一方で、送信者フィールド、人間の意図、本文、後続中継を勝手に認証しない。

出典