土曜日, 12月 19, 2009

HTTPデーモンがmaillogを読めるようにする方法

 私のサーバでは、rootにならなくてもメールログを見ることができるように、メールログファイルを「chmod a+r」していた。個人用のサーバなので、それでよかったのである。だから、拒絶ログソーティングスクリプトも問題なくメールログファイルを入力することができていた。
 しかし、考えてみたら、組織のメールサーバではメールログファイルを「chmod a+r」するわけにはいかない。一般ユーザーが他人のメールのやり取りの状況を知ることができてしまうからである。
 そこで、今さらながら、メールログファイルが一般ユーザーには読めずに、HTTPデーモンから起動されるスクリプトには読めるようにする方法の説明を追記した。このスクリプトを導入した皆さんのほとんどは自分で解決しておられたと思うが、S25R方式を導入する人の中にはPostfixのオペレーションがどうにかできるくらいのスキルレベルの人もいらっしゃるので、説明しておいた方がよいだろう。
 追記した文章は以下のとおりである。

必要な設定
 HTTPデーモンの権限でメールログファイルが読めるようにアクセス権を設定してください。多くのシステムでは、以下のコマンドで設定できます。

chgrp nobody /var/log/maillog*
chmod g+r /var/log/maillog*

 なお、ブラウザでスクリプトを動かすことができる人をメールシステム管理者に限定するには、当然ながら、スクリプトを置いたディレクトリに.htaccessファイルを置くことによってベーシック認証をかければよい。

月曜日, 11月 23, 2009

ルール0の説明を更新

 論文の3.1節「一般規則」での、ルール0の説明に、以下の下線部を付け加えた。

a. [ルール0] 逆引き失敗
 逆引き失敗の意味は、IPアドレスからFQDNを検索できないことだけでなく、逆引きFQDNの順引きの結果が元のIPアドレスに一致しない場合も含んでいる。
 逆引きが失敗するホストの大多数はエンドユーザーコンピュータである。インターネットにはエンドユーザーコンピュータの方がメールサーバよりはるかに多いので、当然である。

 逆引きができないということは、メールサーバかエンドユーザーコンピュータかを逆引き名の特徴から推定することができないということである。その場合もエンドユーザーコンピュータと推定して「450」を返すのはなぜかがわかるように説明を追記した。今まで、何かが書き足りないと意識の奥で感じていた。

日曜日, 11月 22, 2009

受信拒否された人のための説明ページ

 S25Rホームページに、「S25Rでメールが受信拒否された方へ」というページを設けた。S25R方式を導入したサイトへのメールが引っかかって送達遅延警告メッセージを受けた人や、受信側サイトがS25R方式を導入しながら再送アクセスを監視していないためについにエラー差し戻しを食らってしまった人に向けた説明である。S25R方式の間違った運用は私に通報してくださいと書いている。これにより、S25R方式の間違った運用の被害を受けた人は、問題の解決法を見つけやすくなるだろう。
 この説明ページの目的は、メールが受信拒否された送信者に問題の解決法を知らせることだけではない。S25R方式を調査しようとした人に

●S25R方式は正当なメールをエラーリターンさせるものではないこと
●正当なメールの送達に失敗したらそれは運用の間違いであること
●間違った運用があれば開発者が通報を受け付けること

を理解してもらうことも意図している。
 これまで、S25Rホームページのコンテンツはスパム対策の方法を説明するものばかりだった。今回初めて、スパム対策の副作用の被害者に向けたコンテンツを掲載した。このようなコンテンツの重要性にもっと早く気付けばよかった。

(追記)「S25Rでメールが受信拒否された方へ」の説明は、2010年5月17日にトップページへ移しました。

要点の説明を手直し

 S25Rホームページで、S25R方式の要点を次のように説明していた。

●逆引きできないクライアントを応答コード「450」(「後で再試行せよ」の意味)で拒否。
●逆引き名からメールサーバでないと推定されるクライアントを応答コード「450」で拒否。
●応答コード「450」による拒否に対して規則的に再試行する正当なメールサーバをホワイトリストで救済。

 これを、11月17日に次のように手直しした。

●逆引きに基づいてエンドユーザーコンピュータと推定したホストに再送要求(応答コード「450」)を返して受信拒否。
●メールサーバを誤判定した場合は再送アクセスが来るので、ホストをホワイトリスト登録して受信。

これは、講演のスライドに書いた文章と同じものである。
 以前の説明は、自サイトのメールサーバにどのような動作をさせるかという観点の文章だった。手直しした文章は、S25R方式のコンセプトの説明に重点を置いている。
 なぜこのように手直ししたかというと、「逆引きできないホストを蹴るのは悪いスパム対策方式だ」とかたくなに信じ込んでいる頭の固い人に批判されるのはつまらないと思ったからである。
 また、説明を受信拒否について1文、救済について1文としたことにより、受信拒否と救済が同じ重みに見えるということも狙っている。もちろん、S25R方式では偽陽性判定からの救済が重要だからである。

火曜日, 11月 17, 2009

paper.htmlへの直リンクでアラートを出す

 S25Rホームページには同じ内容の二つの論文ページがある。
 最初に公開したのはanti-spam-system.html。これが検索サイトに拾われ、多くのサイトから直リンクされるようになった。そのため、論文を一瞥しただけで「逆引きできないホストを蹴るとはけしからん」などと的外れな批判をする人たちが現れた。
 そこで、anti-spam-system.htmlにアクセスしたら「このページへ直接来られた方は、目次ページもご覧ください」というアラートがポップアップするようにした(2007年7月15日「びっくりページ」)。論文以外の情報も総合的に見てもらうためである。
 そして、アラートを出さないもう一つの論文ページpaper.htmlを設けた。目次ページから論文へたどった人も「目次ページもご覧ください」とアラートされてはわずらわしいからである。paper.htmlにはロボットよけのおまじないを入れて、検索サイトから直接来ないようにしている。また、目次ページで「左記のページ(paper.html)にはリンクしないでください。論文へのリンクはこちらのページ(anti-spam-system.html)にお願いします」と説明している。paper.htmlに直リンクされては、以前と同じことになってしまうからである。
 ところが、それでもpaper.htmlに直リンクする人が現れた。そこで、対策をとることにした。
 paper.htmlには、私のサイト内のリンクからたどった場合と、リファラ情報がない場合(URLを手動で打ち込んだ場合など)にのみアクセスできるようにする。他サイトからの直リンクで来た場合にはエラー403に落として、その際のエラードキュメントとしてanti-spam-system.htmlを返す。これにより、他サイトからpaper.htmlへの直リンクで来た人は、論文を見ることはできるが、実はそのファイルはanti-spam-system.htmlであって、「目次ページもご覧ください」とアラートされるというわけである。そこから目次ページへたどり、目次からもう一度論文(paper.html)へたどった時には、もうアラートされない。

 設定方法は以下のとおり。
 httpd.confファイルに以下の太字の部分を追記する。
<Directory "ドキュメントルートディレクトリ">

AllowOverride AuthConfig FileInfo Limit

</Directory>

 S25Rホームページのディレクトリには、以下のように記述した.htaccessファイルを置く。
