E-mailレピュテーション導入前後の統計

　2009年4月3日「E-mailレピュテーション」で述べたとおり、勤務先では、2009年3月30日以来、トレンドマイクロのE-mailレピュテーションによるスパム対策が行われている。
　対策実施前の2008年1月から10月までの月当たりの平均データは、受信したスパム1387.5通、Becky!でのS25R簡易一般規則によるフィルタリングをすり抜けたスパム26.5通、したがって判別率98.1%だった。なお、2008年11月からスパムの受信が急激に減少しており、これはボットを操るスパマーの上位ISPが通信を遮断したためらしいので、2008年11月から2009年3月までの期間は統計から除外した。
　対策実施後の2009年4月から12月までの月平均データは、受信したスパム400.7通、すり抜け33.8通、判別率91.6%だった。判別率が下がっているのは、S25Rに引っかかるボットからのスパムはE-mailレピュテーションで多くブロックされ、S25Rに引っかからないホストからのスパムはE-mailレピュテーションでもそれほど多くはブロックされないと考えれば、当然の結果である。
　しかし、すり抜けスパムが月平均26.5通から33.8通に増えていたのには驚いた。道理で、すり抜けスパムを捨てる手間が減っていないと感じていたわけだ。押し寄せているスパム全体に対する簡易一般規則による判別率が下がったのだろうか。いや、そんなことはないはずである。自宅サイトでのS25Rによる最近の阻止率は98.6%で低下の兆しは見られず、簡易一般規則による判別率はオリジナルのS25Rによる阻止率とあまり違わないことがわかっているからである。
　そこで、簡易一般規則をすり抜けるスパムはE-mailレピュテーションでまったくブロックされていない、そして簡易一般規則による判別率は対策実施前と同じ98.1%だと仮定してみる。そうすると、押し寄せている月平均のスパム数は、33.8÷(1-0.981)=1779通と推定される。導入前の平均値の1.28倍である。このくらいの増加はありうるだろう。また、E-mailレピュテーションによるブロック率は、1-400.7÷1779=77.5%ということになり、トレンドマイクロが「70%くらい」と言っているのに比べてやや良いデータである。
　もし、簡易一般規則をすり抜けるスパムのうち少しはE-mailレピュテーションでブロックされているとするとどうか。50%がブロックされていると仮定すると、押し寄せているスパムのうち簡易一般規則に引っかからないものは33.8÷0.5=67.6通。ここから計算したスパムの全数は67.6÷(1-0.981)=3558通。まさかそんなに多くはないだろう。10%がブロックされていると仮定すると、押し寄せているスパムのうち簡易一般規則に引っかからないものは33.8÷0.9=37.6通。ここから計算したスパムの全数は37.6÷(1-0.981)=1979通（対策実施前の1.43倍）。E-mailレピュテーションによるブロック率は1-400.7÷1979=79.8%となる。このくらいはありうるかもしれないが、ともかく、S25Rをすり抜けるホストに対するE-mailレピュテーションによる阻止率は低そうだとは言える。
　結論として、わかったことは、勤務先に押し寄せているスパムは（E-mailレピュテーションでブロックされているものを含めて）推定1779通以上と非常に増えているらしいということ。自宅に押し寄せているスパムが最近の1ヶ月あたりの換算で383通ほどなのに比べて4倍以上である。自宅のアドレスの方が露出度が高いのに、自宅サイトに押し寄せるスパムが少ないのは、長年にわたってS25Rで拒否応答を返し続けてきたことの効果に違いない（2006年9月28日「拒絶の効果？」）。

（1月31日修正）考察に誤りがありましたので、記述を修正しました。

掲示板へのスパム投稿攻撃

