水曜日, 11月 29, 2006

偽陽性率

 S25R方式の偽陽性率をどう評価しようかと考えた末に、正当な受信メールの送信元ホストを拾い上げてみた。2006年1月以降、11月28日までに受信したメールの送信元は142個。そのうち、S25Rの一般規則に引っかかるホストは19個だった。ここから計算した、ホワイトリストがないものと仮定した偽陽性率は13.4%である。意外な高さに今さらながら驚いた。
 とはいえ、偽陽性率の高さに手を焼いているわけではまったくない。1サイトのメールマガジンを受信し損ねたことがある(8月30日「リトライを短時間でやめるサーバ」)のを除いて、以前から登録してあったホワイトリスト、新たに登録したホワイトリスト、および協力者から報告されたホワイトリストのおかげで、苦もなく受信に成功している(もちろん、メールトラフィックが少ない個人サイトだから苦労がないのだが)。正規表現によるホワイトリスト登録1件で複数のホストを救済するケースもあり、19個のホストを救済したホワイトリスト項目は14件であった。
 一方、9月15日「宛先の正しいスパムの阻止率」で報告したとおり、2006年7月の統計では、宛先の正しいスパムの阻止率はトータルで97.4%であった。すなわち、偽陰性率(見逃し率)は2.6%である。
 スパム判定においては、偽陰性判定よりも偽陽性判定の方が有害である。スパムの阻止に失敗するよりも、正当なメールを受けられないことの方が困る。では、偽陰性率よりも偽陽性率の方が高いS25R方式は有害な方式か。決してそんなことはない。
 S25R方式では、偽陽性判定は致命的なものではなく、リトライアクセスを発見してホワイトリスト登録すればメールを受信することができる。そして、そのホストからのメールを阻止することは二度となくなる。ホワイトリスト登録が進むにつれて、偽陽性率はゼロに近付いていく。
 偽陰性率は初めから十分に低い。メールの90%以上はスパムだと言われる現在、偽陰性率の低さはやはり重要である。そして、偽陽性率は、ホワイトリスト登録によって(素のS25R方式ではそのために労力はかかるものの)どんどん下がっていく。偽陽性を減らすために偽陰性率の低さを犠牲にする必要がない。つまり、スパム対策方式としての実用性が高いのである。このことこそ、S25R方式が多くの人々に支持されている理由に違いない。

日曜日, 11月 26, 2006

DNSWLはいかが?

 S25R方式は、スパムの阻止率が高い代わりに、組織サイトでは初めのうち偽陽性判定が多い。500~1000件のホワイトリスト登録が必要だと聞く。それなら、ホワイトリストデータベースを共有するようにすれば運用が楽になるのではないかという発想が出てくる。
 そこで、DNSBLならぬDNSWL(DNS White List)というものが世の中にあるかどうかと思って、何気なく検索してみた。すると、そのものずばりのサイトがあった。dnswl.orgである。そのホームページにはこう説明されている(誤訳があったらご指摘ください)。

dnswl.orgとは?
 dnswl.orgは、善良とわかっている送信元のIPアドレスのリストを提供します。このデータは、これらの送信元からのメールがスパムフィルタに偶然つかまったり、偶発的あるいは誤った阻止リスト登録によって阻止されたりしないことを保証するために使うことができます。
 このリストは、メール管理者やスパムフィルタ管理者がホワイトリストを手動で保守する労力を最小化するのに役立ちます。dnswl.orgは共同作業です。つまり、善良な送信元を識別するのに皆さんの援助が必要です。また、リストにある送信元の一つが善良でないとわかったら、知らせてください。
 データは複数のカテゴリー(財団やその他の大企業、インターネット/メールサービスプロバイダなど)について入手でき、各項目は「低」、「中」、「高」に点数付けされています。各管理者は、これらの点数をどう適用するかについて自分自身のルールを選ぶことができます。
 このリストは、DNSによって、また、いくつかのダウンロードフォーマット(プレーンテキスト、rbldnsdフォーマットテキスト、コメント付きテキスト)で提供されます。

 DNSBLよりも役に立つかもしれない。
 ただし、おそらく、S25R方式の導入サイトがすぐに使えるものではない。S25R方式特有のルールによって阻止されるホストがかなりあるからである。S25R方式の導入サイト(それも、かなりの規模の組織サイト)の誰かがボランティアでデータを提供する必要がある。
 また、これが広く使われるようになると、スパマーがスパム送信コンピュータをホワイトリスト登録するおそれがある。悪意ある者によってデータが汚されるのは、ブラックリストにせよホワイトリストにせよ、不特定の人々の共同作業で作るデータベースではどうしても生じるリスクである。