<Files paper.html>
SetEnvIf Referer "^http://www\.gabacho-net\.jp" ShowOK
SetEnvIf Referer "^http://gabacho-net\.jp" ShowOK
SetEnvIf Referer "^http://gabacho\.reto\.jp" ShowOK
SetEnvIf Referer "^$" ShowOK
order deny,allow
deny from all
allow from env=ShowOK
ErrorDocument 403 /anti-spam/anti-spam-system.html
</Files>

 このブログ(http://s25r.blogspot.com/)は他サイト扱いなので、ここからpaper.htmlへ直リンクで行くとアラートされる。お試しください。

http://www.gabacho-net.jp/anti-spam/paper.html

(2010年5月18日追記)
 論文ページをはじめすべてのページに他ページへのインデックスを設け、アラートをやめました。paper.htmlからはanti-spam-system.htmlへ飛ばすようにしました。

日曜日, 11月 15, 2009

DNS逆引きチェックは有効なスパム(迷惑メール)対策

 S25R方式を理解している皆さんは「何を今さら」と思われるだろう。しかし、「スパム対策 逆引き」でググると、「DNS逆引きチェックによるスパム対策は百害あって一利無し」などという古臭い情報が今なお上位にヒットする。「百害あって一利無し」どころか「一害なくて百利あり」だということは、S25R方式を採用するサイトが推定1000以上あることで立証されているというのに。こういう主張をする人は、応答コード「4xx」による拒否に対するリトライアクセスが来ている間にホワイトリスト登録すればよいという簡単なアイデアにまったく気付いていない。そして、こういう情報を真に受けて、私のコンテンツをろくに読まずに、S25R方式は悪い対策だと決め付ける人もいる。
 一方、「当サイトは、逆引きできないホストからの受信を拒否する」と宣言して、それでメール送信ができない人に対しては「逆引きを設定するようにネットワーク管理者に言ってくれ」と言っている人もいる。エラー差し戻しの原因が理解できない素人さんのメールユーザーにはあまりにも不親切である。それに、reject_unknown_client指定で返される応答コードは「450」だから、送信側メールサーバは(Postfixやsendmailのデフォルト設定で)5日間リトライしてようやく送信者にエラーを通知する。特に謝礼や謝罪など、遅滞なく届いてほしいメールの不達に数日間気付くことができなければ、送信者と受信者の双方にとって不利益は計り知れない。
 私が提唱するS25R方式のコンセプトは、逆引きチェックによるスパム対策に反対する立場にも、逆引きできないホストからの受信は拒否すればよいとする立場にも、どちらにもくみしない。逆引きチェックはスパムの阻止に効果があるが、正当なメールもブロックする副作用もあるから、副作用を克服する方策をとる。それにより、大多数のスパムを阻止して、しかも正当なメールの受信に失敗しなくてすむ。簡単な話である。私が提唱しているのは、スキルの高くないメールシステム管理者にも容易に運用できる方式である。
 メールログを監視していなければならないことを方式の欠点だと批判する人もいるであろう。そんなことは、S25R方式を導入してちゃんと偽陽性判定の対処を実行できている人たちにとってはよけいなお世話である。私は、2003年にS25R方式の開発を始めて以来足掛け7年にわたって、送信側メールサーバがリトライを24時間未満(実際には1時間程度)でやめた3回のケースを除いては、正当なメールの受信に失敗したことはない。
 逆引きチェックによるスパム対策に反対してS25R方式を批判する人は、私の論文をちゃんと読んでもらいたいものである。私は、逆引きだけでスパムと断定できるとは一言も言っていない。ホワイトリストが必須だとも述べているし、ホワイトリスト登録すべきホストを見つけやすくするスクリプトも紹介している。S25Rホームページを見れば、ホワイトリスト情報やQ&Aなどがあることもわかるはずである。もっとも、読まない人は読まなくて度し難いということはわかっているのだが。
 同じような話は2006年12月13日「逆引き論争」にも書いているのだが、あえて繰り返した。逆引きによるスパム対策はだめだと言いながら、ならばスパムに困っている人たちはどうすればよいのかを言わない。また逆に、逆引きできないホストからは正当なメールも受け取らないと言う。そのような間違った情報に対抗するには、真にスパムの被害者を救うための情報をしつこく発信するしかない。

Q&Aにpermit_sasl_authenticatedの説明を追記

 Q&AのページのQ/A2-4で、エンドユーザー回線につながってS25Rに引っかかるクライアントをPOP-before-SMTP認証で許可する方法を説明していた。これを更新して、SMTP認証で許可する方法も併せて説明するようにした。下線部が追加部分である。

Q2-4. 私のメールサーバはSMTP認証とPOP-before-SMTP認証をサービスしています。モバイルPCなどの認証されたクライアントがS25Rの規則によって拒否されます。この問題を解決することはできますか?

A2-4. はい、できます。smtpd_client_restrictionsパラメータとsmtpd_recipient_restrictionsパラメータの両方で、permit_mynetworks指定の直後に、SMTP認証のためにpermit_sasl_authenticated指定、およびPOP-before-SMTP認証のためにクライアント認証データベースを指定してください。POP-before-SMTP認証サーバとしてDRACを用いるときの例を示します。「dracd」はデータベースの名前です。本当のファイル名は「dracd.db」ですが、「.db」は書きません。

smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access hash:/etc/mail/dracd,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections

smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access hash:/etc/mail/dracd,
  reject_unauth_destination

金曜日, 10月 30, 2009

「中国にも紹介したい」とのコメント

 前回の続き。
 質問してきた方は、やはり日本の会社に勤務する中国人だった。S25R方式を導入したのは、国内にあるメールサーバ。
 確かに中国では逆引きの設定が広まっていないので、中国からのメールを受信するのにホワイトリスト登録が必要になることはあるとのこと。しかし、中国でもスパムの被害は深刻なので、友人にもS25R方式を勧めたいとおっしゃっていた。
 逆引きの設定が広まっていない中国では、グレイリスティングの方が良いかもしれない。ただ、「初めてメールを送ってくるホストにはわざと一時拒否応答を返す」というグレイリスティングのコンセプトよりも、「逆引き名がサーバっぽいならば許可する。そうでないメールサーバはホワイトリストで許可する」というS25R方式のコンセプトの方が理解しやすいかもしれない。S25R方式を試してから「よく考えてみたら、グレイリスティングでいいじゃないか」と気付く人がいれば、それはそれでよいと思う。

火曜日, 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方式は使いにくくはないだろうか。
 もっとも、逆引きできないホストのホワイトリスト登録がいくら大変でも、スパムの被害に手をこまねいているよりはましだと評価されているかもしれない。
 もし感想を言ってくれたらまた紹介しようと思う。

木曜日, 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ファイルの中に臨時に拒否条件を書いてもよい。

水曜日, 9月 23, 2009

スパムを送ってきたショッピングサイト

 9月10日、HELOアドレスがmail.tacok.comで逆引きできないホストからリトライアクセスがあったので許可してみたら、ショッピングサイトdoremo.jpを宣伝するスパムだった。本文は日本語だが、文字コードはなぜか簡体中国語(簡体中国語の文字セットには日本語の仮名文字も含まれている)。本文は、世界から押し寄せる多くの英語のスパムのような無作法な書き方ではないが、「未承諾広告」の表示やオプトアウトの説明を守っていない。
 ホワイトリスト登録を取り消したが、これは悩ましいなと思った。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と送信者のドメインが一致する場合は要注意といったところでしょうか」とおっしゃっていた。しかし、単発のアクセスの中に正当なメールがあるかもしれないと思ってログを監視するのは大変である。
 リトライしないようにメールサーバを設定しているということは、届かないなら届かないでかまわないと思っているということである。そういうのは、スパムでなければおそらくメールマガジンだけで、個人が送信するメールではまずそんなことはないだろう。届かなくてもかまわないようなメールのためにメールシステム管理者が苦労する必要はないだろう。受信者が待っているメールならば、受信者が「届かないんだけど」と申告してくるだろうから、その時に調査してあげればよい。

日曜日, 9月 13, 2009

批判に勝つのは誰か

 講演資料の最後のページに次のように書いている。

おまけ:将来性を予見するための教訓

普及したものを当初批判した人たち
阿川弘之 ・・・ 新幹線
糸川英夫 ・・・ 家庭用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による自動受付は考えていない。ホワイトリスト情報の申告に人とのコミュニケーションを介する必要がなくなれば、不正な情報を入力する奴は当然現れると予想されるからである。

土曜日, 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%」が誇大広告にならないことがデータの蓄積によってわかっているので、こう書いた方が、二つのデータを併記するよりもわかりやすいだろう。

日曜日, 9月 06, 2009

講演資料を掲載

 ブログの更新がすっかりお留守になっていた間の8月29日に、「第9回まっちゃ445勉強会」でS25R方式についての講演をさせていただいた。事前にこの場で告知しなくてすみません。
 その時の講演スライドをPDFにしてS25Rホームページに掲載した。英訳版も掲載した。
 掲載が遅くなったのは、S25Rホームページのコンテンツは日英二ヶ国語で同じにしなければ気持ち悪いという強迫症のせいである。
 勉強会では、RgreyやtaRgreyの開発者の佐藤さんをはじめ、スパム対策の第一人者の方たちとお会いすることができた。また、掲示板でホワイトリスト情報をお寄せくださったことがあるsuzukiさんともお会いした。

日曜日, 6月 14, 2009

やむなく「554」で蹴っていると言うサイト

 メールサーバの逆引き名がS25Rに引っかかる会社から、S25Rによる不達問題に遭遇したからメールサーバを公開ホワイトリストに掲載してほしいと要請された。
 メールに書かれていた受信拒否のログを見ると、応答コード「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方式を使うならちゃんとログを見てほしい。

日曜日, 5月 31, 2009

ホワイトリスト情報の報告がまた増えた

 2月28日に、ホワイトリスト情報の報告が減ったことを述べた。2009年に入ってから公開ホワイトリストに追加した項目は、1月に1件、2月にはなし、その後、3月に4件、4月に3件と少なかった。ところが、5月に入って34件とまた増えた。
 これは多分こういうことだろう。
 これまでは、ホワイトリスト情報は主に小規模サイトから寄せられていた。大規模サイトでは、自動救済をしていることが多いだろうし、偽陽性判定が頻発するので報告が大変だから、あまり報告されなかったのだろう。
 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に登録されていた。

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.JPBlack 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方式を素のまま使っていると、こういうサディスティックなプレイができて面白い。

*.cust.bit-drive.ne.jpの丸ごと許可を取り消し

 前回、*.cust.bit-drive.ne.jpを丸ごと許可するようにしたことを報告したが、個別許可に戻した。掲示板のゲストのKenjiさんから、*.cust.bit-drive.ne.jpがスパム送信サーバに使われているとの報告をいただいたからである。
 以下は、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の許可条件は、しばらくコメントアウトで示しておくことにする。

# *** 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方式と同じく、スキルの高くない人でも容易に実装・運用できる方法である。知識だけであれこれ言うのでなく、知恵を働かせればよい。
 抗がん剤にはがん細胞だけでなく正常細胞も殺す副作用があるが、だからといって抗がん剤を使ってはいけないなどとは言っていられない。知恵を働かせて副作用を克服できるならば、治療に有効な抗がん剤は使うべきである。それと同じことである。

日曜日, 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を設定してよかったと言える状況である。

水曜日, 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ファイルに以下の太字の行を追加する。

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/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
(smtpd_client_restrictionsパラメータは私の実際の設定を示しているが、必須でない指定も含まれている。誰もがこのように設定すべきだという意味ではない。)

 上記のように設定する前に、まず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)' | \

 これでしばらく様子を見ることにする。

