過去にもspamassassin（その頃は2.x）導入やpopfileのサーバへのインストールなど、数々のスパム（含むウイルスメール）との死闘を繰り広げ、popfileによるフィルタリング＋rblをメールサーバに設定、でなんとか普通に（人間が）対処できるところまでもってきたのですが、このたびrbl.jpのボランティアとしてrblの生成に協力する、という形で攻勢に出ることにしました。
参考→IT用語辞典 e-Words ： MAPS RBLとは 【Mail Abuse Protection System Realtime Blackhole List】
……というわけで、弊社では株式会社スタジオ・ポットほか、いくつかのサイトをメールサーバ込みで管理しているので、メールが届くたびにこのrblを参照しては問題のあるホストからの送信であればその段階で拒絶、という処置を取れるのです。すでにクライアントサイドではpopfile、Mail.app、Thunderbirdなどで武装しているのですが、水際で叩く（トラフィック減）、ということと、スパム防御について数よりも質を追求している、ということ、そして対策の成果を単独ホストではなく、複数の（かなり多くの）サイトで共有できる、ということでかなり注目の技術ではあります。
で、rbl.jpなんですが、実は前から利用していました。しかし、たびたびウイルスメールがサイトめがけて着信し、ウイルススキャナで弾く通数が増えてくると、利用者にいちいち「これはポット宛に来たウイルスメールをスキャナが弾いた報告メールなんですよ」と説明しなければならず、そろそろ「元から断つ」アプローチを取らないとなあ、と思い始め、最近あらためてrbl.jpが何をやってくれているのかを見直したわけです。（以下、技術的なレベルとしては他愛もないことですが、今回のエントリは有志募集の意味もあるので細かく書きます。）
現在、主流となっているスパムメール撃退方法は（私の理解では）以下のように分類されます。
- メールクライアントでの、学習型のフィルタによる防御（Thunderbirdのjunk filter機能など。プラグインの形で実装されることもある）
- プロキシに学習型のフィルタを置いて防御（Popfileなど。ちなみにフツーは各自のPCでpopfileを走らせるのが普通ですが、ポットではpopfileをメールサーバ側に置いて、みんなでそこにつないで利用しています）
- メールサーバにフィルタを置いて防御（SpamAssassinなど。スパムに含まれる単語を解析して学習していくことによる「ベイジアン」タイプのフィルタを実装しているものが主流のようです。
この手のサーバ常駐型は、UNIXへのログインを常態としている環境でない限り、「フィルタへの学習」の指示に難がある、と私は考えており、現在は採用していません（性能の問題ではなく、単なるインターフェースの問題なんですが。）。
- サーバにおける、ホワイトリスト／ブラックリストによる防御
- スパム発信元を特定し、プロバイダに通報
- スパム発信元に（メールを返信する、受信拒否を伝える等）直接拒否の意志を伝える
で、今回話題にしている対策は、4のヴァリアントです。一昔前は、自分のサーバにブラックリストのアドレスを書いていく、という方法がよく紹介されていましたが、ポットのサイトに来るスパム（ウイルス含む）メールの数は100〜200通／日（これでもrblで120通／日は弾いている）です。いちいち手で追加していたら仕事になりません。また、最近は常時接続しているPCをゾンビ化して送る、というすげー腹立たしいケースがかなりあります（60%はゾンビ経由だそうで）。これらのアドレスを未来永劫ブラックリスト扱いしていると、次にそのipアドレスを割り当てられた人からのメールは受信できなくなります。というわけで、rbl.jpは「常時接続系からのスパムメール用の、短期保有型ブラックリスト」と、「ウイルス送信マシンブラックリスト」の二つを保有しているのです。
話を戻しますと、そんなこんなでrbl.jpは常にこの二つのリストのメンテナーの参加を募っています。で、ワタシはこのメンテ作業に参加するという形でスパムに立ち向かうことにしました。（rbl.jpの、登録ボランティア募集についての記述はこちらから。）メンテ要員への参加は、正直、ちょっと敷居が高い感じはするんですが、メールヘッダの読み方にさえ慣れてしまえば大したことはありません。ここでは、背景まで立ち入った説明は極力省いて、どのような作業で発信元を特定できるか（rbl.jpボランティアの参加条件をクリアできるか）、ということを解説します。
まず、スパムが着信したらメールのヘッダを確認します。
Return-Path:X-Original-To: xxxxxxxxxx@pot.co.jp Delivered-To: xxxxxxxxxx@pot.co.jp Received: from localhost (localhost [127.0.0.1]) by mail.pot.co.jp (Postfix) with ESMTP id 6F47B9202D9; Wed, 14 Sep 2005 10:30:41 +0900 (JST) Received: from mail.pot.co.jp ([127.0.0.1]) by localhost (mail.pot.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25381-04; Wed, 14 Sep 2005 10:30:32 +0900 (JST) Received: from 66.148.250.26.nw.nuvox.net (66.148.250.26.nw.nuvox.net [66.148.250.26]) by mail.pot.co.jp (Postfix) with SMTP id F3B549203A5; Wed, 14 Sep 2005 10:30:29 +0900 (JST) Received: from arbt..com (bmnm..com [.54]) by netscape.com (8.3.5/5.7.5) with ESMTP id KAA49426 for ; Wed, 14 Sep 2005 12:31:45 -0600 Message-ID: <57929969.986JVTDJ@hotmail.com> Date: Wed, 14 Sep 2005 13:27:45 -0500 From: "Adele Dewitt" Subject: Proposed charter MIME-Version: 1.0 To: xxxxxxxxxxxxxxx@pot.co.jp Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-UIDL: P`*#!FPS"!>LB!!Yl>"!
いろいろありますが、見るべきは「Received:」で始まるヘッダのみ。ここは、自分の手元に届くまでの経路が記録されている部分です。で、発信源として特定できるのは太字になっている行です。つまり、外のネットワークから自分の（自社の、自分のプロバイダの）ネットワークに入ってきたところが問題になっているわけです（これより下のReceived:ヘッダは偽装されている可能性があるそうです）。ここでは、
66.148.250.26.nw.nuvox.net [66.148.250.26]
ですね。（「66.148.250.26.nw.nuvox.net 」がホスト名で、「66.148.250.26」がIPアドレスです。念のため）
一昔前の拒絶手法は、このようなホストを「自前で」ブラックリスト化し、受信を拒絶する、という方法でした。RBLというのは要するにこのように「スパム／ウイルス」を発信しているホストのリストをネット上で共有して、メンテ／利用しましょう、ということなんです。
で、このリストを日本で運営しているのは（たぶん）rbl.jpだけです。そして、ここは上記のような作業をして、rbl.jpのRBLデータベースに「通報」してくれる人材を募集しています。応募条件は、ずばり「上記のような作業をできる人」です。ちょっと試験みたいでドキドキしますが、とにかくこのボランティアをやっている人は、世界に30人しかいないんです（ボランティア専用MLで参加人数を確認して、正直、たまげました）。たぶん、人手が足りていません。求む若い力（ウソ。スパムメールのアンフェアさに対する怒りと最低限のネットリテラシのある人ならどなたでも）。応簿はrbl.jpのページをご覧ください。この呼びかけそのものに関しての質問は有限会社スタジオ・ポットSD・日高まで。（私が勝手にやってることなんで……。）
[2005-10-24追記]
ボランティア、31名になってました。「ヘッダ見て、IPをWebフォームに書き込むだけ」の作業なんですけどね……。そもそもメールサーバを管理している知り合い自体が皆無ではあるんですが、どうも参加呼びかけしづらいのはなんでなんだろう。ウイルスに関してはclamAVが判定したら自動通知、という仕組みを運用開始したんですかさず乗っからせてもらったんですが、スパム系も「スパムメールをヘッダごとアドレス○○に転送したら、その中の問題のipアドレスをrblのDBに自動追加」みたいな仕組みがあればいいのかなあ。。
