前回の「“Winny遮断はISPの産業革命”を受けて---OP25Bは必要か(前編)」では,スパム対策の歴史を振り返りながら,ISP(インターネット接続事業者)がなぜ,電子メールを送受信(中継)する25番ポートを遮断する「Outbound Port 25 Blocking(OP25B)」を実施するようになったのか,について書いた。OP25B誕生の背景には,これまでスパム対策として有効だった「第三者中継の禁止」という手法が,現在では何の効果も発揮しなくなったという状況がある。

 記者個人は,ポートを遮断するOP25Bは好きにはなれない。スパム対策は,メールを受け取るメール・サーバーのアプリケーションの問題であって,送信側がルーターなどを使ってネットワークのレイヤーで片付ける問題ではないからである。

 そこで今回は,ISPがOP25Bを運用するために採っている方策について触れるとともに,OP25Bを使わずに済ませる方法を模索してみる。記者個人は,実現可能性はさて置き,メール・サーバーの認証が広がることでOP25Bを使わずに済むのではないかと考えている。

25番ポートを別のポートで代替する

 前回も触れたように,ISPがOP25Bを採用して25番ポートを遮断しても,代替ポートが用意されているため,実用上は何の問題も生じない。25番ポートの代替となるポートを「Submissionポート」と呼び,標準では587番ポートを使う。Submissionは,ネットワークからネットワークへメールを中継するMTA(Mail Transfer Agent)の機能と,メール・サーバー自身やメーラーからネットワークへメールを送信するMSP/MSA(Message Submission Program/Agent)の機能を分離するものである。RFC2476「Message Submission」に詳しく書かれている。

 Submissionをメール・サーバーに実装することで,他のメール・サーバーからのSMTP中継の要求は従来通り25番ポートで受け付け,メーラーからのSMTP中継の要求はSubmissionポート(587番)で受け付ける,という運用が可能になる。つまり,メールをSMTPで送ってくるSMTPクライアントがメール・サーバーなのかメーラーなのかを,ポート番号の違いで区別できる,ということだ。

 通信相手を判別できると,嬉しいことがある。メール・サーバーから見れば,ポート587番に接続してくるSMTPクライアントはメーラーであると判断しても構わないため,あとは接続を許可すべき正規のユーザーかどうかを認証すればよい。認証を通ったら,SMTPでのメール中継を許可することになる。認証には標準で,たいていのメール・サーバーとメーラーから利用可能なSMTP_AUTHを用いるのが通例だ。

 スパム送信者を契約ユーザーの中から出したくないISPからすれば,ユーザー が外部のメール・サーバーにメールをSMTPで送出する際には587番ポートを使っ てもらい,スパム送信に使われる25番ポートは閉じてしまえばよい。25番ポートを使ってメールを外部に送信できるのは,ISPが管理しているメール・サーバーだけにする,というわけだ。なお,ISPのメール・サーバーにメール中継を依頼する場合にも587番ポートとユーザー認証が使われる。

ユーザー認証は例外的な第三者中継のためにあった

 実は,587番ポートに接続してくるメーラーに対して行うユーザー認証は,歴史的に見れば,例外的に第三者中継を許可するために使われてきたものだ。例えば,ユーザーが社内LANから,個人で契約したISPのメール・サーバーを経由してメールをインターネットに出す場合(現在の多くの企業はファイアウォールでブロックしている)がこれに当たる。公衆無線LANのアクセス・ポイントやインターネット・カフェからメールを出す,という需要もある。こうした需要に応え,本来は外部のネットワークであるにも関わらず,あたかも自社のネットワークであるかのように運用するわけだ。

 つまり,本来であれば第三者中継に相当するためにメールを出せなくなるケースにおいて,例外的に第三者中継を許可するための手法が,ユーザー認証だったのである。例えば,POP Before SMTPと呼ぶ手法では,POP3によるユーザー認証を経たIPアドレスを,10分間などの短時間に限ってローカル・ネットワークと見なす。それが,Submissionポートによってメール・サーバーとメーラーを区別できるようになったことで,ユーザー認証をメーラーの認証として応用できるようになったというわけである。