すり抜けスパムがDNSBLにどれだけ引っかかるか

 3月から4月にかけてスパムを着信させたホストがDNSBLに引っかかるかどうかを、RBL.JPBlack list DB checkで調べてみた。このCGIによって、ホストがSPAMCOP、spamhaus、RBL.JPに登録されているかどうかを調べることができる(2008年3月20日「DNSBLって効くの?」を書いた時にはもっと多くのDNSBLについて調べることができたが)。
 送信元ホストと、それを登録しているDNSBLを表で示す。

a190.watel.vt.cust.gts.sk [85.248.46.190]SPAMCOP
blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]なし
gate49.cableone.ne.jp [61.7.42.49]なし
smtp.pyramide.co.ma [196.206.253.90]SPAMCOP
adsl.eb23-sjoaoponte.edu.pt [194.210.65.9]SPAMCOP
brevnov.drino.net [213.151.83.161]なし
adsl.ep-adrcisteralcobaca.edu.pt [194.210.105.124]なし
mail.gpk.lt [82.135.204.112]なし
cr-0.accnet.wireless.royell.org [208.91.182.67]なし
techfirewall.lighthouse.net [69.216.168.41]なし
unknown [211.12.212.178]なし
mail.thaibinh.gov.vn [222.252.216.155]SPAMCOP
o7.jdisonline.com [204.54.152.26]なし
mail.sistema102.net [200.50.20.150]なし
gprsinternet04.porta.net [200.25.197.97]なし
mail-fx0-f179.google.com [209.85.220.179]なし
pop.landrumshouse.com [209.194.32.242]なし
ttx01.ttx-net.sk [193.110.187.2]SPAMCOP
a2.sabnet.bj.cust.gts.sk [62.168.87.6]SPAMCOP
cerstef.b.astral.ro [83.103.177.74]SPAMCOP

 blu0-omc4-s29.blu0.hotmail.comとmail-fx0-f179.google.comはS25Rに引っかかるが、ここから着信したのは、hotmail.comとgoogle.comをホワイトリスト登録しているからである。正当なメールサーバを経由して送信されたスパムは、S25R方式ではいかんともしがたい。
 unknownのホストは、リトライの挙動からメールサーバと思われたものである。ホワイトリスト登録してみたら、着信したのはフィッシング詐欺のスパムだった。

 20個のホストのうち、SPAMCOPに登録されていたのが7個あった。ここから計算した阻止率は35%である。spamhausとRBL.JPには一つも登録されていなかった。このことから、S25Rをすり抜けるスパムをブロックするのにいくらかでも効果がありそうなDNSBLはSPAMCOPだけだと考えられる。
 また、2008年3月20日「DNSBLって効くの?」で述べたとおり、SPAMCOPだけが、S25Rで阻止されたスパム送信元ホスト10個のうち8個を登録していて、ほかのDNSBLは一つも登録していなかった。このことからも、役立ちそうなDNSBLはSPAMCOPだけだと思われる。ただし、その記事で述べたとおり、ウェブで見つけた証言によれば、そのSPAMCOPでも阻止率は50~60%程度しかないらしい。
 一方、SPAMCOPによる偽陽性判定のリスクも見て取れる。SPAMCOPに登録されていたsmtp.pyramide.co.maとmail.thaibinh.gov.vnは、名前からして明らかにボットではなくメールサーバである。第2レベルのラベルから見て、pyramide.co.maはモロッコの企業、thaibinh.gov.vnはベトナムの政府機関と推測される。これらのホストからスパムが送信されたのは確かでも、一時的にスパマーに悪用されただけかもしれない。同じホストから正当なメールも送信されるかもしれないのに、SPAMCOPは、ボットかメールサーバかを区別せずにブラックリストに登録している。ほかのDNSBLでも同じようなものだろう。DNSBLを信用して応答コード「5xx」で蹴るのがいかに危険かがわかる。
 とはいえ、蹴る時の応答コードを「4xx」にすれば、DNSBLを使っても、正当なメールをエラーリターンさせる事故を避けることができる。応答コードを変更するには、Postfixのmain.cfファイルで

maps_rbl_reject_code = 450

のように指定すればよい。この方法をとれば、SPAMCOPを利用してすり抜けスパムを減らすことができるかもしれない。
 次の記事で、SPAMCOPを利用する設定方法を説明する。

息子宛のスパムアクセスが再発した

 3月21日に、息子宛のスパムアクセスが1ヶ月以上途絶えたことを述べた。しかし、またかなりのスパムアクセスが来るようになった。4月12日から27日までの間に、アクセス回数26回。推定メッセージ数にして11通だった。やはり、一度メールアドレスがスパマーに漏洩すると、スパムアクセスが根絶することはないようである。
 スパムアクセスの中には、次のように3回トライするリトライアクセスがかなりあった。

Apr 24 20:57:16 unknown [189.79.211.229]
Apr 24 21:14:25 unknown [189.79.211.229]
Apr 24 21:41:33 unknown [189.79.211.229]

17分後に2回目、44分後に3回目のアクセスが来ている。このパターンは6シーケンスあった。グレイリスティングを併用していると突き抜けられてしまうパターンである。しかし、気付いた時には3回でアクセスが止まっていて、だまされてホワイトリスト登録することはなかったので、1通も着信しなかった。
 これらのリトライアクセスの送信者アドレスのユーザーIDは、「KichikawaMizuki」、「Fujino_Mitsuki」など日本人の名前だったことから、日本語のスパムだったと推測される。以前は、息子宛に着信したスパムは英語のものばかりだった。外国人スパマーがオンラインショッピングのサーバを侵害して盗んだメールアドレスが日本人スパマーにまで流れたようである。

土曜日, 4月 18, 2009

半月後のE-mailレピュテーション

 前回、トレンドマイクロのE-mailレピュテーションによる推定阻止率を59%と述べたが、その後半月のデータをとったら、もう少し良い値になった。
 4月1日から16日までに受けたスパムは191通(30日あたりに換算して358通)。スパムの受信数は2月には969通、3月には1061通と増えつつあったことから、月あたりのスパム数は4月前半にはその増分の半分だけ増えた、すなわち1061+(1061-969)÷2=1107通と大雑把に仮定すると、推定阻止率は68%。トレンドマイクロの「70%くらい」という言葉は嘘ではないと言える。
 とはいえ、S25R方式による阻止率は97%以上だから、Emailレピュテーションによる見逃し率はS25R方式の10倍以上ということである。メールサーバの無駄な負荷を減らすには役立つだろうが、ユーザーをスパムの被害から救うというレベルではない。ユーザーは、メーラーのベイジアンフィルタや、Becky!によるS25Rフィルタリングなどの対策を手放すことができない。
 ちなみに、4月1日から16日までに受けたスパム191通のうち、Becky!によるS25Rフィルタリングをすり抜けたものは9通だった。すなわち、判別率は95.3%で、メールサーバでのスパム対策が行われる前には97%以上だったのに比べて低い。これは、S25Rに引っかかるホストの方が、引っかからないホストよりも高い割合でEmailレピュテーションで阻止されるということを意味する。まともなメールサーバを経由したスパムはEmailレピュテーションでも阻止されないから、これは当然の結果と考えられる。概算すると、Emailレピュテーションによる阻止率は、S25Rに引っかかるホストに対して約7割、S25Rに引っかからないホストに対して約5割ということになる。

金曜日, 4月 03, 2009

E-mailレピュテーション

 3月30日から勤務先でスパム対策が始まった。S25R方式ではない。トレンドマイクロのE-mailレピュテーションを利用したものである。社内IT部門としては、社員をスパム問題から救うというよりも、スパム問題のために何もしていないと言われないための手っ取り早い方法をとりたかったらしい。
 その後に私が受けたスパムは、3月31日には14通、4月1日には15通、4月2日には16通だった。2月には969通、3月には1061通だったことから、この3日間に月あたり1100通の割合でスパムが押し寄せていたと仮定すると、阻止率は59%ということになる。2008年3月20日「DNSBLって効くの?」で、SPAMCOPを利用した場合の阻止率は50~60%と推測されると述べた。それと同じくらいである。トレンドマイクロは70%くらいと言っていると聞いたが、それより低い。
 DNSBLのたぐいのIPアドレスブラックリスト方式の効果はしょせんそんなものだろう。データベースの維持にコストがかかっているだろうに。