金曜日, 11月 24, 2006

DNSBLの利用価値はあるか?

 「IPアドレスを手がかりにしてスパム判定するなら、すでにDNSBLがあるではないか」と言う人がいる。しかし私は、S25R方式の方が使いやすいと思う。
 DNSBLは、スパム送信の前科のあるIPアドレスをブラックリストに登録する。しかし、前科がなくても、悪意のないインターネットユーザーのPCがウィルス感染でゾンビ化してスパムの送信元になるおそれがある。ゾンビPCが次から次へと生まれれば、ブラックリスト登録は後追いになる。S25R方式なら、前科の有無にかかわらず、エンドユーザー回線からと推定されるSMTPアクセスに対して一時的拒否応答を返すので、かなりの確度でスパムやウィルスメールを阻止することができる。
 また、DNSBLでは、正当なメールサーバがスパム送信元の巻き添えを食らってブラックリストに登録されてしまうことがある。そのため、今まで届いていたメールが突然拒否されるようになるおそれがある。ブラックリストのデータが古いままで、あるいはデータベースのトラブルでデータが過去に巻き戻ってしまって、無実のメールサーバを拒絶することもあると聞く。S25R方式ではそのような心配はない。拒否や許可のルールはローカルな設定で決めるからである。初めてメールを送ってくる正当なメールサーバを誤って蹴ってしまうことはあるが、再送アクセスが来ている間にホワイトリスト登録した後は、二度と蹴ることはなくなる。
 S25R方式にDNSBLを併用するという方法はどうだろうか。併用の方法には、阻止率を上げる(偽陰性を減らす)ためと、偽陽性を減らすための二通りの方法が考えられる。
 阻止率を上げるためにDNSBLを併用するには、S25Rの阻止条件に引っかからなかったホストをDNSBL検査にかけることになる。しかし、これはあまり効果がないと思う。S25Rをすり抜けるスパムには、ISPのメールサーバを経由したものや、一時的に乗っ取られたサーバから送信されたと思われるものが多い。私のサイトでの観測では、サーバっぽい逆引き名の同じホストから繰り返しスパムが来たことはほとんどない。DNSBLに頼っても、阻止率は、S25Rによる阻止率(全不正メールアクセスについて99%、宛先の正しいスパムについて97%)よりもさらに大きく向上することはないだろう。むしろ、ISPのメールサーバや、乗っ取られた後に対処されたサーバがDNSBLに残り、偽陽性が増えるおそれがある。
 偽陽性を減らすためにDNSBLを併用するには、S25Rの阻止条件に引っかかったホストをDNSBL検査にかけて、それに引っかからなかったホストを許可することになる。この方法では、ゾンビ化したばかりのPCからのスパムを受けてしまうおそれがある。定量的評価はしていないが、阻止率はかなり下がってしまうのではないかと思う。
 結局のところ、DNSBLを使う積極的な理由は見出せない。「S25R+グレイリスティングという対策をとっていれば、今さらDNSBLを使う必要は感じない」と言う人もいる。私もそう思う。

木曜日, 11月 23, 2006

訳語

 「false positive」に「偽陽性」、「false negative」に「偽陰性」という訳語があることを知った。元々は医学用語で、病気がないのに病気の反応が出るのが偽陽性、病気なのに反応が出ないのが偽陰性である。医療では偽陰性の方が危ないが、スパム判定では偽陽性の方が危ない。
 せっかく訳語があるのだから、使うことにしよう。
 ついでに言うと、この場合の「positive」「negative」は可算名詞であり、英作文では単数なら不定冠詞「a」、複数なら語尾「s」を付ける必要がある。

土曜日, 11月 18, 2006

Debian whitelister

 佐藤さんからの情報。DNSBLに引っかかったホストをグレイリスティングに回すのは、Debianのwhitelisterというパッケージでできるそうである。