サーバー認証は果たして広まるか

 だがしかし,OP25Bはネットワークのレイヤーを用いた苦肉の策である。25番ポートでSMTP接続してくるSMTPクライアントがメール・サーバーなのかメーラーなのかを,アプリケーションのレイヤーでは判別できない,という根源の問題が解決されたわけではない。

 そこで記者個人は,昨今の電子メールの世界においてホットな話題であるサーバー認証の可能性を考えてみたい。メール・サーバー認証が一般化すれば,25番を閉じることなくSMTPクライアントを認証できるからである。

 メール・サーバー認証とは,SMTPクライアントを信用してよいかどうかを調べる機構である。ざっとサーバー認証の仕様の例を挙げると,まず(1)米Microsoftが開発した「CallerID for E-Mail」,(2)米Yahoo!と米Sendmailが開発した「DomainKeys」が生まれた。現在では(3)CallerID for E-Mailと「SPF」(Sender Policy Framework)をまとめた「Sender-ID」が広まっており,最新の手法としては(4)DomainKeysと「Identified Internet Mail」を統合した「DomainKeys Identified Mail」(DKIM)が注目されている。Sender-IDとDomainKeysがどれだけ世界で使われているのかは,米CipherTrustが公開しているサイト「TrustedSource Portal」が詳しい。

 Sender-IDは,「MAIL_FROM」と「From:ヘッダー」のドメインをDNS(Domain Name System)で調べ,IPアドレスによる認証を施す手法である。一方のDKIMは,メールのヘッダーに電子署名を付与し,署名を検証するために必要な公開鍵をDNSに登録する,というものだ。

 いずれの手法を使う場合でも,メールを送信する側のメール・サーバーがサーバー認証に対応するのは容易である。Sender-IDであればDNSに情報を追加すればよく,DKIMであれば,DNSへの情報追加に加えて,メール・サーバーに電子署名機能を追加すればよい。

 サーバー認証の問題点は,メール送信者側のメール・サーバーではなく,メール受信者側のメール・サーバーの運用ポリシーにある。認証できない相手からのメールをどう扱うか,という問題である。メールを送ってきた相手が既知の取引先であればあらかじめホワイト・リストに登録しておくことで対処できるが,サーバー認証に対応していないメール・サーバーからのメールを一律に拒否するといった運用は,ビジネスの世界では困難だろう。

 とはいえ,第三者中継を許可するサーバーのリストであるDNSblを用いたアクセス拒否が存在するように,サーバー認証に基付いたメール受信側でのアクセス制御も広まるかも知れない。サーバーの認証はOP25Bと比べたら美しいと思う。記者個人の希望的観測ではあるが,広まって欲しいと切に願う。

Submissionはルート権限の奪取を防止

 最後に本論のテーマからは外れるが,OP25Bを運用するために必須であり,サーバー間認証においても必要度が高いSubmissionにも注目しておきたい。現在,Submissionは世間ではあまり知られていないのではないかと記者は推測する。記者個人はISPが25番ポートを遮断するOP25Bの運用には反対だが,実はSubmissionポートの利用には大賛成である。むしろ,Submissionを広めたくてウズウズしていると言ってもいい。

 記者個人は趣味でドメインを取得し,DNSサーバーとメール・サーバーを運用している。過去に,愛用しているメール・サーバー・ソフトの「Sendmail」を8.11から8.12へとバージョン・アップした際,かなり戸惑った。その理由は,記者個人がSubmissionに対して無知だったからである。Sendmailは,8.12からSubmissionを実装したが,8.11を運用している時には,恥ずかしい話だが,記者はSubmissionの名前も聞いたことがなかった。

 ルート権限(管理者権限)で動作させる1個の常駐ソフト(daemon)で機能のすべてをまかなっていた従来のSendmailと異なり,最新のSendmailではSubmissionによって,可能な限りルート権限を使わずに運用できるようになった。これはSubmissionの大きな功績であり,思わず「Submission万歳」と叫んだものだ。

 Sendmailの配布パッケージに含まれる文書「./sendmail/SECURITY」によれば,sendmailプログラムがルート権限を使ってOSに対して振る舞う作業は,以下の通りである。(1)TCPポート25番にバインドする,(2)自分のコンピュータ上にあるユーザーあてに配送する(ファイル・コピー),(3)個々のユーザーにしか読めない転送設定ファイル(.forward)を読む,(4)メーラーや自身のコンピュータからの送信メールをキューに格納する。

 このうち(4)自身のコンピュータからの送信メールをキューに格納する作業は,従来のSendmailであれば,ユーザーにルート権限を与える(setuid root)ことで実現していたもの。一方,Submission以降のSendmailでは,(4)の機能,すなわちMSP/MSA機能をsendmail内部で分離することで,ルート権限をその都度与えなくてよいようにした。キューを格納する領域(clientmqueue)を特定ユーザー(smmsp)または特定グループ(smmsp)だけが書けるようにすれば,その都度ルート権限を与える必要はないからだ。こうして,MSPとしてsendmailを実行する際には,ユーザーにグループ権限(setgid smmsp)を与えるようになったのである。