水曜日, 4月 01, 2009

April fool

 韓国のヌリビジョンは、バウンシングバック認証方式で100%のスパム阻止を誇る同社のスパム対策アプライアンス「OptPlus」を機能改良したと発表した。これは、同社の日本進出後、日本のスパム対策研究者から指摘された懸念に応えたもの。
 改良点の第一は、バウンシングバック認証要求メールを返送するかどうかをユーザーが選択できるようにしたこと。OptPlusは、入ってくるメールを辞書攻撃チェック、ウィルスパターンチェック、スパムパターンチェックの3段階のフィルタにかけ、それを通過したメールのうち、バウンシングバック認証済みでないものをペンディングキューに入れる。従来は、ペンディングキューに入ったメールすべてに対してバウンシングバック認証要求メールを返送していた。正当な送信者は認証手続きをするので正当なメールは受信できるが、スパマーは認証手続きをしないのでスパムは受信せずに済むというのが「100%のスパム阻止」の仕組み。しかし、スパマーにアドレスをかたられた被害者に身に覚えのないバウンシングバック認証要求メールが届くのは迷惑になると指摘されていた。また、その被害者がバウンシングバック認証要求メールを受けて、事情がわからないまま認証手続きをすると、スパムが受信されてしまうという問題もあった。
 そこで同社は、ユーザーがペンディングキューを見て、スパムに対してはバウンシングバック認証要求メールを返送しないようにできる機能を設けた。これにより、スパマーにアドレスをかたられた被害者への迷惑が避けられる。また、その被害者が間違って認証手続きをすることによるスパムの受信も回避できる。さらに、OptPlusの導入サイト同士でバウンシングバック認証要求メールの投げ合いになって両ユーザーが互いに相手からのメールに気付かないという「やぎさんゆうびん問題」も、ユーザーがバウンシングバック認証要求メールに対してバウンシングバック認証要求メールを返送しないようにすることで解消されるという。
 改良点の第二は、ホワイトリスト登録された送信者アドレスを持つメールであっても、ペンディングキューにいったん保留し、本当にスパムでないかどうかをユーザーが判断した上で受信できるようにしたこと。これにより、ユーザーの知人などのホワイトリスト登録されたアドレスをかたったスパムが受信されてしまうという弱点が解消され、将来にわたって100%のスパム阻止を維持できるようになるという。
 同社は、日本人から寄せられた声をOptPlusに活かしたことにより、同製品の日本国内での更なる普及を目指したいとしている。

土曜日, 3月 28, 2009

OptPlus売れていないんじゃないの?

 「バウンシングバック認証」でググると、私のブログ記事が1位と2位を独占している。2007年5月29日「「バウンシングバック認証」で検索上位」を書いて以来、順位は落ちていない。「OptPlus」でも1位と2位に私のブログ記事がヒットする。「Opt Plus」では7位と8位だが、「Opt Plus ASP」だと、なんとOpt Plus ASPの本家サイトを抜いて私のブログ記事が1位である。
 OptPlusやバウンシングバック認証方式について調査しようとすると、痛烈な批判記事がいやでも目に付いてしまう。こんな状況の中で、OptPlusはどのくらい売れているのだろうか。
 いろいろ検索してみても、ユーザーの声はマスコミサイトのヨイショ記事にしか見当たらない(そのユーザーは、OptPlusのベンダーのビジネスパートナーである)。S25R方式については、「効果抜群でびっくりした」、「これほど効果があるとは予想していなかった」などの声がたくさん見つかるが、OptPlusについては見つからない。バウンシングバック認証要求メールを実際に受けたという話題も見つからない。
 2007年5月にたくさんのマスコミサイトがヨイショ記事を発表してから2年近くになるが、Opt Plus ASPやベンダーのSYSMATE社のコンテンツは代わり映えしない。私の指摘でユーザーが抱くであろう疑問(たとえば「やぎさんゆうびん問題は起こらないのか」など)に答えるコンテンツが追加されてもいないし、獲得ユーザー数やユーザーからの賞賛の声を誇示するコンテンツもない。売る気ないんじゃないだろうか。
 OptPlusが売れていないと思われるのは、おそらく、私のバウンシングバック認証方式反対キャンペーンによるものではない。もちろん、私のブログ記事を読んで、たくさんのマスコミサイトのヨイショ記事を鵜呑みにせずに済んだ人はいるかもしれない。しかし、私がキャンペーンを張らなくても、おそらくOptPlusは売れなかった。
 OptPlusを導入したASPやベンダーの失敗の原因は、日本人のニーズを正しく理解していなかったことである。たいていの日本人は、スパムを受けなくて済むことよりも、正当なメールを確実に受信できることの方を重視するのである。送信者が認証手続きをしなかったら正当なメールも受信されないというバウンシングバック認証方式には、おそらく多くの日本人は見向きもしなかったのである。メーラーに付いているベイジアンフィルタで80~90%のスパムをごみ箱に振り分けることができればそれでおおむね満足で、“スパムの阻止率100%”のために金を払おうと思う人などほとんどいないのである。
 失敗の原因のもう一つは、S25R方式を知らなかったことである。S25R方式を発表したのは2004年。「スパム 対策」のGoogle検索で1位か2位にヒットする状況が2005年以来ずっと続いている。なのに、2007年になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」などと言っている。ちょっと調べれば、スパムの阻止率97~99%、高スキルの技術者でなくても実装できる、しかも無料というS25R方式には勝てないということはすぐにわかったはずである。
 日本人の心と日本人の発明に目を向けなかった事業者の失敗である。

(4月6日追記)
 「OptPlus」と「Opt Plus ASP」での検索順位が少し下がった。しかし、トップ10には入っているので、アピール度は十分である。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

OptPlusの認証画面の脅し文句

 「OptPlus」でググると、7位に面白いページがヒットする。

OptPlus メール
注 意: このシステムはそちらの接続環境(66.249.67.207)で認証したことを自動的に記録いたします。認証後、迷惑メールと判断されるメールを送られてきた場合、法的な処置をとる場合がございますので、翌゚ご了承下さい。 ...
mail.yungjin.co.kr:8886/mmpmgr/user/auth_view.php?msgid=498146C84719&lang=jp - 6k -
(ごみ文字が入っている)

 このサイトは韓国の製薬会社。OptPlusの認証画面である。
 66.249.67.207は、逆引きするとわかるが、GoogleのロボットのIPアドレスである。Googleはどうやってこのページを見つけたのだろうか。この会社にメールを送ってバウンシングバック認証要求メールを受けた人しか知り得ないURLのはずである。誰かが公表したのかと思ったが、検索しても見つからなかった。
 アクセスしてみると、警告文のIPアドレスの部分は自分のIPアドレスになることがわかる。サーバ側でアクセス元のIPアドレスを検出して表示して見せることができるのは当然のことだが、インターネットの仕組みに詳しくないユーザーは不気味に感じることがある。何かを問い合わせようと思ってメールを送った人は、自分のIPアドレスの表示と「法的な処置をとる」という脅し文句に恐れおののいて、認証手続きをせずにあきらめてしまうかもしれない。
 お客様への気配りの心をわきまえた日本人は、こんなことをしてはいけない。

日曜日, 3月 22, 2009

XMailCFG (for Windows)をリンク

 S25Rの目次ページに、XMailCFG (for Windows)へのリンクを掲載した。ホワイトリスト情報をお寄せくださった方から教えていただいたものである。
 XMailは、UNIXとWindowsで動作する、オープンソースのFINGER/SMTP/POPサーバ。XMailCFGは、XMailの設定やメンテナンスを行うソフトウェアであり、XMailにS25Rを組み込むことができる
 XMailとXMailCFGのおかげで、S25Rを組み込んだメールサーバをWindows上でも実現できるようになった。しかも、両ソフトウェアともフリーである。「S25RをWindowsサーバで実現できませんか」という質問を受けたら、これを紹介してあげることにしよう。