木曜日, 11月 09, 2006

maps_rbl_reject_code

 Postfixのsample-smtpd.cfファイルに次のような記述を見つけた。

# The maps_rbl_reject_code parameter specifies the SMTP server response
# when an SMTP client request is blocked by a reject_rbl or reject_rhsbl
# restriction.
#
# Do not change this unless you have a complete understanding of RFC 821.
#
maps_rbl_reject_code = 550

デフォルトの応答コードは「550」だと読み取れるが、実際のデフォルト値をpostconfコマンドで調べてみたら…

$ postconf | grep maps_rbl_reject_code
maps_rbl_reject_code = 554

 前回の記事「「5xx」で蹴るなんて」で、DNSBLを全面的に信頼して「5xx」で蹴ることが信じられないと書いたが、なんとその元凶はPostfixのデフォルト値だった。
 PostfixでDNSBLを利用している人は、ぜひmain.cfファイルに

maps_rbl_reject_code = 450

を追記してほしい。sample-smtpd.cfファイルには「RFC 821を完全に理解していない限り変えるな」と書いてあるが、びびることはない。
 もちろん、まめにログを監視して、正当なメールサーバからのリトライアクセスを発見したらホワイトリスト登録するように運用すべきである。リトライアクセスを発見しやすくするためには、私の拒絶ログソーティングスクリプトが使える。あるいは、グレイリスティングに回してもよいが、どうやればよいのかは知らない。

火曜日, 11月 07, 2006

「5xx」で蹴るなんて

 S25R方式でメールを蹴られて困っている人がいるという情報(10月29日「大手ISPに導入されたらしいが…」)を佐藤さんから聞いたきっかけは、佐藤さんが運用するサイトがSpamhausのDNSBLに登録されてしまったという事件だった。もちろん佐藤さんのサイトがスパムを発信するわけはないのだが、近隣のIPアドレスからスパムが発信されたため、巻き添えをくらってネットマスク22ビット(1024個ブロック)で登録されてしまったらしい。そのため、佐藤さんのサイトからのメールが、Spamhausを利用しているサイトで受信拒否されてしまったのである。
 何の応答コードで蹴られたかと質問したら、「5xx」だったと聞いてびっくりした。なぜそこまで他人のデータベースを信用できるのだろうか。今回のSpamhausのように、多数のIPアドレスからスパムが発信されたら、それらを含むIPアドレスブロックをまとめてリストに登録してしまうケースもある。ましてDNSBLは、登録されたIPアドレスからスパムしか発信されないと保証しているわけではない。DNSBLに登録されたIPアドレスから正当なメールが送信されることもありうるということを考慮すべきである。
 DNSBLの情報に基づいてアクセスを蹴るなら、「4xx」を返して様子を見るべきである。さもないと、他サイトの善良な送信者を困らせるし、そのメールを受信するはずだった自サイトの受信者にも不利益をこうむらせることになる。
 S25R方式のコンセプトで重要なことは、送信元のIPアドレスの逆引き結果に基づいて不正メールアクセスの疑いを推定するが、あくまでも推定であって、決して確信しないということである。だから、誤って阻止される正当なメールを救済する余地を残すために、応答コード「450」を返すのである(企業や学校でポルノサイトからのスパムを阻止するような場合はこの限りではないが)。
 S25R方式に対して、個人サイトを排除するやり方だという批判がいまだにあるが、S25R方式のコンセプトは決してそのようなものではない。私は、ダイナミックIPアドレスの個人サーバから直接送信するのはやめてほしい、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えてほしいと主張してはいる(論文および7月29日「個人サーバ」)。しかし、ダイナミックIPアドレスのサーバだからといって「5xx」を返すことを勧めてなどいない。実際私は、ダイナミックIPアドレスのサーバからのメールもホワイトリスト登録して受信している。
 S25R方式は正当なメールを排除するという批判は誤りである。批判されるべきは、スパムの受信が減ったことで満足してしまって、正当なメールを拒絶する副作用のリスクを省みないという、間違った運用である。それは、S25R方式を使うにせよDNSBLを使うにせよ、同じことである。

水曜日, 11月 01, 2006

Starpitが採用される

 佐藤さんのStarpitTCNWEBのメールサービスに採用された。すばらしい!