前回の続き。
質問してきた方は、やはり日本の会社に勤務する中国人だった。S25R方式を導入したのは、国内にあるメールサーバ。
確かに中国では逆引きの設定が広まっていないので、中国からのメールを受信するのにホワイトリスト登録が必要になることはあるとのこと。しかし、中国でもスパムの被害は深刻なので、友人にもS25R方式を勧めたいとおっしゃっていた。
逆引きの設定が広まっていない中国では、グレイリスティングの方が良いかもしれない。ただ、「初めてメールを送ってくるホストにはわざと一時拒否応答を返す」というグレイリスティングのコンセプトよりも、「逆引き名がサーバっぽいならば許可する。そうでないメールサーバはホワイトリストで許可する」というS25R方式のコンセプトの方が理解しやすいかもしれない。S25R方式を試してから「よく考えてみたら、グレイリスティングでいいじゃないか」と気付く人がいれば、それはそれでよいと思う。
金曜日, 10月 30, 2009
火曜日, 10月 27, 2009
サブミッションポートでの送信を許可する設定
中国人と思われる方から質問をいただいた。メールの本文は簡体中国語の文字セットで書かれた日本語。S25R方式を導入したら、ぷらら（plala.or.jp）からの送信ができないので、解決策を教えてほしいとのこと。
示されたエラーメッセージからわかったのは、S25Rに引っかかるぷららのエンドユーザー回線から、S25R方式を導入したメールサーバへ、ポート587で送信しようとしたらしいということだった。つまり、サブミッションポートでの送信である。
以下の太字の指定を追加するよう助言した。
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access regexp:/etc/postfix/white_list,
check_client_access regexp:/etc/postfix/rejections
これで解決したとの返事をいただいた。この設定を私自身で検証してはいなかったのだが、助言が当たってよかった。
メールはhotmailから送られてきていたので、この人の所属は不明だったが、示されたエラーメッセージにあった宛先ドメインから、対中国のビジネスをサポートする日本の会社に勤務する人らしいと推測した。中国では逆引きの設定があまり普及していないらしいので、日本国内の会社でも中国とのやり取りが多いと、S25R方式は使いにくくはないだろうか。
もっとも、逆引きできないホストのホワイトリスト登録がいくら大変でも、スパムの被害に手をこまねいているよりはましだと評価されているかもしれない。
もし感想を言ってくれたらまた紹介しようと思う。
示されたエラーメッセージからわかったのは、S25Rに引っかかるぷららのエンドユーザー回線から、S25R方式を導入したメールサーバへ、ポート587で送信しようとしたらしいということだった。つまり、サブミッションポートでの送信である。
以下の太字の指定を追加するよう助言した。
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access regexp:/etc/postfix/white_list,
check_client_access regexp:/etc/postfix/rejections
これで解決したとの返事をいただいた。この設定を私自身で検証してはいなかったのだが、助言が当たってよかった。
メールはhotmailから送られてきていたので、この人の所属は不明だったが、示されたエラーメッセージにあった宛先ドメインから、対中国のビジネスをサポートする日本の会社に勤務する人らしいと推測した。中国では逆引きの設定があまり普及していないらしいので、日本国内の会社でも中国とのやり取りが多いと、S25R方式は使いにくくはないだろうか。
もっとも、逆引きできないホストのホワイトリスト登録がいくら大変でも、スパムの被害に手をこまねいているよりはましだと評価されているかもしれない。
もし感想を言ってくれたらまた紹介しようと思う。
木曜日, 10月 15, 2009
48時間続いたスパムアクセス
次のようなスパムアクセスがあった。
Oct 11 19:29:39 unknown [81.255.105.209] from=<paypal@60299.com> to=<deo@gabacho-net.jp> helo=<messagerie.CHG-AJ.local>
Oct 11 19:30:52 〃
Oct 11 19:32:04 〃
…
Oct 13 19:01:28 〃
Oct 13 19:16:41 〃
Oct 13 19:32:09 〃
初めは約1分間隔、その後約15分間隔になって、48時間でようやく止まった。
6月13日に、送信者アドレス<paypal@50305.com>で、PayPalをかたったフィッシング詐欺のスパムがmail.leadershipaa.org [71.248.112.64]から着信していた。今回も、送信者アドレスのユーザーIDが同じで、サイトドメイン名が数字5桁であることが共通で、HELOアドレスがまともでないことから、スパムに違いないと判断して放置してみたのである。
前回のmail.leadershipaa.orgは、SMTPアクセスしてみたらWindowsサーバであることがわかった。ボットにやられたのかもしれない。今回の[81.255.105.209]は、挙動はメールサーバのものだが、SMTPアクセスに応答しなかった。スパム送信用サーバだったのかもしれない。
なお、このような場合、リトライアクセスがうざったいと思って、論文に示しているrejectionsファイルに
/^81\.255\.105\.209$/ REJECT
と追記することによって応答コード「554」で蹴飛ばそうとしても、うまくいかない。Postfixは、まずFQDNで正規表現ファイルをサーチし、次にIPアドレスの十進表記でサーチするので、逆引き結果の名前「unknown」が先にマッチして「450」を返してしまうのである。
逆引きできないホストを「554」で蹴飛ばそうと思ったら、rejectionsファイルの前にもう一つの拒否条件ファイルを指定してそこに拒否条件を書く必要がある。あるいは、rejectionsファイルの前に指定されているwhite_listファイルの中に臨時に拒否条件を書いてもよい。
Oct 11 19:29:39 unknown [81.255.105.209] from=<paypal@60299.com> to=<deo@gabacho-net.jp> helo=<messagerie.CHG-AJ.local>
Oct 11 19:30:52 〃
Oct 11 19:32:04 〃
…
Oct 13 19:01:28 〃
Oct 13 19:16:41 〃
Oct 13 19:32:09 〃
初めは約1分間隔、その後約15分間隔になって、48時間でようやく止まった。
6月13日に、送信者アドレス<paypal@50305.com>で、PayPalをかたったフィッシング詐欺のスパムがmail.leadershipaa.org [71.248.112.64]から着信していた。今回も、送信者アドレスのユーザーIDが同じで、サイトドメイン名が数字5桁であることが共通で、HELOアドレスがまともでないことから、スパムに違いないと判断して放置してみたのである。
前回のmail.leadershipaa.orgは、SMTPアクセスしてみたらWindowsサーバであることがわかった。ボットにやられたのかもしれない。今回の[81.255.105.209]は、挙動はメールサーバのものだが、SMTPアクセスに応答しなかった。スパム送信用サーバだったのかもしれない。
なお、このような場合、リトライアクセスがうざったいと思って、論文に示しているrejectionsファイルに
/^81\.255\.105\.209$/ REJECT
と追記することによって応答コード「554」で蹴飛ばそうとしても、うまくいかない。Postfixは、まずFQDNで正規表現ファイルをサーチし、次にIPアドレスの十進表記でサーチするので、逆引き結果の名前「unknown」が先にマッチして「450」を返してしまうのである。
逆引きできないホストを「554」で蹴飛ばそうと思ったら、rejectionsファイルの前にもう一つの拒否条件ファイルを指定してそこに拒否条件を書く必要がある。あるいは、rejectionsファイルの前に指定されているwhite_listファイルの中に臨時に拒否条件を書いてもよい。
月曜日, 10月 12, 2009
学生の盗作レポート
スパム対策とは関係のない話であることをご了承いただきたい。
私のサイトGabacho-Netに、日本語脚韻研究室という文芸のコーナーがある。2002年に日本語脚韻を思い付いてから5年にわたって、日本語脚韻を実践している人たちと交流しながら学んできた。その成果を掲載している。
最後の成果は、「日本語脚韻詩絶望論」という、2007年に書いたレポートである。日本語脚韻詩をいくつも作った上で、日本語脚韻詩が絶望的に難しいことの理由を論じた。日本語脚韻をやったこともない人が「日本語脚韻は無理だ」と言っているのとも、日本語脚韻を実践している人が「日本語脚韻はできる」と言っているのとも違う、私がオリジナリティを誇るレポートである。
その「日本語脚韻詩絶望論」が学生レポートに盗用された。このままでは、日本語脚韻詩が困難な理由を論じたオリジナリティが私以外の者にあるという誤った情報が、その学生の指導教官を通じて流布されるおそれがある。その可能性はきわめて低いとは思うが、皆無ではない以上、流布されるかもしれない誤った情報に対する対抗措置をとる必要があると考えた。そこで、盗作を告発する「「日本語脚韻詩絶望論」を盗用した学生レポートについて」というコンテンツを掲載した。
このコンテンツがなるべく早く検索サイトに拾われることを期待して、このブログ記事にリンクを設けることにした。このブログは注目度が高いので、リンクが検索サイトに早く拾われるかもしれないと思ったからである。
学生がインターネットで拾った情報を安易にコピーしてレポートをでっち上げることは数多く起こっていると聞く。このブログの読者に大学の先生がいらっしゃったら、学生が盗作レポートを作っていないかどうかに目を光らせるようお願いしたい。特に、レポートが優れた内容に見えるときにはチェックしていただいた方がよいと思う。チェックのための検索は難しいことではない。たとえば、くだんの学生レポートの場合、日本語脚韻が困難である理由を論じていることから「日本語 脚韻 困難 理由」で検索すれば、盗作とすぐわかったはずである。
盗作は、読者を欺き、オリジナルの作者の名誉を傷付ける犯罪である。そのことを学生にきちんと教えることもお願いしたい。
（追記）
ビンゴ！この記事を投稿してからわずか1時間足らずでGoogleが新コンテンツを拾いに来た。Googleは来るのが早い。
私のサイトGabacho-Netに、日本語脚韻研究室という文芸のコーナーがある。2002年に日本語脚韻を思い付いてから5年にわたって、日本語脚韻を実践している人たちと交流しながら学んできた。その成果を掲載している。
最後の成果は、「日本語脚韻詩絶望論」という、2007年に書いたレポートである。日本語脚韻詩をいくつも作った上で、日本語脚韻詩が絶望的に難しいことの理由を論じた。日本語脚韻をやったこともない人が「日本語脚韻は無理だ」と言っているのとも、日本語脚韻を実践している人が「日本語脚韻はできる」と言っているのとも違う、私がオリジナリティを誇るレポートである。
その「日本語脚韻詩絶望論」が学生レポートに盗用された。このままでは、日本語脚韻詩が困難な理由を論じたオリジナリティが私以外の者にあるという誤った情報が、その学生の指導教官を通じて流布されるおそれがある。その可能性はきわめて低いとは思うが、皆無ではない以上、流布されるかもしれない誤った情報に対する対抗措置をとる必要があると考えた。そこで、盗作を告発する「「日本語脚韻詩絶望論」を盗用した学生レポートについて」というコンテンツを掲載した。
このコンテンツがなるべく早く検索サイトに拾われることを期待して、このブログ記事にリンクを設けることにした。このブログは注目度が高いので、リンクが検索サイトに早く拾われるかもしれないと思ったからである。
学生がインターネットで拾った情報を安易にコピーしてレポートをでっち上げることは数多く起こっていると聞く。このブログの読者に大学の先生がいらっしゃったら、学生が盗作レポートを作っていないかどうかに目を光らせるようお願いしたい。特に、レポートが優れた内容に見えるときにはチェックしていただいた方がよいと思う。チェックのための検索は難しいことではない。たとえば、くだんの学生レポートの場合、日本語脚韻が困難である理由を論じていることから「日本語 脚韻 困難 理由」で検索すれば、盗作とすぐわかったはずである。
盗作は、読者を欺き、オリジナルの作者の名誉を傷付ける犯罪である。そのことを学生にきちんと教えることもお願いしたい。
（追記）
ビンゴ！この記事を投稿してからわずか1時間足らずでGoogleが新コンテンツを拾いに来た。Googleは来るのが早い。
水曜日, 9月 23, 2009
スパムを送ってきたショッピングサイト
9月10日、HELOアドレスがmail.tacok.comで逆引きできないホストからリトライアクセスがあったので許可してみたら、ショッピングサイトdoremo.jpを宣伝するスパムだった。本文は日本語だが、文字コードはなぜか簡体中国語（簡体中国語の文字セットには日本語の仮名文字も含まれている）。本文は、世界から押し寄せる多くの英語のスパムのような無作法な書き方ではないが、「未承諾広告」の表示やオプトアウトの説明を守っていない。
ホワイトリスト登録を取り消したが、これは悩ましいなと思った。doremo.jpは、見たところ、違法性や悪質さが認められない、普通と見受けられるショッピングサイトである。もしかしたら、doremo.jpでショッピングをした人のいるサイトでmail.tacok.comからの正当なメールが引っかかり、そのサイトの管理者からホワイトリスト情報が報告されるかもしれない。私は、寄せられるホワイトリスト情報はすべて信用するというポリシーをとっているが、宣伝のためにスパムをまいたことがあるとわかっているサイトを公開ホワイトリストに掲載すべきか。また、公開ホワイトリストに登録されたホストがスパムをまいたことがほかの人から報告されたらどうするか。
考えた末、スパムをまいたことがあるとわかっている（もしくはそう報告された）サイトのホストは公開ホワイトリストに掲載しない、あるいは公開ホワイトリストへの掲載を取り消すというポリシーをとろうと思う。そして、ホワイトリスト登録を要請した人には、サイト・ローカルのホワイトリストで許可してくださいと依頼する。
その理由は次のとおりである。S25Rに引っかからないホストがスパムを送ってきて、そのホストからは受信したくないとサイト管理者が考えた場合は、論文に示しているrejectionsファイルに拒否条件を追記すればよい。しかし、公開ホワイトリストに許可条件が書かれていると、それを取り込んでいるサイトでは、rejectionsファイルの拒否条件に優先して許可されてしまう。もう一つの拒否条件ファイルをホワイトリストの前に指定するという方法もあるが、設定が複雑化する。だから、スパムをまいたことのあるホストは（正当なメールも送信しているとしても）公開ホワイトリストには掲載しない方がよい。
いったん公開ホワイトリストに掲載したホストを取り消すと、公開ホワイトリストを取り込んでいるサイトでは、受信できていたメールが突然受信できなくなるということが起こるかもしれない。しかし、それはやむを得ない。ログを監視して、公開ホワイトリストで許可されないホストはローカルのホワイトリストで許可するようにしていただきたい。公開ホワイトリストは、ローカルのブラックリストの働きを妨害しない方がよいと私は考えるからである。
なお、スパムを送ってきたのがISPのメールサーバだった場合は話は別である。その場合は、そのサイト（ISP）がスパム送信という悪事を働いたわけではなく、ユーザーの中にたまたまスパム送信者がいたにすぎない。ISPのメールサーバを経由したスパムを受けたからといって、そのメールサーバの許可を取り消すわけにはいかない。
ホワイトリスト登録を取り消したが、これは悩ましいなと思った。doremo.jpは、見たところ、違法性や悪質さが認められない、普通と見受けられるショッピングサイトである。もしかしたら、doremo.jpでショッピングをした人のいるサイトでmail.tacok.comからの正当なメールが引っかかり、そのサイトの管理者からホワイトリスト情報が報告されるかもしれない。私は、寄せられるホワイトリスト情報はすべて信用するというポリシーをとっているが、宣伝のためにスパムをまいたことがあるとわかっているサイトを公開ホワイトリストに掲載すべきか。また、公開ホワイトリストに登録されたホストがスパムをまいたことがほかの人から報告されたらどうするか。
考えた末、スパムをまいたことがあるとわかっている（もしくはそう報告された）サイトのホストは公開ホワイトリストに掲載しない、あるいは公開ホワイトリストへの掲載を取り消すというポリシーをとろうと思う。そして、ホワイトリスト登録を要請した人には、サイト・ローカルのホワイトリストで許可してくださいと依頼する。
その理由は次のとおりである。S25Rに引っかからないホストがスパムを送ってきて、そのホストからは受信したくないとサイト管理者が考えた場合は、論文に示しているrejectionsファイルに拒否条件を追記すればよい。しかし、公開ホワイトリストに許可条件が書かれていると、それを取り込んでいるサイトでは、rejectionsファイルの拒否条件に優先して許可されてしまう。もう一つの拒否条件ファイルをホワイトリストの前に指定するという方法もあるが、設定が複雑化する。だから、スパムをまいたことのあるホストは（正当なメールも送信しているとしても）公開ホワイトリストには掲載しない方がよい。
いったん公開ホワイトリストに掲載したホストを取り消すと、公開ホワイトリストを取り込んでいるサイトでは、受信できていたメールが突然受信できなくなるということが起こるかもしれない。しかし、それはやむを得ない。ログを監視して、公開ホワイトリストで許可されないホストはローカルのホワイトリストで許可するようにしていただきたい。公開ホワイトリストは、ローカルのブラックリストの働きを妨害しない方がよいと私は考えるからである。
なお、スパムを送ってきたのがISPのメールサーバだった場合は話は別である。その場合は、そのサイト（ISP）がスパム送信という悪事を働いたわけではなく、ユーザーの中にたまたまスパム送信者がいたにすぎない。ISPのメールサーバを経由したスパムを受けたからといって、そのメールサーバの許可を取り消すわけにはいかない。
月曜日, 9月 21, 2009
リトライしないメールマガジン送信サーバ
掲示板にhanaさんから寄せられたホワイトリスト情報は、リトライしないメールマガジン送信サーバのものだった。公開ホワイトリストへの登録は以下のとおりである。
# Sep 02, 3009: mail2.nc-nippon.com (*)
/^210\.197\.89\.90$/ OK
ログからは7日間隔のリトライに見えたが、7日ごとに発行されるメールマガジンで、応答コード「450」に対してリトライしていないことがわかったとのこと。リトライしないメールサーバもあるとは聞いていたが、本当に見つかったのはこれが初めてである。
hanaさんは、「単発のアクセスも無視できないと反省。HELOと送信者のドメインが一致する場合は要注意といったところでしょうか」とおっしゃっていた。しかし、単発のアクセスの中に正当なメールがあるかもしれないと思ってログを監視するのは大変である。
リトライしないようにメールサーバを設定しているということは、届かないなら届かないでかまわないと思っているということである。そういうのは、スパムでなければおそらくメールマガジンだけで、個人が送信するメールではまずそんなことはないだろう。届かなくてもかまわないようなメールのためにメールシステム管理者が苦労する必要はないだろう。受信者が待っているメールならば、受信者が「届かないんだけど」と申告してくるだろうから、その時に調査してあげればよい。
# Sep 02, 3009: mail2.nc-nippon.com (*)
/^210\.197\.89\.90$/ OK
ログからは7日間隔のリトライに見えたが、7日ごとに発行されるメールマガジンで、応答コード「450」に対してリトライしていないことがわかったとのこと。リトライしないメールサーバもあるとは聞いていたが、本当に見つかったのはこれが初めてである。
hanaさんは、「単発のアクセスも無視できないと反省。HELOと送信者のドメインが一致する場合は要注意といったところでしょうか」とおっしゃっていた。しかし、単発のアクセスの中に正当なメールがあるかもしれないと思ってログを監視するのは大変である。
リトライしないようにメールサーバを設定しているということは、届かないなら届かないでかまわないと思っているということである。そういうのは、スパムでなければおそらくメールマガジンだけで、個人が送信するメールではまずそんなことはないだろう。届かなくてもかまわないようなメールのためにメールシステム管理者が苦労する必要はないだろう。受信者が待っているメールならば、受信者が「届かないんだけど」と申告してくるだろうから、その時に調査してあげればよい。
日曜日, 9月 13, 2009
批判に勝つのは誰か
講演資料の最後のページに次のように書いている。
話題がS25R方式から離れているので、私の講演を聴いた人以外には、このスライドを見るだけでは理解しにくいかもしれない。そこで、私がこのスライドに込めた意図を説明する。
S25R方式は、批判を受けながらも、発表後5年を経て多くのサイトで採用されるようになった。導入サイト数は1000以上と推定される。S25R方式に対して「こんなものはだめだ」と言っていた人たちは、S25R方式の成功を予見できなかったということである。
同じように、普及したものの中には当初批判されていたものがあった。
作家の阿川弘之氏は、「これからはモータリゼーションと航空機の時代で、鉄道は過去の遺物だ」と言って新幹線建設を批判した。後に新幹線が鉄道斜陽論を覆すに至った時、彼は「私が間違っていた」と言った。
ロケット工学者の糸川英夫氏は、著書の中で「家庭用VTRは普及しないだろう」と言っていた。忙しい人はテレビ番組を録画しておいて後で見ることができるとはいっても、忙しい人はその時間さえないからだと言う。大衆は自分のように忙しくしている人ばかりではないとは考えなかったようである。
コンピュータのプロやセミプロたちは、Windowsを批判した。私もその一人だった。しかし、コンピュータの大衆化に最も貢献したのはWindowsだということは、今や誰もが認めることであろう。
これらからわかることは、博識な人や専門家がだめだと言ったものがだめだとは限らないということである。良いかだめかを決めるのは、一部の偉い人ではなく、大衆である。これら普及したものに共通することは、大衆に貢献するために大きな努力が払われてきたことである。一部の偉い人が何と言おうと、継続した努力で大衆のニーズに応えたものが勝つのである。
私も、スパムの被害を食い止めたいと願う人たちのニーズに応えるために努力を続けてきた。決してS25R方式を広めたかったわけではなく、スパムに困っている人たちを助けたかった。スパムに困っている人たちとのコミュニケーションを大切にし、質問には必ず答えている。シェルスクリプトを使ったこともない人をサポートしたこともある。協力者から情報を集めて公開ホワイトリストを提供している。こうした活動を地道に続けている。だから、一部の人たちの批判にもかかわらず、多くの人たちの支持を集め、S25R方式は広まった。
私のアイデアは、おそらく1000人以上のメールシステム管理者を助けた。そして、何万人ものメールユーザーをスパムの被害から救った。S25R方式を採用したメールシステム管理者は私に感謝してくれているだろうが、スパムの被害がないのを当たり前と思っているユーザーは、私の功績を知らないかもしれない。私はそれでいいのである。スパムの被害がないのを当たり前にしたことが私の誇りである。
あなたは、プロに褒められる仕事を目指してはいないだろうか。そうではなく、自分の仕事で大衆を幸せにすることを目指すべきである。料理人について言えば、一部の美食家に褒められる料理ではなく、素人のお客さんを喜ばせる料理を目指すべきである。一部の人の批判にくじけることはない。大衆を幸せにしたら、プロもあなたの仕事を認めざるを得なくなる。その時、あなたは勝者なのである。
普及したものを当初批判した人たち 阿川弘之 ・・・ 新幹線 糸川英夫 ・・・ 家庭用VTR コンピュータのプロやセミプロたち ・・・ Windows 継続した努力で大衆のニーズに応えたものが勝つ。 |
話題がS25R方式から離れているので、私の講演を聴いた人以外には、このスライドを見るだけでは理解しにくいかもしれない。そこで、私がこのスライドに込めた意図を説明する。
S25R方式は、批判を受けながらも、発表後5年を経て多くのサイトで採用されるようになった。導入サイト数は1000以上と推定される。S25R方式に対して「こんなものはだめだ」と言っていた人たちは、S25R方式の成功を予見できなかったということである。
同じように、普及したものの中には当初批判されていたものがあった。
作家の阿川弘之氏は、「これからはモータリゼーションと航空機の時代で、鉄道は過去の遺物だ」と言って新幹線建設を批判した。後に新幹線が鉄道斜陽論を覆すに至った時、彼は「私が間違っていた」と言った。
ロケット工学者の糸川英夫氏は、著書の中で「家庭用VTRは普及しないだろう」と言っていた。忙しい人はテレビ番組を録画しておいて後で見ることができるとはいっても、忙しい人はその時間さえないからだと言う。大衆は自分のように忙しくしている人ばかりではないとは考えなかったようである。
コンピュータのプロやセミプロたちは、Windowsを批判した。私もその一人だった。しかし、コンピュータの大衆化に最も貢献したのはWindowsだということは、今や誰もが認めることであろう。
これらからわかることは、博識な人や専門家がだめだと言ったものがだめだとは限らないということである。良いかだめかを決めるのは、一部の偉い人ではなく、大衆である。これら普及したものに共通することは、大衆に貢献するために大きな努力が払われてきたことである。一部の偉い人が何と言おうと、継続した努力で大衆のニーズに応えたものが勝つのである。
私も、スパムの被害を食い止めたいと願う人たちのニーズに応えるために努力を続けてきた。決してS25R方式を広めたかったわけではなく、スパムに困っている人たちを助けたかった。スパムに困っている人たちとのコミュニケーションを大切にし、質問には必ず答えている。シェルスクリプトを使ったこともない人をサポートしたこともある。協力者から情報を集めて公開ホワイトリストを提供している。こうした活動を地道に続けている。だから、一部の人たちの批判にもかかわらず、多くの人たちの支持を集め、S25R方式は広まった。
私のアイデアは、おそらく1000人以上のメールシステム管理者を助けた。そして、何万人ものメールユーザーをスパムの被害から救った。S25R方式を採用したメールシステム管理者は私に感謝してくれているだろうが、スパムの被害がないのを当たり前と思っているユーザーは、私の功績を知らないかもしれない。私はそれでいいのである。スパムの被害がないのを当たり前にしたことが私の誇りである。
あなたは、プロに褒められる仕事を目指してはいないだろうか。そうではなく、自分の仕事で大衆を幸せにすることを目指すべきである。料理人について言えば、一部の美食家に褒められる料理ではなく、素人のお客さんを喜ばせる料理を目指すべきである。一部の人の批判にくじけることはない。大衆を幸せにしたら、プロもあなたの仕事を認めざるを得なくなる。その時、あなたは勝者なのである。
ホワイトリストへの先回り登録は必要か？
8月29日の講演の時、参加者から「S25Rに引っかかるサーバ事業者がたくさんあるので、調査してホワイトリストに登録した方がよい」というコメントをいただいた。その時は「コメントありがとうございます」と答えたのだが、その後考えてみた。
公開ホワイトリストが充実すればするほど、それを取り込んだサイトでは偽陽性判定の頻度を下げることができる。最近、大規模サイトの協力者が現れたおかげで、登録件数は700件ほどになっているが、S25Rに引っかかる未登録のメールサーバはもちろんまだまだ多いだろう。私か協力者が発見したホストを登録するだけでなく、サーバに連番入りの逆引き名を付けているサーバ事業者を探し出してホワイトリストに先回り登録しておけば、偽陽性判定をさらに避けることができる。
しかし、私がそこまで手間をかけるべきだろうか。私の個人サイトでは偽陽性判定はめったに起こらない。大規模サイトの協力者からホワイトリスト情報が寄せられる頻度も減ってきたことから、協力者のサイトでも偽陽性判定の頻度が減っていると思われる。おそらく、S25R方式を採用しているサイトのほとんどでは、偽陽性判定の頻度は低くなっているであろう。だから、私がホワイトリストへの先回り登録をしなくても誰も困っていないということである。そして、私がそれをしても、偽陽性判定の確率をゼロにすることは不可能である。どのみち、偽陽性判定の監視あるいは自動救済が不要になることはないのである。
それに、サーバを含むIPアドレス帯が、サーバ事業者が管理するサーバ群なのか、ユーザーに割り当てられた固定IPアドレスの回線なのかを区別することは難しい。固定IPアドレスだからといって一律にホワイトリスト登録するとそこからスパムが来ることもわかっている。
やってもやらなくても同じことなら、やる必要はない。それに、「スパムを許可してしまうホワイトリスト」として信用を失うくらいなら、やらない方がよい。今までどおり、私が偽陽性判定を発見したか協力者から情報が寄せられた時に登録するつもりである。
ちなみに、「申告されたホワイトリスト情報を受理する基準はあるのですか」という質問が掲示板に寄せられたことがある。「申告があればすべて載せています」が回答である。メールか掲示板による、私とのコミュニケーションを通じて寄せられたホワイトリスト情報はすべて信用するというのが私のポリシーである。CGIによる自動受付は考えていない。ホワイトリスト情報の申告に人とのコミュニケーションを介する必要がなくなれば、不正な情報を入力する奴は当然現れると予想されるからである。
公開ホワイトリストが充実すればするほど、それを取り込んだサイトでは偽陽性判定の頻度を下げることができる。最近、大規模サイトの協力者が現れたおかげで、登録件数は700件ほどになっているが、S25Rに引っかかる未登録のメールサーバはもちろんまだまだ多いだろう。私か協力者が発見したホストを登録するだけでなく、サーバに連番入りの逆引き名を付けているサーバ事業者を探し出してホワイトリストに先回り登録しておけば、偽陽性判定をさらに避けることができる。
しかし、私がそこまで手間をかけるべきだろうか。私の個人サイトでは偽陽性判定はめったに起こらない。大規模サイトの協力者からホワイトリスト情報が寄せられる頻度も減ってきたことから、協力者のサイトでも偽陽性判定の頻度が減っていると思われる。おそらく、S25R方式を採用しているサイトのほとんどでは、偽陽性判定の頻度は低くなっているであろう。だから、私がホワイトリストへの先回り登録をしなくても誰も困っていないということである。そして、私がそれをしても、偽陽性判定の確率をゼロにすることは不可能である。どのみち、偽陽性判定の監視あるいは自動救済が不要になることはないのである。
それに、サーバを含むIPアドレス帯が、サーバ事業者が管理するサーバ群なのか、ユーザーに割り当てられた固定IPアドレスの回線なのかを区別することは難しい。固定IPアドレスだからといって一律にホワイトリスト登録するとそこからスパムが来ることもわかっている。
やってもやらなくても同じことなら、やる必要はない。それに、「スパムを許可してしまうホワイトリスト」として信用を失うくらいなら、やらない方がよい。今までどおり、私が偽陽性判定を発見したか協力者から情報が寄せられた時に登録するつもりである。
ちなみに、「申告されたホワイトリスト情報を受理する基準はあるのですか」という質問が掲示板に寄せられたことがある。「申告があればすべて載せています」が回答である。メールか掲示板による、私とのコミュニケーションを通じて寄せられたホワイトリスト情報はすべて信用するというのが私のポリシーである。CGIによる自動受付は考えていない。ホワイトリスト情報の申告に人とのコミュニケーションを介する必要がなくなれば、不正な情報を入力する奴は当然現れると予想されるからである。
土曜日, 9月 12, 2009
「阻止率97～99%」と記載
S25Rホームページに掲載しているS25R方式の要点の説明に
●スパムとウィルスメールの全アクセスに対する阻止率約99%。
●宛先の正しいスパムの阻止率97%以上。
と書いていたが、
●スパムやウィルスメールの阻止率97～99%。
と書き直した。
おとりのアドレスやでたらめのアドレスに宛てたスパムを含む全アクセスに対する阻止率は、論文に記載している2004年4月の統計では99.1%だった。2006年7月にも99.1%だった。ところが、宛先の正しいスパムについての阻止率はやや低くて、同月で97.4%だったことがわかった。そこで、誇大広告にならないように二つのデータを併記していた。
その後何度か、宛先の正しいスパムの阻止率のデータをとっていたところ、97%を下回ることはなく、2009年4月26日から5月30日までの期間には、SPAMCOPの併用による効果を除いても99.2%の阻止率を達成していた。だから、宛先の正しいスパムについても阻止率は97～99%だと言っても嘘ではない。講演資料には「阻止率97～99%」と記載した。
宛先の正しいスパムについても「阻止率97～99%」が誇大広告にならないことがデータの蓄積によってわかっているので、こう書いた方が、二つのデータを併記するよりもわかりやすいだろう。
●スパムとウィルスメールの全アクセスに対する阻止率約99%。
●宛先の正しいスパムの阻止率97%以上。
と書いていたが、
●スパムやウィルスメールの阻止率97～99%。
と書き直した。
おとりのアドレスやでたらめのアドレスに宛てたスパムを含む全アクセスに対する阻止率は、論文に記載している2004年4月の統計では99.1%だった。2006年7月にも99.1%だった。ところが、宛先の正しいスパムについての阻止率はやや低くて、同月で97.4%だったことがわかった。そこで、誇大広告にならないように二つのデータを併記していた。
その後何度か、宛先の正しいスパムの阻止率のデータをとっていたところ、97%を下回ることはなく、2009年4月26日から5月30日までの期間には、SPAMCOPの併用による効果を除いても99.2%の阻止率を達成していた。だから、宛先の正しいスパムについても阻止率は97～99%だと言っても嘘ではない。講演資料には「阻止率97～99%」と記載した。
宛先の正しいスパムについても「阻止率97～99%」が誇大広告にならないことがデータの蓄積によってわかっているので、こう書いた方が、二つのデータを併記するよりもわかりやすいだろう。
日曜日, 9月 06, 2009
講演資料を掲載
ブログの更新がすっかりお留守になっていた間の8月29日に、「第9回まっちゃ445勉強会」でS25R方式についての講演をさせていただいた。事前にこの場で告知しなくてすみません。
その時の講演スライドをPDFにしてS25Rホームページに掲載した。英訳版も掲載した。
掲載が遅くなったのは、S25Rホームページのコンテンツは日英二ヶ国語で同じにしなければ気持ち悪いという強迫症のせいである。
勉強会では、RgreyやtaRgreyの開発者の佐藤さんをはじめ、スパム対策の第一人者の方たちとお会いすることができた。また、掲示板でホワイトリスト情報をお寄せくださったことがあるsuzukiさんともお会いした。
その時の講演スライドをPDFにしてS25Rホームページに掲載した。英訳版も掲載した。
掲載が遅くなったのは、S25Rホームページのコンテンツは日英二ヶ国語で同じにしなければ気持ち悪いという強迫症のせいである。
勉強会では、RgreyやtaRgreyの開発者の佐藤さんをはじめ、スパム対策の第一人者の方たちとお会いすることができた。また、掲示板でホワイトリスト情報をお寄せくださったことがあるsuzukiさんともお会いした。
日曜日, 6月 14, 2009
やむなく「554」で蹴っていると言うサイト
メールサーバの逆引き名がS25Rに引っかかる会社から、S25Rによる不達問題に遭遇したからメールサーバを公開ホワイトリストに掲載してほしいと要請された。
メールに書かれていた受信拒否のログを見ると、応答コード「554」で蹴られていた。受信側の会社は、あるホスティング事業者のサービスを利用していて、蹴られるようになったのは最近のことだという。
そのホスティング事業者にメールを送って、「554」で蹴らないように要請した。回答はこうであった。システムの移行でユーザーが大幅に増加し、スパムアクセスも増えて、MXサーバに予想を上回る負荷がかかり、メールの遅延が発生した。そこでMXサーバにスパムフィルタを入れた。その中にS25Rの条件も含まれていた。応答コードを「450」にしたら大量のスパムアクセスの再送があり、新規セッションを受け付けられない状態になってしまった。そのため、やむなく応答コードを「554」にせざるを得なかった。タールピッティングとグレイリスティングの実装を準備しており、7月には実装する予定である。
緊急事態だと言われれば、それでも「450」にしてくださいとは言えない。その代わり、クライアント制限に優先して受理される連絡用メールアドレス、または連絡用入力フォームのURLを拒否メッセージに含めてほしいと要請した。入力フォームのURLを含める方向で検討すると回答してくれた。
これを読んで「そうか。その手を使えば、偽陽性判定された送信者からの申告を待っていればよくて、ログを監視する必要はなくなるな」とは思わないでほしい。それは浅はかな考えである。メールを送信するのは人間だけではない。オンラインショッピングの確認メールやメールマガジンのメールなどを「5xx」で蹴飛ばしたら、送信側サイトの管理者がいちいちホワイトリスト登録を申請して再送してくれたりはしない。メーリングリストの場合も、メーリングリスト管理者が受信拒否による不達に対処してくれない可能性が高い。それらのメールが不達になれば、自サイトの受信者の不利益になる。偽陽性判定からの救済はあくまでも、送信者に手間をかけさせずに受信側で行わなければならない。
メールに書かれていた受信拒否のログを見ると、応答コード「554」で蹴られていた。受信側の会社は、あるホスティング事業者のサービスを利用していて、蹴られるようになったのは最近のことだという。
そのホスティング事業者にメールを送って、「554」で蹴らないように要請した。回答はこうであった。システムの移行でユーザーが大幅に増加し、スパムアクセスも増えて、MXサーバに予想を上回る負荷がかかり、メールの遅延が発生した。そこでMXサーバにスパムフィルタを入れた。その中にS25Rの条件も含まれていた。応答コードを「450」にしたら大量のスパムアクセスの再送があり、新規セッションを受け付けられない状態になってしまった。そのため、やむなく応答コードを「554」にせざるを得なかった。タールピッティングとグレイリスティングの実装を準備しており、7月には実装する予定である。
緊急事態だと言われれば、それでも「450」にしてくださいとは言えない。その代わり、クライアント制限に優先して受理される連絡用メールアドレス、または連絡用入力フォームのURLを拒否メッセージに含めてほしいと要請した。入力フォームのURLを含める方向で検討すると回答してくれた。
これを読んで「そうか。その手を使えば、偽陽性判定された送信者からの申告を待っていればよくて、ログを監視する必要はなくなるな」とは思わないでほしい。それは浅はかな考えである。メールを送信するのは人間だけではない。オンラインショッピングの確認メールやメールマガジンのメールなどを「5xx」で蹴飛ばしたら、送信側サイトの管理者がいちいちホワイトリスト登録を申請して再送してくれたりはしない。メーリングリストの場合も、メーリングリスト管理者が受信拒否による不達に対処してくれない可能性が高い。それらのメールが不達になれば、自サイトの受信者の不利益になる。偽陽性判定からの救済はあくまでも、送信者に手間をかけさせずに受信側で行わなければならない。
金曜日, 6月 05, 2009
副作用の被害者には誠心誠意
メールサーバの逆引き名がISPドメインの連番入りになっている会社から問い合わせを受けた。2社へのメールが送達せず、調査していて私のサイトを知ったとのこと。
その2社へ私からメールを送ってホワイトリスト登録を要請してあげて感謝された。
うち1社へのメールはリトライ中で、私がメールを送ったらほどなく送達したそうである。もう1社へのメールは、5日でリトライアウトしたとのこと。ログを見ていなかったようである。ウェブサイトに掲載されたメールアドレスへメールを送ったらuser unknownになったので、電話をかけて対処してもらってからメールを送り直した。
また、「自社ドメインの逆引き名をDNSに設定しているのに、ISPドメインの逆引き名が検索されるのは、意図していたことと違っている」とおっしゃるので、「逆引きゾーンがISPから委譲されていないからです」と説明した。「おかげでネットワークの請負会社ときちんと話ができました」と感謝された。
S25R方式の副作用の被害を受けたのだから、苦情を言われても不思議はないのに、感謝されてよかった。
それにしても、S25R方式を使うならちゃんとログを見てほしい。
その2社へ私からメールを送ってホワイトリスト登録を要請してあげて感謝された。
うち1社へのメールはリトライ中で、私がメールを送ったらほどなく送達したそうである。もう1社へのメールは、5日でリトライアウトしたとのこと。ログを見ていなかったようである。ウェブサイトに掲載されたメールアドレスへメールを送ったらuser unknownになったので、電話をかけて対処してもらってからメールを送り直した。
また、「自社ドメインの逆引き名をDNSに設定しているのに、ISPドメインの逆引き名が検索されるのは、意図していたことと違っている」とおっしゃるので、「逆引きゾーンがISPから委譲されていないからです」と説明した。「おかげでネットワークの請負会社ときちんと話ができました」と感謝された。
S25R方式の副作用の被害を受けたのだから、苦情を言われても不思議はないのに、感謝されてよかった。
それにしても、S25R方式を使うならちゃんとログを見てほしい。
日曜日, 5月 31, 2009
ホワイトリスト情報の報告がまた増えた
2月28日に、ホワイトリスト情報の報告が減ったことを述べた。2009年に入ってから公開ホワイトリストに追加した項目は、1月に1件、2月にはなし、その後、3月に4件、4月に3件と少なかった。ところが、5月に入って34件とまた増えた。
これは多分こういうことだろう。
これまでは、ホワイトリスト情報は主に小規模サイトから寄せられていた。大規模サイトでは、自動救済をしていることが多いだろうし、偽陽性判定が頻発するので報告が大変だから、あまり報告されなかったのだろう。
2008年終わりから2009年初めにかけて報告が少なくなったころ、公開ホワイトリストは小規模サイトにはほぼ十分なものになった。大規模サイトでは、それでもなお偽陽性判定は起こるが、頻度は少なくなり、報告が大変でなくなった。そのため、大規模サイトからホワイトリスト情報が寄せられるようになった。
5月下旬に掲示板で多くのホワイトリスト情報をお寄せくださったhoutokuさんのサイトは、メールアカウント数が約600とのこと。taRgreyで自動救済されたホストのうち、素性が明らかで正当なメールサーバだと確認されたものを、無期限に許可するためにホワイトリスト登録していた。このホワイトリストはサイトローカルなものにしておくのでなく公開した方がよいと思い立って、私に登録を申請してくださるようになった。そして、私がどのような正規表現にするのがよいかを判断して公開ホワイトリストに掲載したら、それをダウンロードして自サイトのホワイトリストとして利用されている。
つまり、公開ホワイトリストにブレークスルーが起こり、より大規模なサイトでも偽陽性判定を減らすことができるものへ成長し始めたということである。houtokuさんら常連ゲストの方々からの報告が減るころには、数百人規模のサイトでも偽陽性判定をめったに起こさないホワイトリストになるだろう。もしかしたら、さらにその後、数千人規模のサイトからホワイトリスト情報が寄せられるようになるかもしれない。
これは多分こういうことだろう。
これまでは、ホワイトリスト情報は主に小規模サイトから寄せられていた。大規模サイトでは、自動救済をしていることが多いだろうし、偽陽性判定が頻発するので報告が大変だから、あまり報告されなかったのだろう。
2008年終わりから2009年初めにかけて報告が少なくなったころ、公開ホワイトリストは小規模サイトにはほぼ十分なものになった。大規模サイトでは、それでもなお偽陽性判定は起こるが、頻度は少なくなり、報告が大変でなくなった。そのため、大規模サイトからホワイトリスト情報が寄せられるようになった。
5月下旬に掲示板で多くのホワイトリスト情報をお寄せくださったhoutokuさんのサイトは、メールアカウント数が約600とのこと。taRgreyで自動救済されたホストのうち、素性が明らかで正当なメールサーバだと確認されたものを、無期限に許可するためにホワイトリスト登録していた。このホワイトリストはサイトローカルなものにしておくのでなく公開した方がよいと思い立って、私に登録を申請してくださるようになった。そして、私がどのような正規表現にするのがよいかを判断して公開ホワイトリストに掲載したら、それをダウンロードして自サイトのホワイトリストとして利用されている。
つまり、公開ホワイトリストにブレークスルーが起こり、より大規模なサイトでも偽陽性判定を減らすことができるものへ成長し始めたということである。houtokuさんら常連ゲストの方々からの報告が減るころには、数百人規模のサイトでも偽陽性判定をめったに起こさないホワイトリストになるだろう。もしかしたら、さらにその後、数千人規模のサイトからホワイトリスト情報が寄せられるようになるかもしれない。
土曜日, 5月 30, 2009
SPAMCOPの併用の効果
4月29日にSPAMCOPの併用を開始した。4月26日から5月30日22時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は偽陽性判定を除いて1582、この期間に着信したスパムは8通。したがって阻止率は99.5%となった。
S25Rをすり抜けてSPAMCOPでブロックされたスパムは5通あった。これらが着信していたとすると、阻止率は99.2%である。これもけっこう高い値だが、SPAMCOPの併用でさらに0.3%上がったことになる。SPAMCOPによる偽陽性判定は起こっていない。
S25Rでブロックされたホストの中には、論文に示していない追加の一般規則とブラックリストで引っかかったものがあった。そのうち以下に○で示したものはSPAMCOPに登録されていた。
つまり、追加の一般規則とブラックリストがなかったとしても、4通のうち3通はSPAMCOPでブロックできたということである。
SPAMCOPの併用はかなり役に立つ。一方、今までにスパムアクセスをしてきたホストをRBL.JPのBlack list DB checkで調べたところでは、RBL.JPに登録されていたことは数えるほどしかなく、spamhausに登録されていたのを見たことは一度もない。
S25Rをすり抜けてSPAMCOPでブロックされたスパムは5通あった。これらが着信していたとすると、阻止率は99.2%である。これもけっこう高い値だが、SPAMCOPの併用でさらに0.3%上がったことになる。SPAMCOPによる偽陽性判定は起こっていない。
S25Rでブロックされたホストの中には、論文に示していない追加の一般規則とブラックリストで引っかかったものがあった。そのうち以下に○で示したものはSPAMCOPに登録されていた。
| router.shtorm.com [195.62.14.1] | ○ |
| pursuant.age.volia.net [77.122.227.132] | |
| smatteringness-warmth.volia.net [77.123.102.225] | ○ |
| devoted-parlayer.volia.net [93.74.8.151] | ○ |
つまり、追加の一般規則とブラックリストがなかったとしても、4通のうち3通はSPAMCOPでブロックできたということである。
SPAMCOPの併用はかなり役に立つ。一方、今までにスパムアクセスをしてきたホストをRBL.JPのBlack list DB checkで調べたところでは、RBL.JPに登録されていたことは数えるほどしかなく、spamhausに登録されていたのを見たことは一度もない。
金曜日, 5月 15, 2009
スパム送信サーバが13時間リトライ
次のようなリトライアクセスがあった。
May 13 17:44:51 unknown [81.91.67.81] from=<ohflpiciqvMeredith@***.com> to=<deo@gabacho-net.jp> helo=<81.91.67.81>
May 13 17:52:05 〃
May 13 18:12:46 〃
May 13 18:46:47 〃
May 13 19:34:07 〃
May 13 20:34:48 〃
May 13 21:48:49 〃
May 13 23:16:29 〃
May 14 00:56:51 〃
May 14 02:50:52 〃
May 14 04:58:12 〃
May 14 07:18:54 〃
送信者アドレスのユーザーIDがでたらめっぽいのがいかにも怪しい。HELOアドレスがIPアドレスなのに「[ ]」で囲んでいないのがいかにも怪しい。私がウェブで公開しているアドレスは「webmaster」なので、私の知らない人から初めて来るメールは通常「webmaster」に宛てられるのに、「deo」宛なのも怪しい。
スパムに違いないとにらんで放置プレイを食らわせてみたら、リトライアクセスは13時間34分で止まった。
送信元にSMTPアクセスしてみたら、MTAが応答した。ボットでなくメールサーバだった。まともなメールサーバならば24時間やそこらであきらめたりはしないのが普通だが（Postfixやsendmailのデフォルト設定で5日間）、14時間未満でリトライが止まったのは、スパム送信用にチューンしたサーバだからだろう。
人間の知識と経験に基づいて「怪しい」とにらむ判断は、今のところ、機械に任せるのがむずかしい。この職人芸で、長時間リトライするスパムアクセスを放置する。正当なメールサーバがリトライを1時間ほどでやめてしまうというレアケース（私が見つけているのは、メールマガジン、携帯電話会社からのエラーリターンのケース）を除けば、怪しいとにらんだリトライアクセスが24時間未満で止まったらスパムだったと判断してほぼ間違いない。S25R方式を素のまま使っていると、こういうサディスティックなプレイができて面白い。
May 13 17:44:51 unknown [81.91.67.81] from=<ohflpiciqvMeredith@***.com> to=<deo@gabacho-net.jp> helo=<81.91.67.81>
May 13 17:52:05 〃
May 13 18:12:46 〃
May 13 18:46:47 〃
May 13 19:34:07 〃
May 13 20:34:48 〃
May 13 21:48:49 〃
May 13 23:16:29 〃
May 14 00:56:51 〃
May 14 02:50:52 〃
May 14 04:58:12 〃
May 14 07:18:54 〃
送信者アドレスのユーザーIDがでたらめっぽいのがいかにも怪しい。HELOアドレスがIPアドレスなのに「[ ]」で囲んでいないのがいかにも怪しい。私がウェブで公開しているアドレスは「webmaster」なので、私の知らない人から初めて来るメールは通常「webmaster」に宛てられるのに、「deo」宛なのも怪しい。
スパムに違いないとにらんで放置プレイを食らわせてみたら、リトライアクセスは13時間34分で止まった。
送信元にSMTPアクセスしてみたら、MTAが応答した。ボットでなくメールサーバだった。まともなメールサーバならば24時間やそこらであきらめたりはしないのが普通だが（Postfixやsendmailのデフォルト設定で5日間）、14時間未満でリトライが止まったのは、スパム送信用にチューンしたサーバだからだろう。
人間の知識と経験に基づいて「怪しい」とにらむ判断は、今のところ、機械に任せるのがむずかしい。この職人芸で、長時間リトライするスパムアクセスを放置する。正当なメールサーバがリトライを1時間ほどでやめてしまうというレアケース（私が見つけているのは、メールマガジン、携帯電話会社からのエラーリターンのケース）を除けば、怪しいとにらんだリトライアクセスが24時間未満で止まったらスパムだったと判断してほぼ間違いない。S25R方式を素のまま使っていると、こういうサディスティックなプレイができて面白い。
*.cust.bit-drive.ne.jpの丸ごと許可を取り消し
前回、*.cust.bit-drive.ne.jpを丸ごと許可するようにしたことを報告したが、個別許可に戻した。掲示板のゲストのKenjiさんから、*.cust.bit-drive.ne.jpがスパム送信サーバに使われているとの報告をいただいたからである。
以下は、Kenjiさんの記事の引用。Kenjiさんのサイトで複数のユーザーからスパムの申告があった送信元ホストだけでこれだけあるとのことである。
以下は、Kenjiさんの記事の引用。Kenjiさんのサイトで複数のユーザーからスパムの申告があった送信元ホストだけでこれだけあるとのことである。
| 202.94.129.36 から yahoo.co.jp を騙ったspam 202.94.129.226 から yahoo.co.jp を騙ったspam 202.94.147.83 から 出会い系（オプトインかどうかは不明） 202.94.153.85 から yahoo.co.jp を騙ったspam 202.94.153.86 から yahoo.co.jp を騙ったspam 202.94.153.87 から yahoo.co.jp を騙ったspam 202.94.153.197 から yahoo.co.jp を騙ったspam 210.172.21.90 から yahoo.co.jp を騙ったspam 210.172.31.190 から yahoo.co.jp を騙ったspam 210.172.31.191 から yahoo.co.jp を騙ったspam 211.9.45.148 から yahoo.co.jp を騙ったspam 211.9.50.239 から 出会い系（オプトインかどうかは不明） 219.106.230.243 から 出会い系のspam 219.106.230.245 から 出会い系（オプトインかどうかは不明） 219.106.230.253 から 出会い系（オプトインかどうかは不明） 61.45.193.225 から yahoo.co.jp を騙ったspam |
月曜日, 5月 11, 2009
*.cust.bit-drive.ne.jpを丸ごと許可
今まで、210-172-21-218.cust.bit-drive.ne.jp (wserver.alliance.co.jp)をはじめ、cust.bit-drive.ne.jp配下のホストを、発見されるたびに一つ一つ公開ホワイトリストに登録していたが、掲示板のゲストのPyTaさんのご提案により、*.cust.bit-drive.ne.jpを丸ごと信用する許可条件に集約した。bit-driveは法人向けのインターネット接続サービスで、ボット化するエンドユーザーコンピュータはつながっていないだろうと思われ、実際、*.cust.bit-drive.ne.jpから不正メールアクセスが来たことはないからである。
過去に掲載していた*.cust.bit-drive.ne.jpの許可条件は、しばらくコメントアウトで示しておくことにする。
過去に掲載していた*.cust.bit-drive.ne.jpの許可条件は、しばらくコメントアウトで示しておくことにする。
| # *** PUBLISHED S25R WHITE LIST *** # Last update: May 11, 2009 # (*): reported by a contributor # # May 11, 2009: mail.ebookoff.co.jp (202-94-136-109.cust.bit-drive.ne.jp) (*) /\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Mar 15, 2009: (revised) # Feb 03, 2008: mag.jobengine.jp (*) #/^219-106-251-106\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Apr 15, 2008: legacy.transcend.co.jp (*) #/^219-118-179-4\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Mar 26, 2008: mail.dss-net.co.jp (*) #/^218-42-147-99\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Mar 14, 2008: ns.ict-ics.com #/^210-175-254-69\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Feb 03, 2008: mail.furuhonn.com (*) #/^219-118-164-66\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Jan 14, 2008: ns.betterhome.co.jp (*) #/^219-106-250-226\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Dec 14, 2007: nbn.co.jp's (*) #/^210-251-250-78\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Dec 14, 2007: greeting-card.jp (*) #/^210-251-251-204\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Nov 29: 2007: ig3.jp's (*) #/^218-42-159-113\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Jun 19, 2007: mail.ifscorp.co.jp #/^210-175-254-67\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Feb 08, 2007: tachikawa-roukikyo.or.jp (*) #/^219-118-191-144\.cust\.bit-drive\.ne\.jp$/ OK # # May 11, 2009: (aggregated) # Nov 24, 2004: wserver.alliance.co.jp (*) #/^210-172-21-218\.cust\.bit-drive\.ne\.jp$/ OK |
水曜日, 5月 06, 2009
君子は豹変するのだ
2006年11月24日「DNSBLの利用価値はあるか？」で「DNSBLを使う積極的理由は見出せない」と述べてから2年5ヶ月たってそろそろ舌の根が乾いた今、SPAMCOPの併用実験を開始した。S25Rをすり抜けるスパムをDNSBLでブロックできる率について、ある程度定量的なデータが得られたからである。
「DNSBLの利用価値はあるか？」の記事では、「S25Rの偽陽性を減らすためにDNSBLを併用すると、阻止率はかなり下がってしまうのではないか」と述べた。これは正しかった。ウェブで見つけた証言によると、SPAMCOPによる阻止率は50～60%程度。DNSBLの応用であるトレンドマイクロのEmailレピュテーションで70%程度。阻止率はその程度に下がってしまい、S25R方式の高い防御力が無駄になってしまう。
一方、「阻止率を上げるためにS25RにDNSBLを併用しても、阻止率が大きく向上することはないだろう」と述べた。確かに大きく向上するとは言えないが、98.8%の阻止率はSPAMCOPの併用で99.2%程度に上がるという見積もりが得られた。「むしろ偽陽性が増えるおそれがある」とも述べたが、それはあまり心配しなくてよさそうである。蹴る時の応答コードを「450」に設定して再送要求すれば、偽陽性からの救済はS25R方式の運用と同じ手順でできる。4月29日にSPAMCOPの併用を設定してから5月6日までに、S25Rをすり抜けたホスト4個のうち、SPAMCOPで阻止されたホストは3個。その中にリトライしたものはなく、偽陽性判定はまだ起こっていない。SPAMCOPはそこそこ役に立っていると言える。
私の場合、S25Rをすり抜けて着信するスパムは一日平均1通もなく、スパムを捨てる手間はまったく問題になっていない。だから、スパムの受信を減らすためにこれ以上がんばる必要はない。ただ、S25R方式で99%近いスパムを阻止できてもなおスパムの受信が多い人にノウハウが役立つかもしれないと思って、SPAMCOPの併用実験をやっている。
正当なメールをエラーリターンさせる副作用ゆえに「DNSBLを使ってはいけない」という主張もあるが、物は使いようである。多少とも効果があり、副作用を克服できるなら、使えばよいと思う。副作用を克服するには、S25Rと同じくDNSBLによるブロックでも再送要求を返し、ログを監視して、リトライするメールサーバをホワイトリストで救済すればよい。それが、S25R方式と同じく、スキルの高くない人でも容易に実装・運用できる方法である。知識だけであれこれ言うのでなく、知恵を働かせればよい。
抗がん剤にはがん細胞だけでなく正常細胞も殺す副作用があるが、だからといって抗がん剤を使ってはいけないなどとは言っていられない。知恵を働かせて副作用を克服できるならば、治療に有効な抗がん剤は使うべきである。それと同じことである。
「DNSBLの利用価値はあるか？」の記事では、「S25Rの偽陽性を減らすためにDNSBLを併用すると、阻止率はかなり下がってしまうのではないか」と述べた。これは正しかった。ウェブで見つけた証言によると、SPAMCOPによる阻止率は50～60%程度。DNSBLの応用であるトレンドマイクロのEmailレピュテーションで70%程度。阻止率はその程度に下がってしまい、S25R方式の高い防御力が無駄になってしまう。
一方、「阻止率を上げるためにS25RにDNSBLを併用しても、阻止率が大きく向上することはないだろう」と述べた。確かに大きく向上するとは言えないが、98.8%の阻止率はSPAMCOPの併用で99.2%程度に上がるという見積もりが得られた。「むしろ偽陽性が増えるおそれがある」とも述べたが、それはあまり心配しなくてよさそうである。蹴る時の応答コードを「450」に設定して再送要求すれば、偽陽性からの救済はS25R方式の運用と同じ手順でできる。4月29日にSPAMCOPの併用を設定してから5月6日までに、S25Rをすり抜けたホスト4個のうち、SPAMCOPで阻止されたホストは3個。その中にリトライしたものはなく、偽陽性判定はまだ起こっていない。SPAMCOPはそこそこ役に立っていると言える。
私の場合、S25Rをすり抜けて着信するスパムは一日平均1通もなく、スパムを捨てる手間はまったく問題になっていない。だから、スパムの受信を減らすためにこれ以上がんばる必要はない。ただ、S25R方式で99%近いスパムを阻止できてもなおスパムの受信が多い人にノウハウが役立つかもしれないと思って、SPAMCOPの併用実験をやっている。
正当なメールをエラーリターンさせる副作用ゆえに「DNSBLを使ってはいけない」という主張もあるが、物は使いようである。多少とも効果があり、副作用を克服できるなら、使えばよいと思う。副作用を克服するには、S25Rと同じくDNSBLによるブロックでも再送要求を返し、ログを監視して、リトライするメールサーバをホワイトリストで救済すればよい。それが、S25R方式と同じく、スキルの高くない人でも容易に実装・運用できる方法である。知識だけであれこれ言うのでなく、知恵を働かせればよい。
抗がん剤にはがん細胞だけでなく正常細胞も殺す副作用があるが、だからといって抗がん剤を使ってはいけないなどとは言っていられない。知恵を働かせて副作用を克服できるならば、治療に有効な抗がん剤は使うべきである。それと同じことである。
日曜日, 5月 03, 2009
SPAMCOPが効いた
4月29日にSPAMCOPを設定してみた。その後、5月3日までに、S25Rをすり抜けるスパムアクセスが3通あった。www.era.gov.etからの1通（4月30日）は着信したが、adsl.eb1-pacovchamarao.edu.ptから（4月30日）、syscom4.att.net.coから（5月1日）の2通がSPAMCOPでブロックされた。いずれも、応答コード「450」に対してリトライしなかった。
ほかに、81-208-74-142.ip.fastwebnet.itからのアクセス（5月3日）がS25Rに引っかかって8時間以上リトライしていて、多分スパムだろうと思って受信してみたら、やっぱりスパムだった。これはSPAMCOPに引っかからなかった。
4通のうち2通をSPAMCOPでブロックでき、リトライがなかったので、今のところ、SPAMCOPを設定してよかったと言える状況である。
ほかに、81-208-74-142.ip.fastwebnet.itからのアクセス（5月3日）がS25Rに引っかかって8時間以上リトライしていて、多分スパムだろうと思って受信してみたら、やっぱりスパムだった。これはSPAMCOPに引っかからなかった。
4通のうち2通をSPAMCOPでブロックでき、リトライがなかったので、今のところ、SPAMCOPを設定してよかったと言える状況である。
水曜日, 4月 29, 2009
SPAMCOPを設定してみた
前回、S25Rをすり抜けてスパムを着信させたホスト20個のうち7個（35%）がSPAMCOPのDNSBLに登録されていたことを述べた。このことから、すり抜けスパムを減らすためにSPAMCOPがどのくらい役立つかを調べてみたいと思った。
3月29日から4月29日18時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1274、この期間に着信したスパムは16通なので、ここから計算した阻止率は98.8%である。1.2%のすり抜けが、SPAMCOPによってその65%、すなわち1.2%×0.65≒0.8%に減れば、阻止率は99.2%に上がり、16通のすり抜けは10通程度に減る計算になる。
話はそううまくはいかないかもしれない。DNSBLによる偽陽性判定でメールをエラーリターンさせるわけにはいかないから、拒否応答コードを「450」に設定して再送要求する必要がある。S25Rをすり抜けてDNSBLに引っかかる送信元ホストはメールサーバである確率が比較的高いので、「450」に対してリトライしてくる可能性が高い。リトライしなかったアクセスはスパムだったと断定してよいが、メールサーバの挙動でリトライしてきたら、スパムかどうかは受けてみないと確認できない。もしS25Rをすり抜けてDNSBLに引っかかるホストの多くがリトライしてくるとしたら、受信して確認するためにホワイトリスト登録する手間が増える。一方、DNSBLが引っかけてくれるホストの多くがリトライしないボットであれば、阻止率をあと少し上げるのにDNSBLが役立つと考えられる。
ともかく、やってみることにした。
main.cfファイルに以下の太字の行を追加する。
（smtpd_client_restrictionsパラメータは私の実際の設定を示しているが、必須でない指定も含まれている。誰もがこのように設定すべきだという意味ではない。）
上記のように設定する前に、まずreject_rbl_client指定をS25Rチェックの前に置いて優先させることによって、DNSBLに引っかかった時のログがどうなるかを調べた。次のような記録がとれた。
このような記録が拒絶ログソーティングスクリプトで拾われるように、スクリプトを次のように手直しした。
↓
これでしばらく様子を見ることにする。
3月29日から4月29日18時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1274、この期間に着信したスパムは16通なので、ここから計算した阻止率は98.8%である。1.2%のすり抜けが、SPAMCOPによってその65%、すなわち1.2%×0.65≒0.8%に減れば、阻止率は99.2%に上がり、16通のすり抜けは10通程度に減る計算になる。
話はそううまくはいかないかもしれない。DNSBLによる偽陽性判定でメールをエラーリターンさせるわけにはいかないから、拒否応答コードを「450」に設定して再送要求する必要がある。S25Rをすり抜けてDNSBLに引っかかる送信元ホストはメールサーバである確率が比較的高いので、「450」に対してリトライしてくる可能性が高い。リトライしなかったアクセスはスパムだったと断定してよいが、メールサーバの挙動でリトライしてきたら、スパムかどうかは受けてみないと確認できない。もしS25Rをすり抜けてDNSBLに引っかかるホストの多くがリトライしてくるとしたら、受信して確認するためにホワイトリスト登録する手間が増える。一方、DNSBLが引っかけてくれるホストの多くがリトライしないボットであれば、阻止率をあと少し上げるのにDNSBLが役立つと考えられる。
ともかく、やってみることにした。
main.cfファイルに以下の太字の行を追加する。
| maps_rbl_reject_code = 450 smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/dracd, check_helo_access regexp:/etc/postfix/helo_restrictions, reject_unauth_destination, reject_unlisted_recipient, check_client_access regexp:/etc/postfix/white-list.txt, check_client_access regexp:/etc/postfix/white_list, check_client_access regexp:/etc/postfix/rejections, reject_rbl_client bl.spamcop.net |
上記のように設定する前に、まずreject_rbl_client指定をS25Rチェックの前に置いて優先させることによって、DNSBLに引っかかった時のログがどうなるかを調べた。次のような記録がとれた。
| Apr 29 11:27:56 reject: RCPT from 66.239.107.130.ptr.us.xo.net[66.239.107.130]: 450 4.7.1 Service unavailable; Client host [66.239.107.130] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.239.107.130; from=<***@elbloque.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<66.239.107.130.ptr.us.xo.net> |
このような記録が拒絶ログソーティングスクリプトで拾われるように、スクリプトを次のように手直しした。
| # (2) Extract records indicating "450 Client host rejected". # egrep 'reject:.+ 450 .*Client host rejected:' | \ |
| # (2) Extract records indicating "450 Client host rejected". # egrep 'reject:.+ 450 .*Client host (rejected:|.*blocked)' | \ |
これでしばらく様子を見ることにする。
登録:
投稿 (Atom)