掲示板のスパム対策

 協力者からのホワイトリスト情報は、メールよりも掲示板で寄せられることの方が圧倒的に多い。掲示板は、メールとは違って、個人情報を明かさずに投稿できることと、自分の貢献が公になることから、協力者にも好まれるようである。掲示板がなければこれほど多くのホワイトリスト情報は集まらなかったかもしれない。
 掲示板のスパム投稿も問題になっている。スパム投稿のために掲示板を維持できなくなり、閉鎖した人もいる。
 私の掲示板は、他の多くの掲示板に比べてスパム投稿を受けにくかった。トップ画面に投稿フォームがなく、投稿画面へ移るのにワンクリック必要であることが幸いしたようである。また、トップ画面は記事タイトルのスレッド表示で、記事の内容の表示にもワンクリック必要であることから、スパム投稿の宣伝効果に欠けると敬遠されたことも幸いしたかもしれない。
 それでも、私の掲示板にもスパム投稿が来るようになった。そこで、スクリプトに手を加えて、投稿画面のURLを変更してみた。これにより、投稿画面をダイレクトに狙うアクセスをエラーに落とすことができる。しかし、これも破られていたちごっこになった。
 そこで、掲示板スクリプトのファイル名を変えるという方法をとった。「raib.cgi」というファイル名は「raib_3036.cgi」として、また攻撃が来たら数字の部分を変更してかわすことにする。そして、元の名前の「raib.cgi」は、掲示板へジャンプさせるHTMLを吐くシェルスクリプトにする。これが吐くHTMLは、METAタグで掲示板へジャンプさせるようになっている。Aタグは書かず、また、METAタグ中のURLは相対パスにしてフルパスをわかりにくくする。これにより、ブラウザでアクセスする人は手間なく掲示板に到達できるが、スパマーが使う自動プログラムでは掲示板に到達しにくくなる。この方法をとってからは、スパム投稿は根絶した。
 私は無精なので、スパム投稿対策機能を持つ新しい掲示板スクリプトを導入するのでなく、使い慣れたスクリプトを使い続けたかった。これでスパム投稿を排除できたのは幸いだった。投稿してくださるゲストにとっても、CAPTCHA認証の手間を強いられないのは楽だろう。
 掲示板の内容が検索エンジンに拾われなくなるが、そのくらいはやむを得ない。むしろ、ロボットによってPerlスクリプトが連続で動かされてサーバのCPU負荷が上がるよりはよいだろう。
 対策をとったのは2007年だが、今なお、投稿画面の古いURLへのアクセスが日に数回来ている。アホなボットである。

 この方法は私のネットフレンドにも勧めたのだが、その人の掲示板は、この方法をとっても何度か破られている。トップ画面に投稿フォームがあるので、スパマーに狙われやすいのだろう。それでも、古い掲示板スクリプトを使い続けたいならば、これ以上に運用が楽な防御方法はないと思う。

 参考までに、掲示板へジャンプさせるHTMLを吐くシェルスクリプトのコードは次のとおり。「euc-jp」の部分は、メッセージの文字コードに合わせる。シフトJISの場合は「shift_jis」にする。

#!/bin/sh
echo 'Content-type: text/html'
echo
echo '<HTML LANG="ja">'
echo '<HEAD>'
echo '<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=euc-jp">'
echo '<META HTTP-EQUIV="refresh" CONTENT="0; URL=./raib_3036.cgi">'
echo '</HEAD>'
echo '<BODY>'
echo '<CENTER>掲示板への攻撃を防御するため、別URLへ移動します。</CENTER>'
echo '</BODY>'
echo '</HTML>'

土曜日, 3月 21, 2009

息子宛のスパムアクセスが途絶えた

 2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信数について述べた。オンラインショッピング会社のサーバが侵害されて息子のメールアドレスがスパマーに漏洩したものと思われ、2007年9月から届き始めた。今年3月までの着信数の推移は次のとおりである。

2007年9月:3通
10月:2通
11月:2通
12月:3通
2008年1月:6通
2月:5通
3月:11通
4月:3通
5月:2通
6月:0通
7月:0通
8月:1通
9月:0通
10月:0通
11月:0通
12月:1通
2009年1月:0通
2月:0通
3月:0通

 2008年12月22日を最後に着信していない。2月14日「「4xx」は迷惑か?」の中で、
「今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。」
と述べた。この日時点で、過去1ヶ月のスパムアクセスがそのくらいだった。
 今日(3月21日)、ログを見たら、息子宛のスパムアクセスが2月15日以降一度もないことがわかった。ピーク時には月に着信11通、ということは月に数百回あったスパムアクセスが、1ヶ月以上にわたって途絶えている。
 わざとスパマーに拾わせたおとりのアドレス、ウェブページから拾われた間違いアドレス、それらを改変したでたらめのアドレス(2006年9月15日「宛先の正しいスパムの阻止率」参照)へのスパムアクセスは、どんなに「550」を返し続けても、何年たっても減っていない。だから、息子宛のスパムアクセスも、減ることはあっても途絶えることはないと思っていた。途絶えたのは意外だった。
 推測するに、オンラインショッピング会社のサーバを侵害するという難しい方法で盗まれたメールアドレスは、少数のスパマーにしか利用されず、その少数のスパマーのほぼ全員が、息子宛のスパムの送達率の悪さに送信をあきらめたのかもしれない。だとすれば、S25R方式の勝利である。

(3月23日追記)
 3月22日に息子宛のスパムアクセスが1回あった(逆引き失敗で蹴っていた)。根絶はしていないようである。

水曜日, 3月 18, 2009

常軌を逸したダウンロードの犯人がわかった

 3月14日の記事の続編。
 公開ホワイトリストファイルへの5分間隔のアクセスを見つけた時、アクセス元ホストにSMTPアクセスをしてみたら、HELOコマンドへの応答で名乗ったFQDNは「.ne.jp」を冠していた。そのFQDNは順引きできず、また、HELOアドレスは信用できないという思い込みがあって、そのサイトドメインを疑おうとは思いもしなかった。逆引きドメイン名の登録者に通報したが、今なお返事がない。
 再度HELOアドレスを確認し、そのサイトドメイン名のMXレコードを検索してみた。すると、セカンダリMXのIPアドレスがそのホストのものと一致していた。
 逆引き名から、犯人は小規模サイトか個人サイトと推測していたが、そうではなかった。非営利の某ネットワークサービス提供団体だった。常軌を逸したダウンロードをしていたセカンダリMXは、他社の回線を借りて接続していたもので、だから逆引き名からはその団体のサーバだとはわからなかったのである。
 ログを再度調べたら、そのサイトのプライマリMXも公開ホワイトリストファイルをダウンロードしていることがわかった。こちらは一日1回である。セカンダリMXに常軌を逸したダウンロードをさせていたのは何だったのか。cronの設定ミスだったとしたらお粗末。
 手動のSMTPでpostmaster宛のメッセージを打ち込んだが頻繁なアクセスがやまないので、ルータでHTTPをブロックしていた。今日、ブロックを解除してみたら、アクセスはやんでいた。メッセージに気付いたのか、cronジョブがフェールしているのに気付いたのか。HTTPをブロックしてダウンロードを拒絶したのが制裁措置と映っただろうか。設定を直したと連絡をくれればすぐにブロックを解除したものを。
 非営利とはいえ、業務でネットワークサービスを提供しているからにはプロ。小規模サイトや個人サイトのノンプロとは違う。プロならなおのこと、自分の事業のために一個人の無償ボランティアを利用するからには常識として何を守るべきかをわきまえてほしいものである。

火曜日, 3月 17, 2009

公開ホワイトリストファイルから冗長なスペースを削除

 これまで、公開ホワイトリストファイルでは、見栄えのために「OK」のカラム位置をそろえていたが、冗長なスペースを削除して、正規表現との間のスペースを1個だけにした。
 理由の一つは、公開ホワイトリストファイルから「OK」を削除する加工をして使う人がおられることである。加工のしやすさのためには、冗長なスペースはない方がよく、それは見栄えよりも大きな利点だと考えた。
 もう一つの理由は、ファイルサイズの削減である。これで約7KB(約20%)減った。わずかながらダウンロード時間の短縮になる。
 ただし、論文中のホワイトリストサンプルでは、見栄えのために「OK」のカラム位置をそろえたままにしている。

月曜日, 3月 16, 2009

ちゃんとログ見てるんでしょうね

 3月14日「S25Rの採用サイトの推定数」で述べたとおり、公開ホワイトリストファイルを毎日ダウンロードしているサイトは50ほどある(気を遣ってくれる人は、ファイルのタイムスタンプを見て、更新されている時だけダウンロードするようにしてくれているが)。「定期的に取得していいですか」と事前に打診してくれた人は一人しかいない。
 まあいいです。節度をもって利用してくだされば。1回きりのアクセスは単に見ただけかもしれないが、毎日定時にアクセスがあると、どこのサイトがS25R方式を採用してくださっているかがわかって面白い。誰でも知っている某国際空港とか、超有名な某大手出版会社とか。もちろん、私から無断で公言することはしないけれども。

 それはそうと、気になったことがある。cronジョブで公開ホワイトリストを毎日ダウンロードすればホワイトリストのメンテナンスを自動化したことになるとは、まさか思っていないでしょうね。
 公開ホワイトリストを組み込めば、偽陽性判定の確率を下げることはできる。しかし、ゼロにはできない。公開ホワイトリストには、S25Rに引っかかる正当なメールサーバのうち、私と協力者がたまたま見つけたもの(S25Rに引っかかるサイトからの申告を含む)しか収録されていないのである。素のS25R方式を使っている以上、必ずログを監視して、偽陽性判定からの救済を手動で行わなければならない。偽陽性判定はめったに起こらないかもしれないが、ログの監視をサボってはならない。
 ホワイトリストのメンテナンスを自動化したいと思ったら、その方法は、公開ホワイトリストの自動取得ではない。グレイリスティングかタールピッティングの併用、あるいは自動ホワイトリスティングプログラムの組み込みである。くれぐれも勘違いしないでいただきたい。

