要約

  • 1982年のSMTPでは、受信サーバーが次の宛先までの中継を引き受け、次の区間では送信サーバーになれた。
  • 1999年のRFC 2505は無断中継を拒める能力をMTAに求め、偽装しやすいHELOとMAIL FROMを認可の根拠から外した。

タクシー乗り場に荷物を抱えた客が来る。「私は社長です」と名乗り、遠い町まで運んでほしいと言う。車の所有者は客の名前を聞いただけで発車させ、燃料代と苦情を引き受ける。1990年代末の開放型メール中継には、そんな困った親切があった。

中継そのものは、インターネットのメールをつなぐ正当な作業だ。1982年8月のRFC 821では、受信側SMTPサーバーは別のサーバーへ運ぶ仕事を受けても断ってもよい。引き受ければ、次の区間では自ら送信側になる。文書は宛先のメールボックスとそこまでの経路も区別した。複数のシステムをまたいで届けるには、途中の受け渡しが役に立った。

争点は、その受け渡しを誰が命じられるかに移った。1999年2月のRFC 2505はBest Current Practice 30として、無断の中継利用がサーバーの資源を使い、運営者の評判も傷つけると述べた。MTAはその利用を制御し、拒めなければならない。運送業を廃止する指示ではない。誰の荷物をどこへ運ぶ契約があるのかを、出発前に確かめる指示だ。

RFCはSMTPの会話に現れる四つの材料を並べ、信用度の差を示した。HELOに書かれたホスト名は接続者の自称で、偽装しやすい。MAIL FROMの差出人も同様だ。RCPT TOは送ろうとしている先を示し、サーバーには接続者の送信元IPアドレスも見える。最初の二つで中継を許してしまえば、客が自分で書いた名札を配車証にすることになる。

推奨された判断は運営者自身の責任範囲に沿う。宛先が自分の扱うドメイン、または引き受けている転送先なら受け入れる。接続者がIPアドレスか、DNSを信頼できる範囲でのホスト名によって許可されていれば中継する。それ以外は断る。短い規則だが、サーバーの容量と信用を誰が使えるかを、自称ではなく運営上の約束で決める。

ただし、宛先の読み取りには古い郵便路の抜け道があった。RFC 2505は@a,@b:のソースルート、%を使う書き方、UUCP型の!経路を挙げる。表面上は自分宛てに見えるアドレスが、実際にはさらに先への中継を要求する可能性がある。同時に、正当なゲートウェイにも特殊な宛名があった。規制の前に既存の経路を棚卸しする必要がある、と文書は述べる。住所を読めない門番は、詐称者を通し、常連客を追い返す。

同じ年の六月に出たRFC 2635『DON'T SPEW』は、接続事業者にも仕事を割り振った。見知らぬ利用者に開放された中継を閉じ、利用規約を明示し、アカウントの悪用を確認してから措置を取り、abuseやpostmaster宛ての訴えを人が読む。ソフトウェアで閉じる門と、苦情を受ける窓口は別々に要る。機械が一通を拒むとしても、その理由と影響を扱うのは組織だ。

2008年のRFC 5321には、なお残る難題が刻まれた。メールには、届けるか、失敗を返すかという長い期待がある。一方で大量の迷惑メールは選別や拒否を現実の運用にした。黙って消す処理は配達への信頼を損なう。中継を誰に許すかという門の判断と、預かった郵便の結末をどう知らせるかは、別の責任である。

メールサーバーはその後も正当な手紙を運ぶ。変わったのは乗車券の発行者だ。HELOで元気に挨拶しても、客自身が車の所有者に代わって運行許可証を書くことはできない。1999年の規則は、その当たり前をネットワークの入口に置いた。