　2009年3月22日に掲示板のスパム対策について述べた。私の掲示板では、スパム投稿を防御するために、CAPTCHA認証などの投稿者認証方式でなく“ファイル名使い捨て方式”をとっている。2007年にスパム投稿攻撃を受けたので、掲示板スクリプトのファイル名「raib.cgi」を「raib_3036.cgi」に変更し、raib.cgiファイルはraib_3036.cgiへMETAタグで自動ジャンプさせるHTMLを吐くシェルスクリプトに変更した。これにより、ブラウザでアクセスする人は手間なく掲示板にアクセスできるが、スパマーの自動投稿プログラムは旧ファイルへの投稿アクセスで空振りする。ファイル名の変更後、2年以上スパム投稿の被害を受けずに済んでいた。
　しかし、ここ1ヶ月で3度も破られている。12月26日に「raib_3036.cgi」が破られて「raib_5505.cgi」に変更。それが1月7日に破られて「raib_8080.cgi」に変更。それが1月12日に破られて「raib_6666.cgi」に変更した。
　raib_8080.cgiへのスパム投稿アクセスは今日（1月24日）現在なお続いているが、raib_3036.cgiとraib_5505.cgiへのアクセスは1月10日を最後に止まっている。ここから推測されることは、スパマーは手動で掲示板にアクセスして投稿方法を解析した後、連続自動投稿を行うが、このスパマーは、その後実際に投稿できているかを時折確認しているらしいということである。
　このことから、ファイル名使い捨て方式は結局いたちごっこになるだけではないかと思う人がおられるかもしれない。確かにいたちごっこにはなりうる。しかし、私はスパム投稿があれば半日以内に削除しているので、スパム記事の宣伝効果は低い。そして、掲示板スクリプトのファイル名を変更することによってそれ以上自動投稿できないようにしているので、スパマーはその都度、自動投稿のための設定をやり直さなければならない。敵に手間をかけさせ、手間の割に利益がないことを思い知らせれば、敵はしまいにあきらめるだろう。
　CAPTCHA認証でも、ゆがんだ文字を読み取らせるというよくある方式は、敵がパターン認識技術を向上させることでいたちごっこになりうる。その結果、投稿者はますます読み取りにくい文字の読み取りを強いられることになる。
　ファイル名使い捨て方式は、投稿者に認証の手間をかけさせない。ただ、検索サイトまたはブックマークから古いファイル名で特定の記事を指定してアクセスしてきた人は、新しいファイル名でのトップ画面へ飛ばされてしまうので、そこがちょっと不便をかけさせるだけである。運用者にとっては、ファイル名を変更して旧ファイルから新ファイルへジャンプさせるように設定する手順は数分で済む。毎日のように破られてはさすがにうんざりすると思うが、数日に一度くらいならさほど苦にならない。私は、ファイル名使い捨て方式の方が良いと思っている。
　私が変更するファイル名を敵が自動的に追跡してスパム投稿を続けるようになったら…。その時はその時でまた考えよう。知恵は必ず出てくる。

サーバの故障

　今さらの話題なのだが、1ヶ月前の12月17日にサーバのハードディスクが故障した。しばらく私のサイトへのウェブアクセスができなかったことに気付いた方がおられるかもしれない。
　サーバ機は、1998年に買った、Windows NTプレインストールだったノートPC（CPUクロック133MHz）。もう1台の、2002年に中古で買った、Windows 95プレインストールだったノートPC（CPUクロック150MHz）との交代で、一方を予備サーバとしながら動かしていた。何年も連続運転しているので、そろそろ危ないとは思っていたのだが、予備サーバの動作をしばらく点検していなかった。予備サーバを動かそうとしたら、こちらも立ち上がらなかった。
　Windows 98プレインストールだったノートPC（CPUクロック400MHz）が3台あり、うち1台にLinuxをインストールしてあったので、急いでこれをサーバに仕立てた。まずDNSとウェブサービスを優先的に復旧。ウェブコンテンツはクライアントPCに保管していたので復旧できたが、掲示板の記事は消失した。次にPostfixを入れてメールサービスを復旧し、メーリングリストの再構築、BINDやapacheの最新化、NTPの設定などを行った。どういうわけか/etc/localtimeファイルがなくて時刻がJSTで表示されないなどのトラブルがあったが、しばらくしたら予備サーバが起動するようになったので（温まったからだろうか？）、ここから設定ファイルをコピーして解決した。
　完全復旧の後、Windows 98プレインストールだったPC3台のうちもう1台にLinuxをインストールして、新しい予備サーバに仕立てた。
　連続運転に耐えるように設計されてはいないノートPCだが、よくもったものである。予備サーバの動作を時々確認しておくべきことと、古いサーバ機はほどほどで新しいマシンに交代させるべきことが教訓だった。
　それにしても、スパム対策技術のコンテンツやS25Rホワイトリストなどで日本中から頼られているGabacho-Netが古いノートPCで動いていることを知ったら、びっくりされるだろうか。

rejectionsファイルのコメント行を修正

　S25Rの設定ファイルのうち、拒否条件を書いたrejectionsファイルで、

# [rule 6] … # ex: xdsl-5790.lubin.dialog.net.pl

のように、トラップされるFQDNの例をコメント行に書いている。
　このファイルをviエディタで編集しようとした時に、viが「 ex: 」の部分をコマンドと勘違いしてエラーを出すという指摘をいただいた。確かに、起動時に以下のようなエラーを吐くことがわかった（ただし、そのまま継続すれば普通に編集できる）。

"rejections" 92 lines, 3408 characters Error detected while processing modelines: line 91: Unknown option: xdsl-5790.lubin.dialog.net.pl Press RETURN or enter command to continue

　viがデータ中の特定の文字列をデータでなくコマンドと解釈してしまうとは、初めて知った。私はemacsを使っているので、今まで気付かなかった。気付いた人はほかに大勢おられるはずだと思うが、なぜか今まで指摘されたことがなかった。
　論文に示したrejectionsファイルの中身の「ex:」をすべて「ex.:」に置き換えて、エラーを回避できるようにした。

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ファイルを置くことによってベーシック認証をかければよい。