日曜日, 3月 15, 2009

公開ホワイトリストの棚卸し

 公開ホワイトリストを棚卸しした。逆引きができるようになっていたので許可条件をコメントアウトしたのが32件、逆引きができるようになっていたが逆引き名が一般規則に引っかかるので許可条件をFQDNに変えたのが4件である。
 なお、逆引きができるようになっていたとは、もちろん、パラノイド検査(逆引き名の順引き検証)もOKだったという意味である。ご自分で棚卸しをする際にはご注意ください。

s25rtarpitgreylistをリンク

 S25Rの目次ページに、きまぐれPCひろばs25rtarpitgreylistへのリンクを掲載した。S25Rで送信元ホストの選別を行い、タールピッティングとグレイリスティングでスパムの排除を行う、qmail対応のPerlスクリプトである。qmailユーザーには有用なソフトウェアと思われる。

土曜日, 3月 14, 2009

S25Rの採用サイトの推定数

 前回、常軌を逸した頻度で公開ホワイトリストファイルをダウンロードしている人は「自分と同じことを100人がやったらどうなるか」を考えてほしいと述べた。100人というのは大げさな数ではない。公開ホワイトリストファイルを自動でダウンロードしているサイトは、現在50くらいある。2007年10月8日「ホワイトリストファイルを自動取得されているサイト」を書いた時には8サイトだった。この調子では、本当に100サイトにはなるかもしれない。
 公開ホワイトリストファイルを自動取得しているのは、素のS25R方式の採用サイトだろう。Rgreyなどでホワイトリスティングを自動化していれば、自動取得は必要ないはずだからである(その場合も、公開ホワイトリストを組み込んでおくことには意味があるけれども)。
 そして、素のS25R方式の採用サイトのうち大半は、公開ホワイトリストファイルの自動取得まではしていないだろう。最初に公開ホワイトリストを組み込んであとは自分で項目を追加していくのでも十分だからである。公開ホワイトリストを定期的に組み込むにしても、時たま手動で行う人もいるだろう。Postfixのオペレーションがどうにかできるくらいのスキルレベルの人(決して少なくないと思われる)は、cronジョブを作ろうとまでは思わないだろう。自動取得しようと考える人は、根拠レスな推測だが、1割よりも少ない、20~40人に一人といったところではないかと思う。
 この乱暴な仮定に基づけば、S25R方式の採用サイトは1000~2000くらいと推定される。ホワイトリスティングの自動化を併用しているサイトや、Postfix以外のqmailやsendmailでS25R方式を実装しているサイトを合わせれば、1500~3000といったところかもしれない。
 国内に関する限り、一つのシステムでこれほど多くのユーザーがいるサーバ向けのスパム対策方式は、ほかに例がないのではないだろうか。

ホワイトリストファイルの常軌を逸したダウンロード

 公開ホワイトリストの更新は一ヶ月に1度あるかないか、多くても数回という程度である。ウィルス対策ソフトのパターンファイルじゃあるまいし、私が公開するホワイトリストファイルを寸暇を置かずに反映しなくても、セキュリティ上の問題が起こるわけでもない。私が使っているウイルスバスターでさえ、パターンファイルの更新チェックの周期はデフォルトで3時間、最短設定で1時間である。なのに、何を考えて5分間隔でダウンロードしているのか。
 そういう常軌を逸したダウンロードをしているのは1サイトだけなので、リソース負荷は問題になっていない。しかし、「自分一人くらいやっても問題ないだろう」と思うのでなく、「自分と同じことを100人がやったらどうなるか」を考えてほしい。S25R方式を採用するサイトは非常に増えているのだから。100サイトが同じことをやったら、私のサーバは34KBのファイルを3秒に一度の割合で送り出さなければならなくなるのである。
 逆引き名からは、IPアドレスの割り当て1個の小規模サイトか個人サイトと推測された。アクセス元ホストはSMTPアクセスに応答したが、「postmaster@逆引き名」にメールを送ったら「Relay access denied」で蹴られた(mydestinationパラメータに逆引き名が含まれていないらしい)。HELOコマンドへの応答で示されたFQDNは順引きできず、メールは配送エラーになった。手動のSMTPでpostmaster宛に「一日1回にしてください」とメッセージを打ち込んだ。
 その後24時間たっても5分間隔のダウンロードは止まらなかった。postmaster宛のメールをちゃんと見ていないことが考えられる。ルータでHTTPアクセスをブロックした。これで、そのサイトからは、ホワイトリストファイルはもとより、私のウェブページや掲示板にもアクセスできなくなる。しかし、私のスキルでは、気付いてもらうための策がほかに思い付かなかった。
 …と、ここまで書いたところで、whoisで逆引きドメイン名の登録者を調べて通報することを思い付いた。

(続編)
常軌を逸したダウンロードの犯人がわかった

水曜日, 3月 11, 2009

考え直してGoogleのドメイン名もホワイトリスト登録

 前回、パラノイド検査エラーになるGoogleのサーバのためにIPアドレスのホワイトリスト登録をしていることを述べた。BBSのゲストのいるかさんから報告されたGoogleのホストはルール1に引っかかるものであるが、IPアドレスのホワイトリスト登録にマッチするので、ドメイン名のホワイトリスト登録を追加する必要はない。
 しかし、考え直した結果、Googleのドメイン名も公開ホワイトリストに掲載した。というのは、いるかさんはqmail用のs25rtarpitgreylistをお使いで、公開ホワイトリストファイルをそのままPostfixで使っているわけではない。そのような人たちが公開ホワイトリストから項目を抽出して、使用システムに合わせたホワイトリストを作ることに配慮すると、Googleのドメイン名のホワイトリスト登録も示しておいた方がよいと考えたからである。
 記載は以下のとおり。

# *** PUBLISHED S25R WHITE LIST ***
# Last update: Mar 11, 2009
# (*): reported by a contributor
#
# Mar 11, 2009: mail-gx0-f21.google.com, etc. (*)
/\.google\.com$/ OK

 Googleは超メジャーなサイトなので、論文中のホワイトリストのサンプルにも掲載した。

日曜日, 3月 08, 2009

Googleサーバのパラノイド検査エラー

 BBSのゲストのいるかさんから、以下のホストが引っかかるとの情報をいただいた。

mail-gx0-f167.google.com [209.85.217.167]
mail-gx0-f236.google.com [209.85.217.236]
mail-gx0-f72.google.com [209.85.217.72]
mail-gx0-f21.google.com [209.85.217.21]
mail-qy0-f75.google.com [209.85.221.75]

 しかし、以下のように、すでに2008年7月にIPアドレスでホワイトリスト登録していた。

