IIJ技術陣「spamからメールを守れ（管理者編）」

2006年2月27日
櫻庭秀次
ユーザ編はこちら＞＞

　2005年3月にJEAG（Japan Email Anti-Abuse Group）が発足した。テーマごとにつくられたサブワーキンググループ（SWG）でそれぞれ活動しており、本コラムで取り上げている送信ドメイン認証技術もJEAG SWGの一つとなっている。またOP25B SWGでは、より即効性の高い技術として注目されている「OP25B」（Outbound Port 25 Blocking）技術について検討している。OP25Bの有効性が導入企業から紹介されたり、実施方法が活発に議論され、その結果実際に導入するISPが増えるようになってきた。

　spamの動向を調べている私の携帯電話はその動きを顕著に示している。従来、spam発信元として多かったISPのA社からは、OP25B導入後はspamがまったく来なくなった。代わりにISP B社からのspamが増え、その後B社もOP25Bを導入したことによりC社からと、spam送信者がISPを渡り歩いている様子が手にとるようにわかる。

　同様の傾向が日本データ通信協会の報告にも示されている。

　多くのISPは、導入の容易性とその効果の大きさから、携帯電話宛限定でOP25Bを導入しているところが多く、実際に効果をあげている。こういった対策が広がって今後携帯電話宛のspamが送れなくなった場合、PCなどで使われる通常のメールアドレスへのspamが増えるような気がしている。手を休めることなく、対策を続けるべきだろう。前回は、SPF/Sender IDの歴史と概要について触れた。今回は、実際に送信ドメイン認証をSPFで行う場合の方法について述べる。設定例にはsendmailを、それに対する機能追加には「Milter」（sendmail Mail Filter API）を利用する。

　sendmailは、その難解な設定ファイル（sendmail.cf）で一般には敬遠されがちだが、一方、そのルールセットや外部マップは強力で一部の人には根強い人気がある。バージョン8.10から試験的に導入されたMilter機構は、8.12では標準として組み込まれるようになり、それを利用したMilterアプリケーションも増えつつある（http://www.milter.org）。

　Milterアプリケーションは、sendmailに付属のライブラリ（libmilter）をリンクした独立したアプリケーションとして作成される。構造は簡単で、コールバックと呼ばれる機能群をAPIを通して登録することにより、これらがsendmailからSMTP（Simple Mail Transfer Protocol）の各コマンドのタイミングで呼び出される、という仕組みである。sendmailとMilterアプリケーションは、ソケットインタフェースで通信するため、それぞれの動作ホストを分離することも可能だし、複数のsendmailからの要求を単一のMilterアプリケーションで処理することも、またその逆も可能だ。sendmail側にはあらかじめ通信を行うMilter側の情報を設定する必要がある。

　Milterアプリケーションは、接続元情報やSMTPコマンドの引数 （エンベロープ情報）、メール本体などさまざまな情報が得られる。一方Milterアプリケーションからsendmail側へのはたらきかけとしては、以下のことが可能となっている。

・SMTP上の応答コード（REJECTやDISCARD、TEMPFAILなど）の指定
・ヘッダ情報の修正や削除、追加
・配送上の宛先の削除や追加
・本文の入れ換え

　これらの機能を使えば、メールの内容を調べてspamかどうかを判定し、接続を拒否する、といったことも技術的には可能だ。SPFの認証処理では、接続元IPアドレスと、エンベロープFrom情報が必要なので、Milterで十分に機能が実現できる。

　SPF認証処理のためのMilterアプリケーションとしては、「sid-milter」が有名だ。開発を主導しているのはSendmail社のKucherawy氏で、SPFだけでなくSenderID（のPRA部分）の認証機能もサポートしている。sid-milterの導入方法については、IAjapanのポータルサイトなどすでに情報があるので、今回は別の視点としてlibspfとそれを利用したspfmilterの導入方法について解説する。