ルール0の説明を更新

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

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

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

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

　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方式では偽陽性判定からの救済が重要だからである。

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へ飛ばすようにしました。

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

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

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

サブミッションポートでの送信を許可する設定

　中国人と思われる方から質問をいただいた。メールの本文は簡体中国語の文字セットで書かれた日本語。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方式は使いにくくはないだろうか。
　もっとも、逆引きできないホストのホワイトリスト登録がいくら大変でも、スパムの被害に手をこまねいているよりはましだと評価されているかもしれない。
　もし感想を言ってくれたらまた紹介しようと思う。

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月10日、HELOアドレスがmail.tacok.comで逆引きできないホストからリトライアクセスがあったので許可してみたら、ショッピングサイトdoremo.jpを宣伝するスパムだった。本文は日本語だが、文字コードはなぜか簡体中国語（簡体中国語の文字セットには日本語の仮名文字も含まれている）。本文は、世界から押し寄せる多くの英語のスパムのような無作法な書き方ではないが、「未承諾広告」の表示やオプトアウトの説明を守っていない。
　ホワイトリスト登録を取り消したが、これは悩ましいなと思った。doremo.jpは、見たところ、違法性や悪質さが認められない、普通と見受けられるショッピングサイトである。もしかしたら、doremo.jpでショッピングをした人のいるサイトでmail.tacok.comからの正当なメールが引っかかり、そのサイトの管理者からホワイトリスト情報が報告されるかもしれない。私は、寄せられるホワイトリスト情報はすべて信用するというポリシーをとっているが、宣伝のためにスパムをまいたことがあるとわかっているサイトを公開ホワイトリストに掲載すべきか。また、公開ホワイトリストに登録されたホストがスパムをまいたことがほかの人から報告されたらどうするか。
　考えた末、スパムをまいたことがあるとわかっている（もしくはそう報告された）サイトのホストは公開ホワイトリストに掲載しない、あるいは公開ホワイトリストへの掲載を取り消すというポリシーをとろうと思う。そして、ホワイトリスト登録を要請した人には、サイト・ローカルのホワイトリストで許可してくださいと依頼する。
　その理由は次のとおりである。S25Rに引っかからないホストがスパムを送ってきて、そのホストからは受信したくないとサイト管理者が考えた場合は、論文に示しているrejectionsファイルに拒否条件を追記すればよい。しかし、公開ホワイトリストに許可条件が書かれていると、それを取り込んでいるサイトでは、rejectionsファイルの拒否条件に優先して許可されてしまう。もう一つの拒否条件ファイルをホワイトリストの前に指定するという方法もあるが、設定が複雑化する。だから、スパムをまいたことのあるホストは（正当なメールも送信しているとしても）公開ホワイトリストには掲載しない方がよい。
　いったん公開ホワイトリストに掲載したホストを取り消すと、公開ホワイトリストを取り込んでいるサイトでは、受信できていたメールが突然受信できなくなるということが起こるかもしれない。しかし、それはやむを得ない。ログを監視して、公開ホワイトリストで許可されないホストはローカルのホワイトリストで許可するようにしていただきたい。公開ホワイトリストは、ローカルのブラックリストの働きを妨害しない方がよいと私は考えるからである。
　なお、スパムを送ってきたのがISPのメールサーバだった場合は話は別である。その場合は、そのサイト（ISP）がスパム送信という悪事を働いたわけではなく、ユーザーの中にたまたまスパム送信者がいたにすぎない。ISPのメールサーバを経由したスパムを受けたからといって、そのメールサーバの許可を取り消すわけにはいかない。

リトライしないメールマガジン送信サーバ

　掲示板にhanaさんから寄せられたホワイトリスト情報は、リトライしないメールマガジン送信サーバのものだった。公開ホワイトリストへの登録は以下のとおりである。

# Sep 02, 3009: mail2.nc-nippon.com (*)
/^210\.197\.89\.90$/ OK

　ログからは7日間隔のリトライに見えたが、7日ごとに発行されるメールマガジンで、応答コード「450」に対してリトライしていないことがわかったとのこと。リトライしないメールサーバもあるとは聞いていたが、本当に見つかったのはこれが初めてである。
　hanaさんは、「単発のアクセスも無視できないと反省。HELOと送信者のドメインが一致する場合は要注意といったところでしょうか」とおっしゃっていた。しかし、単発のアクセスの中に正当なメールがあるかもしれないと思ってログを監視するのは大変である。
　リトライしないようにメールサーバを設定しているということは、届かないなら届かないでかまわないと思っているということである。そういうのは、スパムでなければおそらくメールマガジンだけで、個人が送信するメールではまずそんなことはないだろう。届かなくてもかまわないようなメールのためにメールシステム管理者が苦労する必要はないだろう。受信者が待っているメールならば、受信者が「届かないんだけど」と申告してくるだろうから、その時に調査してあげればよい。

批判に勝つのは誰か

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

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

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

講演資料を掲載

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