# Jul 10, 2008: rv-out-0102.google.com, etc. (*)
/^209\.85\.(1(2[8-9]|[3-9][0-9])|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK
#
# Jul 10, 2008: py-out-0102.google.com, etc. (*)
/^64\.233\.1([6-8][0-9]|9[0-1])\.[0-9]+$/ OK
#
# Jul 10, 2008: ag-out-0102.google.com, etc. (*)
/^72\.14\.(19[2-9]|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK

 このホワイトリスト登録は、PyTaさんからの報告によるものである。たとえば209.85.198.192~209.85.198.207の16個のIPアドレスの逆引き結果はどれもrv-out-0102.google.comになり、その逆引き名を順引きすると16個のIPアドレスが順不同で列挙されてくる。Postfixは、検索された最初のIPアドレスが元のIPアドレスに一致しないとパラノイド検査エラーとして扱う。したがって、高い確率で逆引き結果が「unknown」になってしまう。
 ホスト名の初めの綴りを3種類教えていただいたので、それを手がかりに、Googleに割り当てられているIPアドレスブロックを調べて、上記のようにIPアドレスの許可条件を作った。
 いるかさんから報告されたホストは、逆引きと順引きの対応がまともになっているのでパラノイド検査エラーにはならないが、

/\.google\.com$/ OK

という許可条件を追加するまでもない。IPアドレスが1番目の許可条件にマッチするからである。

 このようなパラノイド検査エラーは、amazon.comでも起こっていた。207.171.167.25と207.171.172.6の逆引き名がともにiad-fw-global.amazon.comで、その順引き結果が二つのIPアドレスになっていた。しかし、今調べたところ、それぞれの逆引き名は207-171-167-25.amazon.comと207-171-172-6.amazon.comに変わっていて、順引きとの対応もまともになっていることがわかった。これらのホストは、すでに

# Oct 28, 2004: 207-171-180-101.amazon.com
/\.amazon\.com$/ OK

という許可条件があるので、許可される。
 逆引き名の変更で不要になった許可条件は、ホワイトリストファイルの頭の方でコメントアウトで示した。しばらくしたら削除するつもりである。

# Mar 08, 2009: (This condition has become unnecessary.)
# Jun 06, 2004: iad-fw-global.amazon.com
#/^207\.171\.(167\.25|172\.6)$/ OK

水曜日, 3月 04, 2009

ホスティング事業者もS25Rを推奨

 沖縄のホスティングサービスプロバイダ・テトラビットのニューストピックスより。

2009.01.20
■テトラビット専用サーバサービスでは、SPAM対策の一つである、S25R(Selective SMTP Rejection)方式を推奨します。

 「S25R」は、正しく運用することによって、有効なSPAM対策となります。
 SPAMメールでお困りのお客様はぜひ一度弊社までご相談をください。

 サーバ運用のプロがS25R方式の正しい運用をマスターし、スパムに困っている顧客に推奨して、導入と運用を支援してくれる。これにより、スパム問題から救われる人たちがますます増える。うれしいことである。

土曜日, 2月 28, 2009

ホワイトリスト情報の報告が減った

 2007年9月30日に、ホワイトリスト情報の報告が増えたことを述べた。ホワイトリスト情報を寄せてくださる人が増えたのは、S25R方式を導入する人の総数が増えたからに違いない。
 しかし、最近では報告が減った。2009年に入ってからは、1月に1件寄せられただけで、2月には1件も寄せられていない。これはもちろん、善意の協力者が減ったからではなくて、公開ホワイトリストが安定してきたからだろう。
 現在、公開ホワイトリストの登録数は353件である。大規模サイトでは1000件以上になると聞いているが、それには遠く及ばない。それは、報告してくださるのは素のS25R方式を使っている小規模サイトや個人サイトの方がほとんどだからであろう。大規模サイトでは、Rgrey、Starpit、あるいはtaRgreyでホワイトリスティングを自動化していることが多いだろうし、ホワイトリスト情報を報告しようにも数が多すぎて報告が大変だろう。
 とはいえ、公開ホワイトリストが安定してきたということは、メジャーなサイトはほとんど収録できて、小規模サイトにはほぼ十分なものになったと言える。大規模サイトでも、偽陽性判定の頻発を防ぐにはかなり役立つだろう。
 公開ホワイトリストのおかげで、S25R方式はますます使いやすいものになった。ご協力くださった皆様に心から感謝する。
 なお、Rgrey、Starpit、あるいはtaRgreyでホワイトリスティングを自動化する場合も、公開ホワイトリスト(少なくとも、その中のメジャーなサイト)は組み込んだ方がよいと思う。グレイリスティングあるいはタールピッティングによる送達遅れを減らすことができるからである。公開ホワイトリスト中の特にメジャーなサイトとしては、hotmail.com、data-hotel.net、yahoo.com、google.comなどがある。

木曜日, 2月 26, 2009

逆引き名設定サービスが広まってほしい

 固定IPアドレス1個割り当ての接続サービスの場合、逆引き名はISPによって管理されていて、ホスト名に連番を含み、S25Rに引っかかることが多いようである。そのような接続サービスを使ってメールサーバを運用している人にとって、S25R方式はいまいましいものであろう。送信先サイトがS25R方式を採用しているとブロックされてしまう。送信先がS25R方式を正しく運用していればメールがエラーリターンすることはないが、送達が遅延する。送信先がホワイトリスト登録すればそれ以後は遅延しないが、S25R方式を採用する別のサイトへ送る時にはまたブロックされてしまう。に申し出ていただけば公開ホワイトリストに掲載させていただくが、それで送達遅れがなくなるとは限らない。
 自分のサーバがS25Rに引っかかっても、自分が使ったらスパムの阻止にものすごく効果的なS25R方式。それがわかると、人は気持ちが落ち着かなくなるかもしれない。いまいましいけどありがたい――アンビバレントな気持ちという。
 この問題を解決してみんながハッピーになる方法は、ISPがユーザーの希望する逆引き名を設定してあげるサービスを提供することである。それも、追加料金なしで提供されることが望ましい。アクセス元がメールサーバかエンドユーザーコンピュータかを逆引き名から推定する方法がスパム対策として実用的であることは、S25R方式が多くの人たちに支持されることで実証されている。逆引きは設定されていればよいというものではなく、サーバにはサーバらしい逆引き名を付けることが、受信側に警戒されずにただちに信用してもらうためには好都合である。だから、固定IPアドレス1個割り当ての接続サービスでも、ISPが割り振る連番入りの逆引き名でなくユーザー所有のドメイン名を使った逆引き名を名乗りたいというのは、当然のユーザーニーズであろう。ISPには、そのようなユーザーニーズに応えることを考慮してほしい。
 自分のサーバがS25Rに引っかかり、S25R方式をいまいましいと思っている人は、S25R方式に不平を言うよりもむしろ、ISPに対して逆引き名設定サービスを要求して声を上げてほしい。S25R方式は、メールが誤って再送要求でブロックされて不快になる人たちよりも多くの人たちをスパム問題から救った。今さらS25R方式の採用をやめてくれと言っても、採用するサイトの増加は止めようがないのである。
 もしISPが逆引き名設定サービスの提供を検討してくれないなら、それを提供しているISPに乗り換えることを考えてもよい。調べてみたところ、インターリンク逆引きサービスを無料で提供している。

土曜日, 2月 14, 2009

「4xx」は迷惑か?

 「迷惑メール対策サービス「+abmail」」のページに、私への謝辞が書かれている。スパム対策ソフトウェアabmailは、Receivedヘッダを解析してスパム判定する仕組み。送信元がメールサーバかエンドユーザーコンピュータかは逆引き名からかなりの確度で推定できると私が実証したことが活かされているのが、謝辞の理由なのだろうと思う。S25R方式そのものを使うのでなくても、私のアイデアがこうして別の工夫の基礎として役立っていることをうれしく思う。

 ところで、そのページからリンクされている「+abmail — 迷惑メール対策サービス ~ 迷惑メール判定プログラム「abmail」の導入について~」という資料(PDF)には、私とは異なる考え方が述べられている。

 詐称が行い難い箇所とは、主にIPアドレスやその逆引きであるドメイン名ですが、エンドユーザ空間であれば通常ある範囲の動的アドレスであるので、そういったアドレス空間には正当なMTAが設置されていることは稀で、むしろ、ウイルスでボットと化したパソコン、スパマーとの相関が極めて高いことが判っています。こうした点に注目してMTAコネクションで対策を施す手法が既に提案されています。エンドユーザ空間であることをドメイン名から推定して、そこからのメールを拒否応答してしまうのがS25R(Selective Port 25 Rejection)、正当なMTAか否かを判定すべく、再送要求するのがRgrey(S25R & greylisting)、応答遅延するのがStartpit(S25R & tarpitting)、応答遅延と再送要求するのがtaRgrey(tarpitting, S25R & greylisting)という対策方式です。
 このS25R派生の方式は、スパム排除に効果的であることが知られていますが、正当なMTAであることを判定するための資源を正当なMTAに託す、いささか他者に迷惑な方式であることが問題視されています。

 2006年8月8日「リソース負荷」で述べたとおり、送信側が正当なメールサーバであるかどうかを判断できるまで「4xx」(再送要求)を返して(あるいは応答を遅らせて)送信を多少待ってもらうことは罪悪でもモラル違反でもないというのが私の考えである。
 そもそも、「4xx」を返すと送信側に迷惑をかけると考える人は、自サイトから送信したメールに「4xx」を返されたら迷惑だと思うのだろうか。自サイトから送信したメールがすぐにキューから掃けなかったら、自分のサーバのディスク領域がしばらく使われ続けたと怒るのだろうか。再送のためにCPUやメモリが使われたと怒るのだろうか。送信メールがすぐに掃けずに再送を余儀なくされるのは、相手のインターネット接続回線の故障か工事、相手のサーバの故障かメンテナンス、相手サイトの停電などが原因のこともある。その場合も、迷惑を受けたと思うのだろうか。もしそうだとしたら、ずいぶん狭量である。
 「4xx」を返されて迷惑だと思う人は、確かにいるかもしれない。S25Rに引っかかるメールサーバの運用者が、メールを送信した後神経質にログを見て、いつ送達するのだろうかとやきもきするようなケースである。不快になるのは、メールが送達するかどうか心配になるからであって、自分のサーバにリソース負荷がかかったからではないだろう。そのリソース負荷には何の実害もないのだから。そのような人には、私は「のんびり待ってください」と言う。受信側サイトにも都合があるのだから、メールの送達が遅れることはあって当たり前。最終的にリトライアウトした時に対処を考えればよい。
 片や「受信側は、送信側に負荷をかけないように、送信側で発生したメールをただちに吸い込んであげるべきだ」とする“送信側優先”のポリシー、片や「『4xx』で送信が多少待たされるのは許容し合おう」という“相互許容”のポリシー。インターネットの世界でどちらかのポリシーを合意するとすれば、どちらがよいだろうか。送信側優先のポリシーだと、すべてのスパムを吸い込むためにディスク領域をたくさん使う。スパムの可能性が高いと判断しても、万一正当なメールだった場合に送信側に再送を強いないためには、ことごとく受信しなければならないからである。相互許容のポリシーでは、自サイトからの送信メールが送信キューに滞留することがあるが、そのために使われるディスク領域はわずかで済む。一方、スパムの可能性があるアクセスに対して「4xx」を返すことによってほとんどのスパムを受信せずに済むので、受信キューのディスク領域も少なくて済む。つまり、相互許容のポリシーを合意した方が経済的なのである。
 送信側優先のポリシーと相互許容のポリシー。インターネットの世界での合意とまではいかないまでも、どちらが主流となるか。それは明らかに相互許容のポリシーである。相互許容のポリシーを前提としたS25R方式は、付加ソフトウェアが不要で実装も運用も簡単で効果が高いため、送信側優先のポリシーを主張する人よりも圧倒的多数の人たちに支持されているからである(もちろん、Rgrey、Starpit、taRgreyの利用者も合わせればもっと多い)。
 私は、送信側優先のポリシーに立脚してすべてのメールを吸い込むスパム対策システムにも反対しない。しかし、正当な送信側メールサーバに「4xx」を返して負荷をかけるべきではないとする主張にはこう反論する。「あなたは、工夫によって抑制できる不正なトラフィックも無差別に受け入れることによって、インターネットユーザーの共有リソースであるインターネット中継回線に無駄な負荷をかけているのですよ」と。

 なお、「そこからのメールを拒否応答してしまうのがS25R」という書き方は誤解を招く。
「エンドユーザ空間であることをドメイン名から推定して、そこからのメールに対して再送要求を返して受信拒否するのがS25R、再送するメールサーバを自動的に許可するのがRgrey、…」
と書いてくれた方が、より正確である。

 ついでに…

(S25R派生の方式は)また、正当なMTAと同等な応答の実装を、もしスパマーが実現した暁には破綻してしまうことは明らかで、現にそういったウイルスが出現しています。こうした敵に気付かれる手法では、スパマーに次の手を考える余地をすぐさま与えてしまうので、有効性の寿命は短いと言わざるを得ません。
 一方、本手法はそういったスパムと相関の高いエンドユーザ空間からのメールであっても、正当なメールと同様に受信します。設定によってはそのまま棄ててしまうことも可能ですが、スパムである可能性が極めて高いメールを振り分けてしまうという方式を採っていますので、スパマーは徐々に収益が低下していくことしか知り得ないでしょう。

 私の経験では、スパムに対して拒否応答を返し続けた方が、敵がだんだんあきらめてスパムアクセスが減るので得策である。私の自宅のアドレスはwhoisデータベースに露出している。勤務先のアドレスは、過去にwhoisデータベースに露出していたことがあるが、今は露出していない。それにもかかわらず、自宅の正しいアドレスに押し寄せるスパムアクセスは、スパム対策をしていない勤務先に届くスパムより少ない。これは、自宅サイトではスパムが増え始めたころから拒否応答を返し続けてきたことの効果としか思えない。このことは、2006年9月28日「拒絶の効果?」で述べた。
 また、2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信が2008年3月をピークにその後減ったことを述べた。今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。これも、拒否応答を返し続けたことの効果だろう。
 当然ながら、スパムアクセスの総数が減れば、防御をすり抜けるスパムも減る。それだけユーザーはハッピーになる。
 スパムアクセスに対して「450 S25R check, be patient」という拒否応答を返すのは“敵に気付かれる手法”ではあろうが、当分は気にする必要はない。敵がS25Rを攻略するには、メールサーバを経由するか、脆弱なサーバを侵害するか、ボットに長時間リトライさせるしかなく、いずれにしても大量スパム配信にはコスト高な方法をとらざるを得ないからである。

金曜日, 2月 13, 2009

日本語のスパムをbody_checksでブロック

 「洗練された英文ライティングを実現!」という文で始まる日本語のスパムが2通着信した。2通目の着信は2月10日11時13分。前回述べた、多数のボットからの連続するスパムアクセスと時を同じくしていた。それらの連続するスパムアクセスの送信者アドレスのユーザー名は、「Sakuma.Mako」、「gotou.masato」など日本人の名前だったので、着信したのと同じ文面の日本語のスパムを送り込もうとしたものと思われた。
 この調子では、多数のスパムアクセスが来るうちにまたS25Rがすり抜けられそうだと思ったので、body_checksでブロックすることにした。
 着信した2通のスパムは、送信者アドレスはもちろん、サブジェクトも異なっていた。また、HTMLパートが付いていたが、そこに含まれるURLも異なっていた。変わらないのは本文の文章だった。サーバに残したままのメールを、サーバにログインしてmailコマンドで見てみたら、最初の「洗練された英文ライティングを実現!」という文が次のようにquoted-printableエンコーディングで符号化されていることがわかった。

=1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B!

 main.cfファイルには

body_checks = regexp:/etc/postfix/body_checks

と書いておき、body_checksファイルに次のように書き込む。正規表現で特別な意味を持つ記号の前に「\」(JISローマ文字セットでは円記号)を挿入すればよい。

/=1B\$B@vN\}\$5\$l\$\?1QJ8%i%\$%F%#%s%0\$r<B8=3D=1B\(B!/ REJECT

 quoted-printableエンコーディングはあまりメジャーではなく、たいていのメーラーでは7bitエンコーディングで送信される。だから、誰かがこのスパムを引用して「こんなメールを受けたんですけど」と問い合わせるメールを送ってきたとしても、上記の拒否条件にマッチするおそれはあまりない。
 この作戦は見事成功。S25Rに引っかからないホストからのスパムを2通ブロックした。

Feb 12 02:04:11 reject: body            =1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B! from wireless.netibr.com.br[200.195.40.69]; from=<MeshizukaHimiko@***.info> to=<deo@gabacho-net.jp> proto=SMTP helo=<[200.195.40.69]>: 5.7.1 message content rejected

Feb 12 02:13:01 reject: body            =1B$B@vN}$5$l$?1QJ8%i%$%F%#%s%0$r<B8=3D=1B(B! from cmi.milacron.com[216.68.248.2]; from=<Sugita.Anna@***.org.ua> to=<deo@gabacho-net.jp> proto=SMTP helo=<cmi.milacron.com>: 5.7.1 message content rejected

