月曜日, 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