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ホームページで、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

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

学生の盗作レポート

　スパム対策とは関係のない話であることをご了承いただきたい。
　私のサイトGabacho-Netに、日本語脚韻研究室という文芸のコーナーがある。2002年に日本語脚韻を思い付いてから5年にわたって、日本語脚韻を実践している人たちと交流しながら学んできた。その成果を掲載している。
　最後の成果は、「日本語脚韻詩絶望論」という、2007年に書いたレポートである。日本語脚韻詩をいくつも作った上で、日本語脚韻詩が絶望的に難しいことの理由を論じた。日本語脚韻をやったこともない人が「日本語脚韻は無理だ」と言っているのとも、日本語脚韻を実践している人が「日本語脚韻はできる」と言っているのとも違う、私がオリジナリティを誇るレポートである。
　その「日本語脚韻詩絶望論」が学生レポートに盗用された。このままでは、日本語脚韻詩が困難な理由を論じたオリジナリティが私以外の者にあるという誤った情報が、その学生の指導教官を通じて流布されるおそれがある。その可能性はきわめて低いとは思うが、皆無ではない以上、流布されるかもしれない誤った情報に対する対抗措置をとる必要があると考えた。そこで、盗作を告発する「「日本語脚韻詩絶望論」を盗用した学生レポートについて」というコンテンツを掲載した。
　このコンテンツがなるべく早く検索サイトに拾われることを期待して、このブログ記事にリンクを設けることにした。このブログは注目度が高いので、リンクが検索サイトに早く拾われるかもしれないと思ったからである。

　学生がインターネットで拾った情報を安易にコピーしてレポートをでっち上げることは数多く起こっていると聞く。このブログの読者に大学の先生がいらっしゃったら、学生が盗作レポートを作っていないかどうかに目を光らせるようお願いしたい。特に、レポートが優れた内容に見えるときにはチェックしていただいた方がよいと思う。チェックのための検索は難しいことではない。たとえば、くだんの学生レポートの場合、日本語脚韻が困難である理由を論じていることから「日本語 脚韻 困難 理由」で検索すれば、盗作とすぐわかったはずである。
　盗作は、読者を欺き、オリジナルの作者の名誉を傷付ける犯罪である。そのことを学生にきちんと教えることもお願いしたい。

（追記）
　ビンゴ！この記事を投稿してからわずか1時間足らずでGoogleが新コンテンツを拾いに来た。Googleは来るのが早い。

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

　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さんともお会いした。

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

　メールサーバの逆引き名がS25Rに引っかかる会社から、S25Rによる不達問題に遭遇したからメールサーバを公開ホワイトリストに掲載してほしいと要請された。
　メールに書かれていた受信拒否のログを見ると、応答コード「554」で蹴られていた。受信側の会社は、あるホスティング事業者のサービスを利用していて、蹴られるようになったのは最近のことだという。
　そのホスティング事業者にメールを送って、「554」で蹴らないように要請した。回答はこうであった。システムの移行でユーザーが大幅に増加し、スパムアクセスも増えて、MXサーバに予想を上回る負荷がかかり、メールの遅延が発生した。そこでMXサーバにスパムフィルタを入れた。その中にS25Rの条件も含まれていた。応答コードを「450」にしたら大量のスパムアクセスの再送があり、新規セッションを受け付けられない状態になってしまった。そのため、やむなく応答コードを「554」にせざるを得なかった。タールピッティングとグレイリスティングの実装を準備しており、7月には実装する予定である。
　緊急事態だと言われれば、それでも「450」にしてくださいとは言えない。その代わり、クライアント制限に優先して受理される連絡用メールアドレス、または連絡用入力フォームのURLを拒否メッセージに含めてほしいと要請した。入力フォームのURLを含める方向で検討すると回答してくれた。

　これを読んで「そうか。その手を使えば、偽陽性判定された送信者からの申告を待っていればよくて、ログを監視する必要はなくなるな」とは思わないでほしい。それは浅はかな考えである。メールを送信するのは人間だけではない。オンラインショッピングの確認メールやメールマガジンのメールなどを「5xx」で蹴飛ばしたら、送信側サイトの管理者がいちいちホワイトリスト登録を申請して再送してくれたりはしない。メーリングリストの場合も、メーリングリスト管理者が受信拒否による不達に対処してくれない可能性が高い。それらのメールが不達になれば、自サイトの受信者の不利益になる。偽陽性判定からの救済はあくまでも、送信者に手間をかけさせずに受信側で行わなければならない。

副作用の被害者には誠心誠意

　メールサーバの逆引き名がISPドメインの連番入りになっている会社から問い合わせを受けた。2社へのメールが送達せず、調査していて私のサイトを知ったとのこと。
　その2社へ私からメールを送ってホワイトリスト登録を要請してあげて感謝された。
　うち1社へのメールはリトライ中で、私がメールを送ったらほどなく送達したそうである。もう1社へのメールは、5日でリトライアウトしたとのこと。ログを見ていなかったようである。ウェブサイトに掲載されたメールアドレスへメールを送ったらuser unknownになったので、電話をかけて対処してもらってからメールを送り直した。
　また、「自社ドメインの逆引き名をDNSに設定しているのに、ISPドメインの逆引き名が検索されるのは、意図していたことと違っている」とおっしゃるので、「逆引きゾーンがISPから委譲されていないからです」と説明した。「おかげでネットワークの請負会社ときちんと話ができました」と感謝された。
　S25R方式の副作用の被害を受けたのだから、苦情を言われても不思議はないのに、感謝されてよかった。
　それにしても、S25R方式を使うならちゃんとログを見てほしい。

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

　2月28日に、ホワイトリスト情報の報告が減ったことを述べた。2009年に入ってから公開ホワイトリストに追加した項目は、1月に1件、2月にはなし、その後、3月に4件、4月に3件と少なかった。ところが、5月に入って34件とまた増えた。
　これは多分こういうことだろう。
　これまでは、ホワイトリスト情報は主に小規模サイトから寄せられていた。大規模サイトでは、自動救済をしていることが多いだろうし、偽陽性判定が頻発するので報告が大変だから、あまり報告されなかったのだろう。
　2008年終わりから2009年初めにかけて報告が少なくなったころ、公開ホワイトリストは小規模サイトにはほぼ十分なものになった。大規模サイトでは、それでもなお偽陽性判定は起こるが、頻度は少なくなり、報告が大変でなくなった。そのため、大規模サイトからホワイトリスト情報が寄せられるようになった。
　5月下旬に掲示板で多くのホワイトリスト情報をお寄せくださったhoutokuさんのサイトは、メールアカウント数が約600とのこと。taRgreyで自動救済されたホストのうち、素性が明らかで正当なメールサーバだと確認されたものを、無期限に許可するためにホワイトリスト登録していた。このホワイトリストはサイトローカルなものにしておくのでなく公開した方がよいと思い立って、私に登録を申請してくださるようになった。そして、私がどのような正規表現にするのがよいかを判断して公開ホワイトリストに掲載したら、それをダウンロードして自サイトのホワイトリストとして利用されている。
　つまり、公開ホワイトリストにブレークスルーが起こり、より大規模なサイトでも偽陽性判定を減らすことができるものへ成長し始めたということである。houtokuさんら常連ゲストの方々からの報告が減るころには、数百人規模のサイトでも偽陽性判定をめったに起こさないホワイトリストになるだろう。もしかしたら、さらにその後、数千人規模のサイトからホワイトリスト情報が寄せられるようになるかもしれない。