水曜日, 2月 11, 2009

手ごわいスパム攻撃

 受信拒否されたら別のボットから送信を試みるというやり方と思われるスパムアクセスを、2004年ころに何度か発見したことがある。このことは、2007年10月1日「スパマーは進歩しているのか?」で述べた。
 最近ではこのようなスパムアクセスは観測されていなかったが、久しぶりに現れた。拒絶ログソーティングスクリプトでソーティングした結果を示す。

Feb 10 10:31:33 unknown [190.84.120.208]
Feb 10 10:48:35 unknown [190.84.120.208]
Feb 10 11:15:37 unknown [190.84.120.208]

Feb 10 10:32:49 host60.190-228-65.telecom.net.ar [190.228.65.60]
Feb 10 10:50:01 host60.190-228-65.telecom.net.ar [190.228.65.60]
Feb 10 11:17:53 host60.190-228-65.telecom.net.ar [190.228.65.60]

Feb 10 10:33:56 unknown [118.91.2.38]
Feb 10 10:50:57 unknown [118.91.2.38]
Feb 10 11:17:58 unknown [118.91.2.38]

Feb 10 10:35:11 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]
Feb 10 10:52:12 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]
Feb 10 11:19:13 ppp-58-10-74-55.revip2.asianet.co.th [58.10.74.55]

 1分前後の間隔で異なるホストからアクセスが来ており、しかも、同一ホストから17~27分の間隔でリトライしている。アクセスはこれで止まらず、多数のボットからのアクセスが12時47分まで続いていた。これでは、DNSBLは簡単に突破されるだろうし、グレイリスティングも突破されてしまう。
 とはいえ、リトライの継続時間は1時間未満なので、素のS25R方式を使っていればブロックを破られるおそれは少ない。もしメールサーバと同じように何時間もリトライするボットが現れたら、S25R方式でも防御が困難になるだろう。もっとも、ボットに何時間もリトライさせることは、スパマーにとってはコスト高な方法である。スパマーはそこまでやるだろうか。今後、スパマーの戦略がどうなるか、観察を続けようと思う。

日曜日, 2月 01, 2009

IPv6アドレスを引っかけないようにルール1を変更

 BBSのゲストのJE3KMZさんから、IPv6アドレスのホストからのアクセスがルール1で蹴られてしまうという申告をいただいた。
 IPv6アドレスの表記は、「2001:2f8:0:100::153」(f.dns.jpの例)のような形である。Postfixは、まずFQDNを正規表現と照合して、どれともマッチしなければ、次にIPアドレスの表記を正規表現と照合する。だからIPv6アドレスがことごとくルール1に引っかかってしまうのだと気付いた。
 そこで、ルール1を次のように変更した。

/^[^.]*[0-9][^0-9.]+[0-9]/ 450 S25R check, be patient

/^[^.]*[0-9][^0-9.]+[0-9].*\./ 450 S25R check, be patient

 正規表現の末尾の「\.」はドットにマッチする。これにより、ドットを含まないIPv6表記は引っかからなくなる。
 これで解決したとの報告をいただいたので、論文を修正した。