勤務先では31日間に535通のスパムを受けた(9月23日「Becky!でのフィルタリング」)。一方、自宅サイトでもし対策をしていなければ受けてしまったであろうスパムは、35日間で370通と推計された(8月26日「通数で計った阻止率」)。31日間あたりに換算すると328通で、勤務先でのスパムの受信数の61%しかない。自宅サイトでスパムに狙われているアドレスは「deo」(個人アドレス)と「webmaster」の二つである。これらを合算しても、自宅サイトでスパム対策を解除したら受けるであろうスパムの量は、勤務先で一つのアドレスに届いているスパムより少ないのである。
勤務先のアドレスがスパマーに知られたのは、whoisデータベースからと考えられる。勤務先のドメインの管理者を務めていたことがあるからである。今は仕事が変わったので、whoisデータベースに私のアドレスはない。このこと以外に、勤務先のアドレスを自らインターネットに露出させたことはない。一方、自宅のアドレス「deo」は、私が持つドメインの管理者のアドレスとして今もwhoisデータベースに露出している。また、「webmaster」は、私のウェブサイトに連絡先として掲載している。かつてはmailtoアンカーで掲載していたので、スパマーやウィルスに拾われやすかった(今はmailtoアンカーをやめているが)。
他人のPCのウィルス感染によって私のアドレスがスパマーに漏洩したという推理もできるが、そうだとしても、自宅のアドレスの方が漏洩のリスクが高いと思われる。私は会員200人ほどのメーリングリストを運用しており、会員のPCがウィルス感染したことは何度かあったからである。
どう考えても、自宅のアドレスの方が露出度が高い。それにもかかわらず、勤務先で受けるスパムよりも、自宅サイトの正しいアドレスに押し寄せるスパムの方が少ないのである。
理由は一つしか考えられない。勤務先ではスパム対策をしていなくて、自宅サイトではスパムをはね返していることである。やはりスパマーは、送達率に無頓着にスパムを投げまくる連中ばかりではないのだろう。おそらく一部のスパマーは、私のサイトにはどうにもスパムを送り込めないことを知って、私のアドレスをリストから削除しているのだろう。
私のサイトに押し寄せる、宛先の正しいスパムが少ないのは、拒否応答を返し続けていることの効果なのだと思う。受けてからフィルタリングする方法では、こうはいかない。送達には成功しているので、スパマーはいい気になってスパムを送り込み続けるに違いない。
拒否応答を返す方法には、時として正当なメールを遅延させるという副作用が伴うが、やむを得ない。悪人をシャットアウトするためには善人も検問を受けなければならないようなものである。
月曜日, 9月 25, 2006
簡易一般規則
前回(9月23日)紹介したBecky!用の簡易一般規則は、S25Rの6個の正規表現による一般規則に比べて効力がさほど劣らない振り分け条件を一つの正規表現として書いたものである。
なぜ一つの正規表現にしたのかというと、正当なメールをごみ箱行きから除外するための条件を追加しやすくするためである。たとえば、一般規則に引っかかる正当なメールのFromヘッダのドメイン名が「example1.co.jp」および「example2.ne.jp」である場合、Becky!では、一般規則の条件の下に「かつFromヘッダにexample1.co.jpがないとき、かつFromヘッダにexample2.ne.jpがないとき(…に、ごみ箱に振り分ける)」という具合に、除外条件を絞り込み条件として追加していく必要がある。一般規則を複数の正規表現で指定すると、除外条件をどの条件の下に追加すればよいのかがわかりにくかったり、複数の条件の下に同じ除外条件を追加しなければならなかったりすることがある。それを避けるために一つの正規表現にしたわけである。
簡易一般規則を作るにあたっては、S25R方式の一般規則のすべてのルールを盛り込もうとは欲張らず、ほどほど複雑すぎない正規表現で、ほどほど高い効果が得られるように工夫した。もしかしたら、Becky!での利用以外にも、フィルタリングスクリプトを組むのに役立つかもしれないと思ったので、参考のために解説を補足する。
from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp
この正規表現の各部分を以下に説明する。
.*\(
「Received: from 」に続くHELOアドレスから、それに続く「(」までを読み飛ばす。Postfixとsendmailが記録するReceivedヘッダでは、「(」の次から逆引き名が始まる。
「Received: from 」の直後に逆引き名が位置するフォーマットの場合(qmailの場合)は、この4文字を削除してください(ブラックリストの指定でも同様である)。
unknown
Postfixおよびqmailで、逆引きできなかった場合を引っかける。
sendmailの場合は不要である(削除しなくても支障はない)。
\[
sendmailでは、逆引きできなかった場合、「(」の直後の逆引き名が空になり、IPアドレスを囲む「[」が直後にいきなり位置する。その場合を引っかける。
Postfixおよびqmailの場合は不要である(削除しなくても支障はない)。
[0-9]
逆引きホスト名が数字で始まる場合を引っかける。すなわち、ルール3(逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる)の条件のサブセットである。
[^.]*[0-9][0-9][0-9][0-9][0-9]
逆引きホスト名に、5個以上連続する数字が含まれる場合を引っかける。すなわち、ルール2の条件である。
[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]
下線で示した部分は、随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介した時には「([a-z]|-)+」だけであった。ホスト名に、英字やハイフン1個以上で分断された数字列が2個以上含まれる場合を引っかける。すなわち、ルール1の条件である。
ところが、「h146.27.40.69.ip.alltel.net」のようなケースがけっこうすり抜けることがわかったので、数字列を分断するのは最初のドット1個でもよいという条件を付け加えた。ややトリッキーな書き方である。これで、ルール3で引っかかるものの一部がさらに引っかかるようになる。
ただし、これによって、「mx01.246.ne.jp」(実在するMXだが、メールを送信するかどうかはわからない)のようなケースが引っかかってしまう。S25Rのルール3は、このようなケースを引っかけないように上位3階層を検査から除外しているのだが、同じようにしようとすると正規表現が複雑化するので、やめた。レアケースだと思うので、かんべんしてください。
.*\(may be forged\)
sendmailで、逆引きのパラノイド検査が不適合になって、逆引き名とIPアドレスの次に「(may be forged)」と付記された場合を引っかける。
Postfixの場合は、パラノイド検査が不適合になった場合も逆引き失敗の場合と同じく「unknown」と表示されるので、不要である(削除しなくても支障はない)。qmailの場合は確かめていないが、多分不要だと思う。
なぜ一つの正規表現にしたのかというと、正当なメールをごみ箱行きから除外するための条件を追加しやすくするためである。たとえば、一般規則に引っかかる正当なメールのFromヘッダのドメイン名が「example1.co.jp」および「example2.ne.jp」である場合、Becky!では、一般規則の条件の下に「かつFromヘッダにexample1.co.jpがないとき、かつFromヘッダにexample2.ne.jpがないとき(…に、ごみ箱に振り分ける)」という具合に、除外条件を絞り込み条件として追加していく必要がある。一般規則を複数の正規表現で指定すると、除外条件をどの条件の下に追加すればよいのかがわかりにくかったり、複数の条件の下に同じ除外条件を追加しなければならなかったりすることがある。それを避けるために一つの正規表現にしたわけである。
簡易一般規則を作るにあたっては、S25R方式の一般規則のすべてのルールを盛り込もうとは欲張らず、ほどほど複雑すぎない正規表現で、ほどほど高い効果が得られるように工夫した。もしかしたら、Becky!での利用以外にも、フィルタリングスクリプトを組むのに役立つかもしれないと思ったので、参考のために解説を補足する。
from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp
この正規表現の各部分を以下に説明する。
.*\(
「Received: from 」に続くHELOアドレスから、それに続く「(」までを読み飛ばす。Postfixとsendmailが記録するReceivedヘッダでは、「(」の次から逆引き名が始まる。
「Received: from 」の直後に逆引き名が位置するフォーマットの場合(qmailの場合)は、この4文字を削除してください(ブラックリストの指定でも同様である)。
unknown
Postfixおよびqmailで、逆引きできなかった場合を引っかける。
sendmailの場合は不要である(削除しなくても支障はない)。
\[
sendmailでは、逆引きできなかった場合、「(」の直後の逆引き名が空になり、IPアドレスを囲む「[」が直後にいきなり位置する。その場合を引っかける。
Postfixおよびqmailの場合は不要である(削除しなくても支障はない)。
[0-9]
逆引きホスト名が数字で始まる場合を引っかける。すなわち、ルール3(逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる)の条件のサブセットである。
[^.]*[0-9][0-9][0-9][0-9][0-9]
逆引きホスト名に、5個以上連続する数字が含まれる場合を引っかける。すなわち、ルール2の条件である。
[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]
下線で示した部分は、随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介した時には「([a-z]|-)+」だけであった。ホスト名に、英字やハイフン1個以上で分断された数字列が2個以上含まれる場合を引っかける。すなわち、ルール1の条件である。
ところが、「h146.27.40.69.ip.alltel.net」のようなケースがけっこうすり抜けることがわかったので、数字列を分断するのは最初のドット1個でもよいという条件を付け加えた。ややトリッキーな書き方である。これで、ルール3で引っかかるものの一部がさらに引っかかるようになる。
ただし、これによって、「mx01.246.ne.jp」(実在するMXだが、メールを送信するかどうかはわからない)のようなケースが引っかかってしまう。S25Rのルール3は、このようなケースを引っかけないように上位3階層を検査から除外しているのだが、同じようにしようとすると正規表現が複雑化するので、やめた。レアケースだと思うので、かんべんしてください。
.*\(may be forged\)
sendmailで、逆引きのパラノイド検査が不適合になって、逆引き名とIPアドレスの次に「(may be forged)」と付記された場合を引っかける。
Postfixの場合は、パラノイド検査が不適合になった場合も逆引き失敗の場合と同じく「unknown」と表示されるので、不要である(削除しなくても支障はない)。qmailの場合は確かめていないが、多分不要だと思う。
土曜日, 9月 23, 2006
Becky!でのフィルタリング
私は、勤務先ではメーラーBecky!のフィルタリング機能を利用してスパムを捨てている。その方法は、随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介している。以前は、メールサーバが送信元の逆引き名をReceivedヘッダに記録してくれなかったので、S25R方式を応用した正規表現フィルタでHELOアドレスを検査して約60%、HTMLメールを捨てるフィルタを加えて約80%、さらに、怪しい単語(「viagra」など)を引っかけるフィルタを加えて約90%をごみ箱行きにしていた。
最近になって、逆引き名がReceivedヘッダに記録されるようになったので、フィルタを変更した。
まず、随筆記事で紹介している正規表現フィルタに若干工夫を加えた。「ヘッダ」欄に「Received」と入力し、「正規表現」のチェックをオンにして、「文字列」欄に次のように入力する。
from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp
ここで、「mail\.example\.jp」は自サイトのメールサーバ名に置き換える。MTAがsendmailの場合は、「unknown|」はなくてもよい。Postfixの場合は、「\[|」と「|.*\(may be forged\)」はなくてもよい。
これは、S25Rの一般規則を簡略化したもの(簡易一般規則と呼ぶことにする)である。逆引き失敗、およびルール1、2、3を合わせた条件とおおむね等価である。また、sendmailによるパラノイド検査(逆引き名の順引き結果が元のIPアドレスに一致するかどうかの検査)で不適合になって逆引き名に「(may be forged)」(偽造かもしれない)と付記されている場合も引っかけるようにしている。正当なメールをごみ箱行きから除外するには、この条件の下に絞り込み条件として除外条件を追加する。
また、次のブラックリストも設定した。
from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp
from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp
from .*\(user.*\.mindspring\.com .* by mail\.example\.jp
2006年8月23日から9月22日までの1ヶ月間に受信したスパムは535通。そのうち519通(97.0%)がスパム判定された。簡易一般規則に引っかかったものは494通(92.3%)であった。いずれも、9月15日の記事「宛先の正しいスパムの阻止率」で報告した阻止率(トータルで97.4%、一般規則で92.1%)に近い値である。
S25Rの一般規則には引っかかるが簡易一般規則をすり抜けたものは4通(0.7%)であった。このことから、簡易一般規則の効力はS25Rの一般規則に比べてさほど劣らないと言える。
これで、HTMLメールを捨てるフィルタと、怪しい単語を引っかけるフィルタは不要になった。これらのフィルタを設定してもスパム判定率はほとんど上がらない。
一方、誤ってごみ箱行きになった正当なメールは4通(送信元は3個)であった。人によってはもっと多くなるだろう。多くの外部サイトからのメールを受けないと、false positive率は計算しにくい。
以前、ウイルスバスターの迷惑メール対策機能を使っていた時には、判定レベルを「高」にしても、スパム判定率は85%くらいであった。それに比べて、わずか4個の、負荷の軽いフィルタで97%のスパムをごみ箱行きにできるのだから、S25R方式を応用したフィルタリングの効果は高い。一日に100通のスパムを受ける人の場合も、受信箱に残るスパムは平均3通ですむのだから、メーラーによるスパム対策としてはこれで十分だと思う。
Becky!以外への応用の参考のために、前記の4個のフィルタ設定を、Receivedヘッダ全体を検査する正規表現に直して示しておく。
/^Received: from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp/
/^Received: from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp/
/^Received: from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp/
/^Received: from .*\(user.*\.mindspring\.com .* by mail\.example\.jp/
最近になって、逆引き名がReceivedヘッダに記録されるようになったので、フィルタを変更した。
まず、随筆記事で紹介している正規表現フィルタに若干工夫を加えた。「ヘッダ」欄に「Received」と入力し、「正規表現」のチェックをオンにして、「文字列」欄に次のように入力する。
from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp
ここで、「mail\.example\.jp」は自サイトのメールサーバ名に置き換える。MTAがsendmailの場合は、「unknown|」はなくてもよい。Postfixの場合は、「\[|」と「|.*\(may be forged\)」はなくてもよい。
これは、S25Rの一般規則を簡略化したもの(簡易一般規則と呼ぶことにする)である。逆引き失敗、およびルール1、2、3を合わせた条件とおおむね等価である。また、sendmailによるパラノイド検査(逆引き名の順引き結果が元のIPアドレスに一致するかどうかの検査)で不適合になって逆引き名に「(may be forged)」(偽造かもしれない)と付記されている場合も引っかけるようにしている。正当なメールをごみ箱行きから除外するには、この条件の下に絞り込み条件として除外条件を追加する。
また、次のブラックリストも設定した。
from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp
from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp
from .*\(user.*\.mindspring\.com .* by mail\.example\.jp
2006年8月23日から9月22日までの1ヶ月間に受信したスパムは535通。そのうち519通(97.0%)がスパム判定された。簡易一般規則に引っかかったものは494通(92.3%)であった。いずれも、9月15日の記事「宛先の正しいスパムの阻止率」で報告した阻止率(トータルで97.4%、一般規則で92.1%)に近い値である。
S25Rの一般規則には引っかかるが簡易一般規則をすり抜けたものは4通(0.7%)であった。このことから、簡易一般規則の効力はS25Rの一般規則に比べてさほど劣らないと言える。
これで、HTMLメールを捨てるフィルタと、怪しい単語を引っかけるフィルタは不要になった。これらのフィルタを設定してもスパム判定率はほとんど上がらない。
一方、誤ってごみ箱行きになった正当なメールは4通(送信元は3個)であった。人によってはもっと多くなるだろう。多くの外部サイトからのメールを受けないと、false positive率は計算しにくい。
以前、ウイルスバスターの迷惑メール対策機能を使っていた時には、判定レベルを「高」にしても、スパム判定率は85%くらいであった。それに比べて、わずか4個の、負荷の軽いフィルタで97%のスパムをごみ箱行きにできるのだから、S25R方式を応用したフィルタリングの効果は高い。一日に100通のスパムを受ける人の場合も、受信箱に残るスパムは平均3通ですむのだから、メーラーによるスパム対策としてはこれで十分だと思う。
Becky!以外への応用の参考のために、前記の4個のフィルタ設定を、Receivedヘッダ全体を検査する正規表現に直して示しておく。
/^Received: from .*\((unknown|\[|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-)+|\.)[0-9]|.*\(may be forged\)).* by mail\.example\.jp/
/^Received: from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp/
/^Received: from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp/
/^Received: from .*\(user.*\.mindspring\.com .* by mail\.example\.jp/
月曜日, 9月 18, 2006
ベイジアンフィルタを欺くスパム
最近、宣伝文を画像化したスパムが多い。私が受けたスパムのうちでは、2006年7月には8通のうち6通、8月には10通のうち6通が画像ファイル付きだった。本文を解析するベイジアンフィルタを欺くことを狙っているのだろう。
今のところ、そのようなスパムはHTML形式であって、ベイジアンフィルタでもHTMLタグを解析してスパム判定することは可能だと思われる。また、ほとんどはメールヘッダに
Content-Type: multipart/related
が入っているので、これを条件としてごみ箱行きにするようメーラーでのフィルタリングを設定するという方法もある(Outlook Expressをデフォルト設定のままで使っている人から送信されるHTMLメールのヘッダは「Content-Type: multipart/alternative」になっているので、上記のフィルタリングでごみ箱行きになることはない)。
しかし、スパムメールの中身がプレーンテキストと画像ファイルだけになって、しかもプレーンテキストの内容がまっとうに見える文章になっていたら、ベイジアンフィルタでは歯が立たなくなるのではないだろうか。あるいは、判定条件がかき乱されて、正当なメールをスパム判定することが多くなるのではないだろうか。S25R方式の恩恵を受けていないユーザーにとって、ベイジアンフィルタや、それを応用したメーラーの迷惑メール対策機能は重宝な技術である。それが無力化しては気の毒である。
S25R方式をメーラーでのフィルタリングに応用する方法もある。メーラーBecky!なら、フィルタリング条件に正規表現を使えるので簡単に設定でき、私はそれを随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介している。また、本庄さんは「Becky! S25R spamフィルタ」というBecky!用のプラグインを開発されている。
ほかのメーラーのメーカーも、S25R方式を応用した迷惑メール対策機能を付けてくれないものだろうか。Receivedヘッダに記録された、送信元の逆引き名を解析すればよいので、技術的には簡単である(ただし、自サイトのメールサーバが送信元の逆引き名をReceivedヘッダに記録してくれなければならないが)。
もっとも、S25R方式があまりにも単純すぎることが、かえって採用の阻害要因になるかもしれない。スパム対策には世界中の人々が大変な苦労をしているのに、こんな簡単な方式で、受信するスパムのうち97%(9月15日の記事「宛先の正しいスパムの阻止率」参照)もスパム判定できるとは、おそらく多くの人には信じられないことだろう。開発者本人でさえ、もし私が他人だったら耳を疑うだろうと思うくらいだから。
今のところ、そのようなスパムはHTML形式であって、ベイジアンフィルタでもHTMLタグを解析してスパム判定することは可能だと思われる。また、ほとんどはメールヘッダに
Content-Type: multipart/related
が入っているので、これを条件としてごみ箱行きにするようメーラーでのフィルタリングを設定するという方法もある(Outlook Expressをデフォルト設定のままで使っている人から送信されるHTMLメールのヘッダは「Content-Type: multipart/alternative」になっているので、上記のフィルタリングでごみ箱行きになることはない)。
しかし、スパムメールの中身がプレーンテキストと画像ファイルだけになって、しかもプレーンテキストの内容がまっとうに見える文章になっていたら、ベイジアンフィルタでは歯が立たなくなるのではないだろうか。あるいは、判定条件がかき乱されて、正当なメールをスパム判定することが多くなるのではないだろうか。S25R方式の恩恵を受けていないユーザーにとって、ベイジアンフィルタや、それを応用したメーラーの迷惑メール対策機能は重宝な技術である。それが無力化しては気の毒である。
S25R方式をメーラーでのフィルタリングに応用する方法もある。メーラーBecky!なら、フィルタリング条件に正規表現を使えるので簡単に設定でき、私はそれを随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」で紹介している。また、本庄さんは「Becky! S25R spamフィルタ」というBecky!用のプラグインを開発されている。
ほかのメーラーのメーカーも、S25R方式を応用した迷惑メール対策機能を付けてくれないものだろうか。Receivedヘッダに記録された、送信元の逆引き名を解析すればよいので、技術的には簡単である(ただし、自サイトのメールサーバが送信元の逆引き名をReceivedヘッダに記録してくれなければならないが)。
もっとも、S25R方式があまりにも単純すぎることが、かえって採用の阻害要因になるかもしれない。スパム対策には世界中の人々が大変な苦労をしているのに、こんな簡単な方式で、受信するスパムのうち97%(9月15日の記事「宛先の正しいスパムの阻止率」参照)もスパム判定できるとは、おそらく多くの人には信じられないことだろう。開発者本人でさえ、もし私が他人だったら耳を疑うだろうと思うくらいだから。
土曜日, 9月 16, 2006
ブラックリスト
前回(9月15日)の記事で述べたように、2006年7月には、宛先の正しい不正メールの送信元で阻止されたのは297個であった。そのうち1個は送信者ドメインの実在の検査に引っかかり、一般規則に引っかかったものは281個であった。残りの15個はブラックリストで阻止されたもので、次のとおりである。
abcm136.neoplus.adsl.tpnet.pl [83.6.228.136]
abem128.neoplus.adsl.tpnet.pl [83.7.24.128]
abmf241.neoplus.adsl.tpnet.pl [83.7.225.241]
abty159.neoplus.adsl.tpnet.pl [83.8.170.159]
aeb234.internetdsl.tpnet.pl [83.16.105.234]
aiz151.neoplus.adsl.tpnet.pl [83.25.233.151]
boo89.neoplus.adsl.tpnet.pl [83.29.30.89]
dao137.neoplus.adsl.tpnet.pl [83.23.14.137]
dtf110.neoplus.adsl.tpnet.pl [83.24.243.110]
dtm234.neoplus.adsl.tpnet.pl [83.24.250.234]
dvn234.internetdsl.tpnet.pl [83.19.251.234]
edw31.neoplus.adsl.tpnet.pl [83.21.8.31]
xdsl-334.jgora.dialog.net.pl [81.168.149.78]
xdsl-5141.lodz.dialog.net.pl [87.105.80.21]
xdsl-9532.wroclaw.dialog.net.pl [84.40.234.60]
ご覧のように、ドメインは二つだけである。一般規則だけによる阻止率は92.1%だったが、たった二つのブラックリスト項目が阻止率を97.0%にまで引き上げていたのである(あと0.4%は送信者ドメインの実在の検査による)。
マークしておくべきドメインはもう一つある。
user-0cetsi8.cable.mindspring.com [24.238.242.72]
このドメインからの不正メールアクセスのうち、宛先が正しかったのはこの1件だけで、一般規則のルール1に引っかかっていた。しかし、「user-」の後の7個の英数字は番号を符号化したものと思われ、一続きで4桁以下の数字列しか含まれなくて一般規則をすり抜けることが時々ある。おそらく、一般規則をすり抜ける割合は、8桁の十六進番号よりも高い。しかも、このドメインは不正メール発信の常連である。
そういうわけで、ブラックリストに次の3件は最低限登録しておくことをお奨めする。
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain UCE-blacklisted
/^xdsl.+\.dialog\.net\.pl$/ 450 domain UCE-blacklisted
/^user.+\.mindspring\.com$/ 450 domain UCE-blacklisted
これらのうち、tpnet.plとmindspring.comは論文に示した設定ファイルの内容に含まれているが、dialog.net.plは最近見つけたもので、含まれていない。
なお、dialog.net.plを引っかけるには、一般規則のルール6を
/^(dhcp|dialup|ppp|adsl|xdsl)[^.]*[0-9]/ 450 may not be mail exchanger
と直してもよい。
abcm136.neoplus.adsl.tpnet.pl [83.6.228.136]
abem128.neoplus.adsl.tpnet.pl [83.7.24.128]
abmf241.neoplus.adsl.tpnet.pl [83.7.225.241]
abty159.neoplus.adsl.tpnet.pl [83.8.170.159]
aeb234.internetdsl.tpnet.pl [83.16.105.234]
aiz151.neoplus.adsl.tpnet.pl [83.25.233.151]
boo89.neoplus.adsl.tpnet.pl [83.29.30.89]
dao137.neoplus.adsl.tpnet.pl [83.23.14.137]
dtf110.neoplus.adsl.tpnet.pl [83.24.243.110]
dtm234.neoplus.adsl.tpnet.pl [83.24.250.234]
dvn234.internetdsl.tpnet.pl [83.19.251.234]
edw31.neoplus.adsl.tpnet.pl [83.21.8.31]
xdsl-334.jgora.dialog.net.pl [81.168.149.78]
xdsl-5141.lodz.dialog.net.pl [87.105.80.21]
xdsl-9532.wroclaw.dialog.net.pl [84.40.234.60]
ご覧のように、ドメインは二つだけである。一般規則だけによる阻止率は92.1%だったが、たった二つのブラックリスト項目が阻止率を97.0%にまで引き上げていたのである(あと0.4%は送信者ドメインの実在の検査による)。
マークしておくべきドメインはもう一つある。
user-0cetsi8.cable.mindspring.com [24.238.242.72]
このドメインからの不正メールアクセスのうち、宛先が正しかったのはこの1件だけで、一般規則のルール1に引っかかっていた。しかし、「user-」の後の7個の英数字は番号を符号化したものと思われ、一続きで4桁以下の数字列しか含まれなくて一般規則をすり抜けることが時々ある。おそらく、一般規則をすり抜ける割合は、8桁の十六進番号よりも高い。しかも、このドメインは不正メール発信の常連である。
そういうわけで、ブラックリストに次の3件は最低限登録しておくことをお奨めする。
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain UCE-blacklisted
/^xdsl.+\.dialog\.net\.pl$/ 450 domain UCE-blacklisted
/^user.+\.mindspring\.com$/ 450 domain UCE-blacklisted
これらのうち、tpnet.plとmindspring.comは論文に示した設定ファイルの内容に含まれているが、dialog.net.plは最近見つけたもので、含まれていない。
なお、dialog.net.plを引っかけるには、一般規則のルール6を
/^(dhcp|dialup|ppp|adsl|xdsl)[^.]*[0-9]/ 450 may not be mail exchanger
と直してもよい。
金曜日, 9月 15, 2006
宛先の正しいスパムの阻止率
私のサイトへの不正メールアクセスの大半は、宛先誤りのものである。スパムやウィルスメールをおびき寄せてデータを取るためにおとりアドレスを仕掛けたのが理由の一つである。また、ISO-2022-JP(通称:JIS)で符号化したウェブページから拾い出された「bwebmaster」などの間違いアドレスもある。先頭の「b」は、文字セット切り替えのエスケープシーケンス(「B」と同じ符号を含む)から誤って抽出されたものである。ほかに、「sneovbwebmaster」だの「qujwtbwebmaster」だのというでたらめのアドレスもある。アドレスリストにごみデータを混ぜて水増しして売り飛ばす奴がいるのだろうか。
このような不正メールアクセスから統計を取り、2004年4月にも2006年7月にも、ホスト数で計って阻止率99.1%という結果を得た(8月25日「今なお阻止率99%」)。しかし、対策をしていなければ受けてしまったであろうスパムの推計数と実際に受けてしまった通数から計算した阻止率は、97.8%という、やや低い値になった(8月26日「通数で計った阻止率」)。これはなぜだろうかと考えて、推計値でない厳密な統計値を出すことを思い付いた。宛先の正しい不正メールを送り込もうとしたホストだけを抽出して、そのホスト数で阻止率を計るという方法である。
2006年7月には、受けてしまったスパムの送信元は8個(ISPのメールサーバを含む)、阻止されたホストは297個、そのうち一般規則に引っかかったものは281個であった。このことから、トータルの阻止率は97.4%、一般規則だけによる阻止率は92.1%という結果になった。トータルの阻止率は、通数で計った推計阻止率に近い。
私は論文で「阻止率99%」と標榜しており、それは不正メールアクセスすべてから統計を取った結果であって嘘ではないのだが、受信するスパムの減少率は97%くらいと思っていただいた方がよいかもしれない。それでも、無料でできるスパム対策としては十分に高い値だと思う。
この結果は何を意味するかというと、宛先の正しいスパムはS25R方式の防御を突破する率がやや高いということである。その理由を私はこう推測する。スパマーには、効率無視のスパマーと効率重視のスパマーがいる。効率無視のスパマーは、ごみデータだらけのアドレスリストを使い、たくさんのエンドユーザーPCをゾンビ化させて、送達率など気にせずにスパムをばらまく。これらのほとんどはS25R方式で阻止できる。一方、効率重視のスパマーは、送達率の高い良質なアドレスリストを使い、ISPのメールサーバを経由するか、あるいはセキュリティの弱いサーバを乗っ取ってそこからスパムをばらまく。それらの送信元が逆引きできて、しかもサーバっぽい逆引き名であれば、S25R方式では阻止できない。つまり、効率重視のスパマーが、宛先の正しいスパムの突破率を押し上げているのだろう。
このような不正メールアクセスから統計を取り、2004年4月にも2006年7月にも、ホスト数で計って阻止率99.1%という結果を得た(8月25日「今なお阻止率99%」)。しかし、対策をしていなければ受けてしまったであろうスパムの推計数と実際に受けてしまった通数から計算した阻止率は、97.8%という、やや低い値になった(8月26日「通数で計った阻止率」)。これはなぜだろうかと考えて、推計値でない厳密な統計値を出すことを思い付いた。宛先の正しい不正メールを送り込もうとしたホストだけを抽出して、そのホスト数で阻止率を計るという方法である。
2006年7月には、受けてしまったスパムの送信元は8個(ISPのメールサーバを含む)、阻止されたホストは297個、そのうち一般規則に引っかかったものは281個であった。このことから、トータルの阻止率は97.4%、一般規則だけによる阻止率は92.1%という結果になった。トータルの阻止率は、通数で計った推計阻止率に近い。
私は論文で「阻止率99%」と標榜しており、それは不正メールアクセスすべてから統計を取った結果であって嘘ではないのだが、受信するスパムの減少率は97%くらいと思っていただいた方がよいかもしれない。それでも、無料でできるスパム対策としては十分に高い値だと思う。
この結果は何を意味するかというと、宛先の正しいスパムはS25R方式の防御を突破する率がやや高いということである。その理由を私はこう推測する。スパマーには、効率無視のスパマーと効率重視のスパマーがいる。効率無視のスパマーは、ごみデータだらけのアドレスリストを使い、たくさんのエンドユーザーPCをゾンビ化させて、送達率など気にせずにスパムをばらまく。これらのほとんどはS25R方式で阻止できる。一方、効率重視のスパマーは、送達率の高い良質なアドレスリストを使い、ISPのメールサーバを経由するか、あるいはセキュリティの弱いサーバを乗っ取ってそこからスパムをばらまく。それらの送信元が逆引きできて、しかもサーバっぽい逆引き名であれば、S25R方式では阻止できない。つまり、効率重視のスパマーが、宛先の正しいスパムの突破率を押し上げているのだろう。
月曜日, 9月 11, 2006
ホワイトリスト情報
ルール1に引っかかるメールサーバがまた見つかって、ホワイトリスト情報に掲載した。
# Sep 11, 2006: adm2-bge0.cc.uec.ac.jp
/\.cc\.uec\.ac\.jp$/ OK
こういうことがあると、「ルール1の条件を緩めた方がよいだろうか」とつい思ってしまう。しかしそれは、強固な防衛力によってサイトの平和が保たれていることをつい忘れてしまうからだろう。
前回(9月3日)の記事に書いたように、2006年7月の統計によれば、ルール1の条件を「3個以上の数字列」に緩めたら阻止率は1.3%低下する。わずかなもののように思えるかもしれないが、不正メールの送信元のホスト4423個のうち、見逃されるものが57個増えるのである。大規模サイトでは、一日の不正メールアクセスが数千件になる所はざらであろう。数千件のうちの数十件の不正メールアクセスを毎日見逃すか、たまにホワイトリスト登録を強いられるか、どちらを選びますか?それを考えれば、「数字列が2個以上なら阻止」という一見厳しすぎる条件を提案したことは間違っていなかったと思っている。
一方、ルール2をぎりぎりですり抜けたスパム(すなわち、ホスト名に4桁の数字を含むホストからのもの)をたまに受けると、ルール2を厳しくしたいという衝動にかられてしまう。
実は、ルール2を「数字が5桁以上なら阻止」という条件に決めたのは、多分に恣意的な理由によるものである。第一に、S25R方式の開発中にいろいろなドメインのMXレコードを調べたところ、見つかったホスト名の中では数字4桁が最長だったこと。第二に、4桁までの数字なら覚えやすいので(自動車のナンバーが4桁だし、電話番号も多くの場合、最大4桁ずつ区切って覚えるから)、4桁の数字を含むホスト名をメールサーバに付ける人はいるだろうと思ったこと。第三に、S25R方式で阻止されないホスト名を決めようとする人の立場で考えた時、「数字は一続きで3桁まで」という条件は窮屈すぎると思われたからである。
実際のところ、ルール2をぎりぎりですり抜ける不正メールの送信元は少しあるが(4423個中9個)、ブラックリストで阻止するのに苦労はない程度。一方、ホスト名に数字5桁を含む正当なメールサーバもたまに見つかるが、ホワイトリストで許可するのに苦労はない程度である。「数字が5桁以上なら阻止」という条件は、ほどほどバランスがとれていると思う。
# Sep 11, 2006: adm2-bge0.cc.uec.ac.jp
/\.cc\.uec\.ac\.jp$/ OK
こういうことがあると、「ルール1の条件を緩めた方がよいだろうか」とつい思ってしまう。しかしそれは、強固な防衛力によってサイトの平和が保たれていることをつい忘れてしまうからだろう。
前回(9月3日)の記事に書いたように、2006年7月の統計によれば、ルール1の条件を「3個以上の数字列」に緩めたら阻止率は1.3%低下する。わずかなもののように思えるかもしれないが、不正メールの送信元のホスト4423個のうち、見逃されるものが57個増えるのである。大規模サイトでは、一日の不正メールアクセスが数千件になる所はざらであろう。数千件のうちの数十件の不正メールアクセスを毎日見逃すか、たまにホワイトリスト登録を強いられるか、どちらを選びますか?それを考えれば、「数字列が2個以上なら阻止」という一見厳しすぎる条件を提案したことは間違っていなかったと思っている。
一方、ルール2をぎりぎりですり抜けたスパム(すなわち、ホスト名に4桁の数字を含むホストからのもの)をたまに受けると、ルール2を厳しくしたいという衝動にかられてしまう。
実は、ルール2を「数字が5桁以上なら阻止」という条件に決めたのは、多分に恣意的な理由によるものである。第一に、S25R方式の開発中にいろいろなドメインのMXレコードを調べたところ、見つかったホスト名の中では数字4桁が最長だったこと。第二に、4桁までの数字なら覚えやすいので(自動車のナンバーが4桁だし、電話番号も多くの場合、最大4桁ずつ区切って覚えるから)、4桁の数字を含むホスト名をメールサーバに付ける人はいるだろうと思ったこと。第三に、S25R方式で阻止されないホスト名を決めようとする人の立場で考えた時、「数字は一続きで3桁まで」という条件は窮屈すぎると思われたからである。
実際のところ、ルール2をぎりぎりですり抜ける不正メールの送信元は少しあるが(4423個中9個)、ブラックリストで阻止するのに苦労はない程度。一方、ホスト名に数字5桁を含む正当なメールサーバもたまに見つかるが、ホワイトリストで許可するのに苦労はない程度である。「数字が5桁以上なら阻止」という条件は、ほどほどバランスがとれていると思う。
日曜日, 9月 03, 2006
一般規則を緩めたら
ルール1(逆引きFQDNの最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む)やルール2(逆引きFQDNの最下位の名前が、5個以上連続する数字を含む)に引っかかるメールサーバがある。そのため、これらの条件を緩めた方が安全ではないかと考える方もおられるであろう。
8月25日の記事「今なお阻止率99%」に書いたように、2006年7月には、一般規則による阻止率は98.2%であった。これが、ルール1またはルール2の条件を緩めたらどのくらいに下がるのかを計算してみた(それぞれ、ほかのルールは変えないという前提で計算している)。
ルール1を「3個以上の数字列」という条件にしたら96.9%(1.3%減)。「4個以上の数字列」では95.7%(2.5%減)。
ルール2を「6個以上連続する数字」という条件にしたら98.0%(0.2%減)。「7個以上連続する数字」では97.6%(0.6%減)。ついでに、「4個以上連続する数字」と厳しくしたら98.4%(0.2%増)になった。
これらの結果をどう考えるかは皆さんにお任せする。「阻止率の低下がそのくらい少ないなら、正当なメールサーバを阻止するリスクを減らすために条件を緩めよう」と考える人もいるかもしれない。
しかし私は、条件を緩めてもホワイトリストの作成の手間が大きく減ることはないだろうと思う。どのみち、逆引きできないメールサーバや、エンドユーザー回線を使っているメールサーバ(小規模サイトやメールマガジン配信業者などのもの)はホワイトリスト登録しなければならず、それらに比べれば、一般規則を緩めることで引っかからなくなるメールサーバは少ないと考えられるからである。
8月25日の記事「今なお阻止率99%」に書いたように、2006年7月には、一般規則による阻止率は98.2%であった。これが、ルール1またはルール2の条件を緩めたらどのくらいに下がるのかを計算してみた(それぞれ、ほかのルールは変えないという前提で計算している)。
ルール1を「3個以上の数字列」という条件にしたら96.9%(1.3%減)。「4個以上の数字列」では95.7%(2.5%減)。
ルール2を「6個以上連続する数字」という条件にしたら98.0%(0.2%減)。「7個以上連続する数字」では97.6%(0.6%減)。ついでに、「4個以上連続する数字」と厳しくしたら98.4%(0.2%増)になった。
これらの結果をどう考えるかは皆さんにお任せする。「阻止率の低下がそのくらい少ないなら、正当なメールサーバを阻止するリスクを減らすために条件を緩めよう」と考える人もいるかもしれない。
しかし私は、条件を緩めてもホワイトリストの作成の手間が大きく減ることはないだろうと思う。どのみち、逆引きできないメールサーバや、エンドユーザー回線を使っているメールサーバ(小規模サイトやメールマガジン配信業者などのもの)はホワイトリスト登録しなければならず、それらに比べれば、一般規則を緩めることで引っかからなくなるメールサーバは少ないと考えられるからである。
金曜日, 9月 01, 2006
グレイリスティングを抜けられないサイト
ホワイトリスト情報で公開しているサイトに以下のものがある。
# Nov 25, 2004: mta12.m2.home.ne.jp, etc.
/\.m2\.home\.ne\.jp$/ OK
# Jan 10, 2006: n2.59-106-41-68.mixi.jp, etc. (*)
/\.mixi\.jp$/ OK
これらは、リトライのたびに送信元のIPアドレスが変わるという困った動作をするサイトである。前者は私が見つけた。後者は、協力者から報告されたものだが、これも困ったサイトだということは後で佐藤さんのブログ記事で知った。
S25Rの拒否条件に引っかかる上に、グレイリスティングも抜けられない。だから、S25R方式の導入サイトだけでなく、グレイリスティングの導入サイトでもホワイトリスト登録しておかなければならない。
S25R方式では拒否されなくてもグレイリスティングを抜けられないサイトがほかにあるかもしれないので、グレイリスティングの導入サイトでは要注意である(注意しようにもどうしようもないかもしれないが)。
こんなスパムもどきの動作はしてほしくないのだが。
# Nov 25, 2004: mta12.m2.home.ne.jp, etc.
/\.m2\.home\.ne\.jp$/ OK
# Jan 10, 2006: n2.59-106-41-68.mixi.jp, etc. (*)
/\.mixi\.jp$/ OK
これらは、リトライのたびに送信元のIPアドレスが変わるという困った動作をするサイトである。前者は私が見つけた。後者は、協力者から報告されたものだが、これも困ったサイトだということは後で佐藤さんのブログ記事で知った。
S25Rの拒否条件に引っかかる上に、グレイリスティングも抜けられない。だから、S25R方式の導入サイトだけでなく、グレイリスティングの導入サイトでもホワイトリスト登録しておかなければならない。
S25R方式では拒否されなくてもグレイリスティングを抜けられないサイトがほかにあるかもしれないので、グレイリスティングの導入サイトでは要注意である(注意しようにもどうしようもないかもしれないが)。
こんなスパムもどきの動作はしてほしくないのだが。
登録:
投稿 (Atom)