生兵法は大怪我のもと

　私はS25R方式の英語名を「the S25R anti-spam system」と称している。
　オックスフォード英英辞典によると、「system」の意味は、まず「a group of things or parts working together as a whole」（全体として共に働くものまたは部分の集まり）とある。「コンピュータシステム」と言うときの意味はこれである。3番目の意味として「a set of ideas, theories, procedures, etc according to which sth is done」（何かが行われることに関する考え、理論、手続きなどの組）とある。「情報セキュリティマネジメントシステム（ISMS）」や「the S25R system」と言うときの意味はこれである。
　S25R方式は、次のアイデアあるいは手続きから成る組としてのシステムである。

●IPアドレスの逆引き結果からクライアントが高い確率でエンドユーザーコンピュータであると推定できる条件（一般規則）を定め、それに基づいて受信を拒否する。
●一般規則に引っかからないエンドユーザーコンピュータに対しては、ブラックリスト登録によって受信を拒否する。
●受信を拒否する際には、クライアントがエンドユーザーコンピュータだという推定がはずれるかもしれないので、正当なメールをエラーリターンさせないように、再送を促す応答コード（450）を返す。
●運用時にログを監視して、「450」の応答コードに対する規則的な再送を発見したら、正当なメールサーバに対して偽陽性判定をしている可能性が高いので、ホワイトリスト登録によって受信を許可する。

　メールシステムの知識のある人なら、私の論文を熟読すれば、S25R方式をシステマティックに理解することは難しくないはずである。実際、Postfixのオペレーションがどうにかできるくらいのスキルレベルの人でも、S25R方式の導入に成功して、ユーザーをスパム問題から解放している。
　しかし、論文を一瞥して、S25R方式をシステムとしてとらえずに「ダイナミックIPアドレスからのアクセスを排除するメソッド（method: a way of doing sth；何かを行うやり方）」と思った人は、必ず失敗する。拒否条件を設定してみてから、正当なメールサーバを拒否する副作用に気付き、これじゃ使えないと思ったり、拒否条件を緩めてみようと思ったりする。拒否条件を緩めると、スパムの阻止率が下がり、それでいて副作用はなくならない。
　S25R方式は、私が数千件の不正メールアクセスを観察しながら10ヶ月かけて、ホワイトリスト作りの運用も含めたシステムとして作り上げたものである。2006年8月7日「ホスト名「nat」」で紹介したような微小な工夫は加えてもよいものの、発表から3年たった今も抜本的な見直しは必要ないと思っているくらいの完成度のシステムである。私が説明していることを最初は素直に真似すればよいものを、自己流でやろうとするから、S25R方式による利益を享受し損なうのである。
　アルゼンチンの人からメールをいただいた。bay0-omc1-s40.bay0.hotmail.comを蹴飛ばしてしまったという。私は論文で、一般規則に引っかかる正当なメールサーバの実例としてmc1-s3.bay6.hotmail.comがあることをちゃんと書いている。
　その人が設定していた拒否条件は

/^[^.]*[0-9][^0-9.]+[0-9]/ REJECT NO !!!, your IP is dynamic

だという。「REJECT」（「554」で蹴る）なんか書いちゃいかんっちゅうに！
　その人は、だから次のような設定を試そうと思っているという。

/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\..*/ REJECT NO !!!, seems dynamic
/^[0-9]+-[0-9]+-[0-9]+-[0-9]+-.*/ REJECT NO !!!, seems dynamic
/.*[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\..*/ REJECT NO !!!, seems dynamic
/.*[0-9]+-[0-9]+-[0-9]+-[0-9]+-.*/ REJECT NO !!!, seems dynamic

私は、2003年、S25R方式の着想を得た時に、「ドットかハイフンで区切られた4個の数字列」という条件を真っ先に試している。確か最初は「REJECT」と書いたが、そうしてはいけないということは、正当なメールをエラーリターンさせる事故を起こす前に気付いた。Postfixがreject_unknown_clientで返すのと同じ応答コード「450」を指定することを覚えた。論文では、そうせよと書いている。
　その人が試そうとしている条件ではたくさんの不正メールアクセス元を阻止し損なうという実例を教えてあげた。

100.red-217-217-187.user.auna.net
host51-253-dynamic.16-87-r.retail.telecomitalia.it
200-19.is.net.pl
a252-96.adsl.paltel.net
p6223-ipad30fukuokachu.fukuoka.ocn.ne.jp

また、207-171-180-101.amazon.comが正当なメール送信サーバであることも教えてあげた。
　それっきり返事は来ていない。
　生兵法は大怪我のもと。英語では「A little learning is a dangerous thing.」（少しばかりの学問は危ないものだ）という。

「OptPlus」でも検索上位

　5月29日「「バウンシングバック認証」で検索上位」で、5月14日「バウンシングバック認証という無茶なやり方」が「バウンシングバック認証」のGoogle検索で1位になっていることを述べた。6月22日現在、なおも1位を保っており、「バウンシングバック」の検索でも1位になっている。
　さらに、6月17日「OptPlusの機能を考える」が、「OptPlus」または「Opt Plus」のGoogle検索で上位にのし上がった。6月22日時点の検索順位は次のとおりである。

「OptPlus」：3位（OptPlusの日本ベンダーのサイト以外ではトップ）
「OptPlus 特徴」：1位
「OptPlus 効果」：1位
「Opt Plus」：5位
「Opt Plus 特徴」：1位
「Opt Plus 効果」：3位

　OptPlusについては、たくさんのマスコミサイトがヨイショ記事を出している。ベンダーやASPが相当働きかけたのだろう。その結果、多くの人がOptPlusのことを知るようになる。そして、OptPlusについてインターネットで調べようとした人は、私のブログ記事を見つけてS25R方式のことを知る。私は、インターネット接続費用以外にまったく金を使わずにS25R方式を宣伝できる。いやあ、うれしいうれしい。(^o^)
　私のブログ記事がマスコミサイトのたくさんのヨイショ記事を抜き去って上位にヒットするのは、多くの皆さんがRSSでS25R雑情報をウォッチしてくださっている結果、検索のポイントが上がっているからではないかと思う。皆さん、ありがとうございます。(_"_)
　S25R方式を2004年に発表して、2005年には「スパム 対策」のGoogle検索で1位になり、今も1位か2位を保っている。国内では有名になり、導入した方々から絶賛をいただいている。使ってみずに批判する声はあるが、使ってみたけれども使い物にならなくて放棄したという声は見当たらない。「（無料で使えてシンプルで効果が高い）S25R方式を知って、スパム対策をビジネスにするのをあきらめた」とどなたかが書いているのを見たこともある。今になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」なんて、いったい何を調査していたのだろう？
　まだまだ多くの人々がスパムに困っている状況だが、解決の希望はもう見えている。スパム対策で金を稼げる時代は、これから始まるどころか、すでに終わりが見えている。これからのメールセキュリティソリューション製品には、スパム・ウィルス対策は当たり前で、情報漏洩対策とか情報の真正性保証とか、そういう付加価値を考えた方がいいと思うよ。補助機能としてのスパム対策にS25R方式を取り入れているMail Proof Keeperのように。

（6月23日追記）
　S25R方式を使ってみたけれども放棄したという声が見つかった。「SPAMメール対策ツールPostgrey（Postfix Greylisting Policy Server）」というページ。「S25Rは一部の正規なメールサーバを遮断してしまう行為です」って…うーん、遮断しないように「450」を返すよう説明しているから、S25Rによる拒否はグレイリスティングと変わらないんだけどなあ。素のS25R方式（手動ホワイトリスティング）では受け入れまでの遅延が大きいというだけで。
　まあ、いいです。「良い提案は必ず批判を受ける。誰からも批判されない提案は採用しない方がよい」という話を聞いたこともあることだし（もちろん、逆は必ずしも真ならずで、批判を受ける提案は良い提案だという意味ではない）。

OptPlusの機能を考える

　バウンシングバック認証を売りにする韓国・ヌリビジョン（Nurivision）社のスパム対策アプライアンス「OptPlus」は、次の4段階のフィルタを備えるという。

(1) ディクショナリアタック（辞書攻撃）チェック
(2) ウィルスパターンチェック
(3) スパムパターンチェック
(4) バウンシングバック認証元チェック

　一見すごそうに見えるが、それぞれのフィルタの特徴と効果はどのようなものか。考えてみた。

(1) ディクショナリアタック（辞書攻撃）チェック
　辞書攻撃とは、ありそうなユーザーIDを片っ端から試すという手口である。存在しないユーザーIDへの送信のアクセスを次々に受けたら、その送信元ホストからの以後のアクセスをブロックする。これにより、偶然当たるユーザーIDへのスパムを阻止することができるというのが辞書攻撃チェックである。
　しかし、橋本大也さんのブログ記事によると、姓の数は、韓国では250、中国では350、ヨーロッパ全土で5万ほどだが、日本では30万ほどあるそうである。だから日本では、辞書攻撃は、当たる確率が低くて割に合わない。私は、日本人のユーザーIDを狙った辞書攻撃を発見したことはない。かつて携帯電話に対する辞書攻撃が起こったのは、携帯電話では一つのドメインに1000万以上ものユーザーIDが収容されているという、一般のインターネットサイトとは違う特性があるからである。攻撃のための辞書は膨大になっても、携帯電話メールのドメインは限られているので、辞書攻撃は割に合ったのである。今では、ユーザーは長いユーザーIDを使うなどして防御し、携帯電話会社でも対策を打ったので、この問題はほぼ解決されている。
　結局のところ、辞書攻撃チェックは、OptPlusの開発国の韓国では有用なのかもしれないが、日本の一般のインターネットサイトにとっては、あってうれしいというほどの機能ではない。
　S25R方式は、辞書攻撃にも強い。仮にユーザーIDが偶然当たったとしても、エンドユーザー回線から送信されているという推定によって、高い確率でスパムを阻止できるからである。

(2) ウィルスパターンチェック
　メールセキュリティアプライアンスにはあって当たり前の機能である。Opt Plusならではの特徴ではない。
　S25R方式は、送信元がエンドユーザー回線らしいと推定することだけによって、ウィルスメールも（未知のウィルスであっても）ほとんど阻止する効果がある。

(3) スパムパターンチェック
　ベイジアンフィルタを使っているようである。OptPlusならではの特徴ではない。判別率は、ベイジアンフィルタの評価について検索してみたところ、90%程度と推測される。
　おそらく、ここでスパム判定されたメールは、捨てずにペンディングキューに入れるのだろう。偽陽性判定された正当なメールをユーザーが拾い出せなければ困るから。

(4) バウンシングバック認証元チェック
　ベイジアンフィルタを通過したメールは、バウンシングバック認証にかけられる。正当なメールのうちバウンシングバック認証済みでないものと、着信したスパムのうち偽陰性判定された10%程度に対して、バウンシングバック認証要求メールが自動返送されることになる。
　バウンシングバック未認証のメールは、ペンディングキューに入る。ペンディングキューに入っているメールの一覧を定期的にメールで知らせてくれる機能があるらしい。ユーザーは、HTML形式の通知メールの画面上で正当なメールを指定すれば、受信すると同時にそのメールの送信者アドレスをホワイトリスト登録することができる。ここまで工夫されているのなら、あまり使いにくくはなさそうだ。
　Opt Plus ASPのページにあるバウンシングバック認証要求メールの文例を見ると、「携帯電話からは認証できません。受信者側で手動認証いたしますので、本メールは無視してください」とある。ん？ということは、送信者に認証手続きを頼まなくても、受信者がペンディングキューから正当なメールを拾い出してホワイトリスト登録すればよいだけのことではないか。どのみちユーザーは、送信者が認証手続きをしてくれない場合に備えてペンディングキュー内のメールをチェックしなければならないのだし。送信者に手間を要求する失礼なメールを自動返送する必要がどこにあるのだろう？

　以上のことから、辞書攻撃チェックは日本ではほとんど不要で、バウンシングバック認証メールの返送はしなくてもよい（返送しない方が、顰蹙を買わずに済むという点で安全である）。したがって、OptPlusの特徴は次のようにまとめられる。

●ベイジアンフィルタでスパム判定されたメール、および受信者が送信者アドレスをホワイトリスト登録していないメールは、ペンディングキューに入れられ、受信者のメールボックスには入らない。
●受信者は、定期的にペンディングキューをチェックして正当なメールを拾い出す必要がある（その操作を容易にする仕組みはある）。正当なメールだと受信者が認めたメールの送信者アドレスはホワイトリスト登録される。
●受信者がホワイトリスト登録しているアドレスを送信者アドレスにかたったスパム（5月27日「バウンシングバック認証の破り方」参照）は、約10%の確率でベイジアンフィルタを突破してメールボックスに入ると考えられる。

　バウンシングバック認証方式やOpt Plusについて調査しようとしてこの記事にたどり着いた人のために、S25R方式の特徴もまとめておく。

●送信元のIPアドレスの逆引き結果からエンドユーザーコンピュータと推定した場合に、受信を拒否して再送を促す（スパムやウィルスメールはほとんど再送されない）。不正メール送信元に対してその推定が当たる確率は約99%（ただし、受信するスパムの減少率は約97%）。スパムやウィルスメールのメッセージ本体の受信が食い止められるので、サーバと回線のリソース負荷が減る。
●正当なメールサーバを経由して送信されたスパムは阻止できない。しかし、メールサーバの処理能力がボトルネックになることや、メールサーバでの流量制限により、そのようなスパムはあまり多くならないことが期待できる。
●偽陽性判定された正当なメールの救済は、メールシステム管理者の手作業または自動救済システム（Rgrey、Starpit、taRgreyなど）によって行われる。ユーザーに追加の作業は発生しない。
●偽陽性判定された正当なメールの受信は、送信元からの再送に頼る。グレイリスティングによる自動救済では数分～数十分、手動救済では数十分～数時間遅延する。ただし、タールピッティング（応答遅延）による自動救済では再送に頼らず、受信の遅延は1～2分である。
●無料で使える。

　なお、5月27日「バウンシングバック認証の実装がヘボだと…」で、バウンシングバック認証メールのループの懸念について書いたが、おそらくそれはOpt Plusでは考慮されていると信じたい。バウンシングバック認証メールの送付先をデータベースに記憶しておいて、同じ送付先に二度送らないようにすれば、メールループは簡単に防げるから。
　それにしても、ペンディングキューといい、バウンシングバック認証メールの送付先のデータベースといい、いろんなデータの管理が必要。リソースを食いそうな、また、開発コストが高そうなシステムではあるわな。

（おことわり：この記事を検索にかかりやすくするために、「Opt Plus」と「OptPlus」の表記を混ぜています。）

（この記事へ直接来られた方は、OptPlusについての最初の記事「バウンシングバック認証という無茶なやり方」をご覧ください。そこにOpt Plusについてのすべての記事へのリンクがあります。）

ターピッティング？タールピッティング？

　5月3日に論文を更新した際、追記した文章の中で「tarpitting」をどう音訳するかと悩んだ末に、「タールピッティング」と書いた。
　英語の音訳の原則に素直に従えば「ターピッティング」であり、確かにそれが原音に近いだろう。しかし、「tarpitting」の語源が「tar pit」（タールの穴）であり、「タールピット」という表記はすでに行われていることから、「タールピッティング」と書くことにした。片仮名語から語源を類推しやすくすることを考えたのである。
　英語の辞書にない、知られ始めたばかりの語なので、片仮名で書いている人はまだ少ない。6月14日時点で、Google検索すると、「ターピッティング」でヒットするのは26件。私のほかにはマイクロソフトだけが「タールピッティング」と書いていることがわかった。同社は「タールピット機能」という語も使っている。
　「タールピット機能」という語との整合性を考えれば、英語の綴りを素直に音訳した「ターピッティング」よりも、「タールピッティング」の方が好都合ではないかと思う。
　なお、佐藤さんのRgreyは「アールグレイ」、Starpitは「スターピット」と読むのが自然だろう。taRgreyは、「R」が掛け言葉ならぬ掛け文字になっていることから、私は「タールグレイ」と読んでいる。

Q&Aを公開

　私のサイトに、S25R方式についてのQ&Aのページを新設した。「コンセプト」と「運用」の2編に分けてある。どうぞお役立てください。
http://www.gabacho-net.jp/anti-spam/q-and-a.html
　英語版を先に書いたので、日本語版は翻訳調になっている。答えの最初で「はい」、「いいえ」、「私はそうは思いません」と言い切っているのは、欧米の文化に合わせた英文を翻訳したからである。日本人の感覚ではちょっときつい感じがするかもしれないけど。

mailというホストからスパムアクセス

　ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばすという反則技に、mailという名前のホストが引っかかった。

Jun  6 01:59:42 mail.kamlit.ru [217.66.31.153] from=<cedlpsgroupgym@lpsgroup.com> to=<deo@gabacho-net.jp> helo=<[217.66.31.153]>

Jun  6 02:00:32 mail.kamlit.ru [217.66.31.153] from=<cedlpigroupgym@lpigroup.com> to=<deo@gabacho-net.jp> helo=<[217.66.31.153]>

（この記事からスパマーにメールアドレスを拾われにくいように、「@」は「&#64;」と書いている。もっとも、送信者アドレスのユーザー名はでたらめだろうし、今さら私のアドレスが拾われても痛くも痒くもない。）
　一瞬、まともなリトライのように見えたのだが、私の拒絶ログソーティングスクリプトでは空白行を挟んで表示されていた。よくよく見ると、送信者アドレスのユーザー名が1文字だけ、ドメイン名が1文字だけ違っている。人間が見落とす違いをちゃんと判別してくれるおいらのスクリプトは偉いっ！(^o^)
　セキュリティぼろぼろのメールサーバがボットにやられたのだろうか。それとも、スパマーのドメインなのだろうか。もしこのドメインから繰り返しスパムアクセスが来るなら、反則技を解除する時に備えて（解除しないかもしれないが）、「/\.kamlit\.ru$/」をブラックリストに登録しようと思う。
　反則技をかけて以来、そのおかげで受けずに済んだスパムは3通（今回の2回のアクセスは、受けていればおそらく1通だった）。6月に入ってから6日までスパムはまったく受けていない。勤務先でも、Becky!のフィルタリングに反則技を設定した（東欧から仕事のメールを受けることはあり得ないので）。それ以来、200通以上のスパムのうち見逃しは1通だけである。反則技の効果はすごい！

（6月8日追記）
　www.kamlit.ruにアクセスしてみた。まともな会社っぽい。やはりサーバがボットにやられたのだろう。

そんなにすごいですか？

　「なーおんぶろぐ」さんの2007年2月12日の記事「PostfixでS25Rスパム対策」で絶賛をいただいている。メールサービスを提供している会社のサーバらしいのだが、「１日様子を見ましたが、今のところスパム排除率100%、誤認率0%です」とのこと。そんなにすごいですか？
　宛先の正しいスパムの阻止率約97%ということから考えると、受けるスパムが一日数十通程度の人の場合、確かに一日まったくスパムを受けないことはあるだろう。
　ホワイトリストなしの偽陽性判定率は推定約13%だが、私が公開しているホワイトリストを初めから組み込んでおられるようである。「ホワイトリストは、上記サイトに登録されているもので普通は十分」とも。大規模サイトでは1000件ほどのホワイトリスト登録が必要と聞いているが、公開しているのは、私が見つけたものと、協力者から少数ずつ報告された、合計100件ほどである。これだけでも、メジャーなメールサーバは大体網羅されていて、偽陽性判定を大幅に減らすことができるようである。
　ともかく、喜んでいただけてうれしいです。ご利用ありがとうございます。

反則技

　2007年5月に着信したスパムは15通だった。そのうち12通は、ポーランド、ロシア、チェコの国ドメインから来ていた。

router.emserv.ru
deflektor.betanet.pl
deflektor.betanet.pl
krochmalna.spray.net.pl
bielsko.bsb.vectranet.pl
ge-r1-atm.ptim.net.pl
isb12.clnet.cz
ns.lanta-net.ru
iB3.rudanet.pl
alfa.sinus.one.pl
xr1.ntsias.ru
helemik-ipex.ipex.cz

　S25Rの一般規則をすり抜けてスパムを送り込んでくるのは、この三つの国ドメインが多い。そこで、次のように拒否条件を設定してみた。

/\.(pl|ru|cz)$/ 450 domain check, be patient

　エンドユーザーコンピュータと疑われるホストを蹴飛ばすというS25Rのコンセプトから言って、国ドメインを丸ごと蹴飛ばすのは反則技である。しかし、エンドユーザーコンピュータっぽくない名前のホストがどういう挙動を示すかを見てみようと、あえてかけてみた。
　6月1日に2個のホストが引っかかった。いずれもリトライしなかった。

*o*o*a-tsusho-machinery.ru
router.finemedia.pl

　前者は、日本企業のロシア支社とモロわかりの名前だったので、一部伏せ字にした。NAPT（IPマスカレード）で収容されたサイト内PCがボットにやられたのだろうか。
　反則技とはいえ、特定の国ドメインをグレイリスティングにかけると考えれば、サイトのポリシーとして認められることである。これら東欧3国からのスパムでお困りのサイトは、よろしかったらお試しください。ただし、これらの国のためのホワイトリスト登録の手間とのバランスを考えた上で。

拒否メッセージを変更

　論文に示している設定ファイルの記述で、拒否メッセージを変更した。

ブラックリスト用：
450 domain UCE-blacklisted
↓
450 domain check, be patient

一般規則用：
450 may not be mail exchanger
↓
450 S25R check, be patient

　誤って拒絶された正当なメールサーバを救済するのが数時間以上遅れた時、送信者が送信側のメールサーバから遅延警告メッセージを受け取ることがある。その中に、クライアント制限設定ファイルで指定した拒否メッセージが表示される。「あなたは怪しい」というニュアンスのメッセージだと、善良な送信者を不安にさせる。「be patient」（お待ちください）という語句を含むメッセージなら、「受信側で何かの検査に引っかかっているが、待っていれば対処してもらえるのだろう」と思ってもらえるだろう。
　ログに残るメッセージの例は次のとおりである。これらはスパムかウィルスメールを阻止した例だが、正当なメールの送信者が遅延警告メッセージを受け取った時には、これらと同様の形のメッセージを目にすることになる。

450 4.7.1 <pd318ee.tkyoac00.ap.so-net.ne.jp[61.211.24.238]>: Client host rejected: domain check, be patient
450 4.7.1 <123-192-172-177.ethome-ip.ethome.com.tw[123.192.172.177]>: Client host rejected: S25R check, be patient

　素のS25R方式をお使いの方は、拒否メッセージをこのように変更するようお勧めする。
　なお、論文には以前の拒否メッセージと変更の説明を付記しているので、以前の拒否メッセージで検索した人も論文にたどり着くことができるようになっている。

　ついでに、「逆引き名がMXレコードに対応していれば正当なメール中継サーバとして信頼する」という、ドメイン認証に似たアイデアを論文に書いていたが、有用な情報ではないと考えて削除した。すべてのサイトで「これは正当なメールサーバである」と宣言する設定が完了しないと有効なスパム対策にならないような方式のためにインターネット全域で足並みがそろうとは期待しにくい。S25R方式は、他サイトが何の変更もしてくれなくてもすぐに役立つスパム対策である。これが広まって、S25Rで拒否されない逆引き名をメールサーバに付けることも多くのサイトに広まり、ますますS25R方式が使いやすくなることの方が、実現の可能性が高いと思う。

（7月28日追記）
　設定方法を変更した説明を論文に反映しました。設定ファイルをホワイトリストと拒否条件に分け、逆引きできない送信元ホストに対する拒否メッセージを拒否条件のファイルに組み込むようにしました。こちらの記事で説明しています。

日経コミュニケーションに載った

　「日経コミュニケーション」2007年6月1日号の贈呈誌をいただいた。p.66～71にS25R方式の記事が載っている。タイトルは、

企業を熱くする最新テクノロジ　S25R
無料で使える迷惑メール対策　疑わしき通信をシャットアウト

　S25R方式について、わかりやすく正確に解説していただけた。記事の中で、サイバー大学の園田道夫准教授から「迷惑メールを入り口でシャットアウトできるうえに、メールの中身まで解析しなくても済む」とのコメントをいただいている。
　なお、一部誤植があった。

p.70　第2段組　2行目
エンド・サーバーのパソコン　→　エンド・ユーザーのパソコン

「バウンシングバック認証」で検索上位

　5月14日「バウンシングバック認証という無茶なやり方」が、5月29日時点で、「バウンシングバック認証」のGoogle検索で1位になっている。「バウンシングバック」の検索でも上位にある。マスコミサイトでは画期的な技術ともてはやされる風潮の中で、バウンシングバック認証方式について調査しようとする人たちの目にとまりやすくなったことをうれしく思う。
　私は決して、S25R方式だけが良いスパム対策方式でほかの方式はだめだと言いたいのではない。ただ、すべての善良なインターネットユーザーがスパムの被害から救われてハッピーになってほしいのである。バウンシングバック認証方式が本当にすべての善良なユーザーをハッピーにするのかどうかを考えていただきたい。
　私が書いてきた懸念が杞憂であるなら、それはそれでよい。しかし、バウンシングバック認証方式を使ったアプライアンスやホスティングサービスの利用を考えている人は、ベンダーあるいはプロバイダが私の懸念に対して筋道立てて論駁できるのかどうかを確かめていただきたい。
　また、特に企業のネットワーク管理者や経営者は、“スパムの完全排除”の裏にひそむリスクを認識していただきたい。プロバイダは、貴社のお客様にバウンシングバック認証の手間をかけさせないためには「ユーザーがあらかじめホワイトリスト登録すればよい」と言う。しかし、貴社は全社員にそれを徹底し続ける自信があるか。「スパム対策のために客のメールを疑って客に手間をかけさせるのか」とお客様を不快にさせるおそれがないと言い切れるのか。
　貴社の製品に興味を持ってくれた、お客様になってくれるかもしれない人が、ウェブのフォームで問い合わせをしてきたとする。社員がそれにメールで回答した。問い合わせをした人が、さらにそのメールに返信した。正しく返信したのに、「認証手続きをしてくれなければあなたのメールを受けてあげません」と解釈される自動メールを送り付けられた（これは、回答メールを送った時に相手をホワイトリスト登録しておいても完全には避けられない。相手が受信用に開示したアドレスがエイリアスで、相手からのメールの送信者アドレスがそれとは異なることもあるから）。依頼文の書き方がどんなに丁寧でも、それは無礼なことではないのか。それで気を悪くさせてビジネスチャンスを失うリスクはないと言えるのか。そこを考えていただきたい。
　ついでに、バウンシングバック認証について調査しようとしてこのブログにたどり着いてS25R方式の名前を知った人は、すでにS25R方式がどれほど多くの人の注目を集め、どれほど多くの人に支持されているかを知っていただきたい。
　S25R方式にも、正当なメールを疑って受信を遅延させるというリスクはある。しかし、送信側からは、受信側の一時的なシステムトラブルだったかのようにしか見えない。正しく運用していれば、お客様に手間をかけさせることはないし、貴社のセキュリティポリシーがお客様に対して無礼なものだと思われる心配はない。
　良いことしか言わない商用アプライアンスとは違って、S25R方式を無償公開した私は、論文でその弱点をも初めから公表している（ただし、スパマーが弱点を突くには高いコストを強いられることも）。S25R方式の支持者は、それをわかって支持してくださっている。もちろん、ほかのスパム対策方式もある。セールストークを鵜呑みにせずにちゃんと調査し、何が良いのかを比較検討した上で決断していただきたい。

バウンシングバック認証の破り方

　「バウンシングバック認証でスパムの阻止率100%。スパムを受信したら返金します」と豪語されると、スパマーは、なんとか破って鼻をあかしてやりたくなるだろう。
　もちろん、スパムに対するバウンシングバック認証メールをまともに受けて、手作業でキャプチャ認証を通過してスパムを送り込むことはできるが、そんなちまちました方法でなく、もう少し大がかりに破る方法がある。
　たくさんのPCにウィルスかスパイウェアかボットを仕掛けて、やり取りしているメールのアドレス情報を盗み出す。そして、From、To、CCから送信者と受信者の関係を解析する。そこから、白やぎさんと黒やぎさんが互いにメールをやり取りしていることを把握する（それは、第三者が保管していたメールからも知られうる）。そうしたら、白やぎさんのアドレスをかたって黒やぎさんへ、黒やぎさんのアドレスをかたって白やぎさんへ、たくさんのゾンビPCからスパムを送り込むのは、やりたい放題である。完璧に見える防御策は、弱点が見つかってしまえば案外もろいものである。
　ウィルス対策ソフトを使っているからウィルスやスパイウェアやボットは自分には無縁だと思っている人がいるかもしれない。しかし、悪意のあるウェブサイトにアクセスしただけでスパイウェアが仕込まれるおそれはある。それに、たくさんのPCがボットに感染してスパムの発信源になっている。それらのPCがやり取りしているメールのアドレス情報を、特定のサーバにアップロードさせるなどして収集すれば、それらのPCの使用者たちだけでなく、その知人、さらにそのもう一つ先の知人までメールのやり取りの関係を把握できてしまう。
　これに対抗するには、ホワイトリストに送信元サーバのIPアドレスも登録するという方法が考えられる。しかし、送信側サイトのメールサーバが複数あると、送信者は、自分を完全に認証してもらうまでに、送信サーバの台数と同じ回数だけバウンシングバック認証要求に応じなければならない。バウンシングバック認証をやっているサイトは不評を買うことになるだろう。
　バウンシングバック認証なんか使わない方がよい。まして、生半可な考えでインプリメントしてはならない。
　もっとも、日本の企業や学校には広まりはしないだろう。良識あるメールシステム管理者や経営者なら、企業ではお客様やこれからお客様になってくれるかもしれない人に対して、学校では学外の偉い先生に対して、バウンシングバック認証のメールを送り付けて手間をかけさせるのは失礼だとわかるだろうから。

（7月1日追記）
　佐藤さんのブログ記事で、別の破り方が提案された。楽天、ヤフーオークション、まぐまぐなどのメジャーなショッピングモールやメールマガジンサービスからメールを受信している人は少なくないと見込んで、それらの送信者アドレスをかたったスパムを送り込むという方法。メールマガジンなどを受信するには、バウンシングバック認証なしで受信するための別アドレスであるエクスパンションアドレスを使う方法があるが、そんな巧妙な方法よりも、ペンディングキューからメールを拾い出してホワイトリスト登録する単純な方法を選ぶユーザーが多いだろう。そういうユーザーが標的になる。グッドアイデアだと思う。

バウンシングバック認証の実装がヘボだと…

　「やぎさんゆうびん問題」は、「自サイトのユーザーがスパムを受けなくてすむためには、他サイトのユーザーに手間をかけさせてもかまわない」という身勝手どうしがぶつかり合うとどうなるかと考えて書いたお話である。白やぎさんと黒やぎさんがともに相手からの手紙を食べてしまったという童謡「やぎさんゆうびん」になぞらえて、双方が同じことをすることによって互いに情報が伝わらなくなるという問題をこのように名付けた（英訳は「the Goats' Mail problem」とでもしようか）。
　実際のところ、白やぎさん、黒やぎさんともにペンディングキューに気を付けていれば、やぎさんゆうびん問題は起こらない。しかし、白やぎさんが、個人間のメールのやり取りを始めたばかりの初心者だったら、ペンディングキューに落ちているバウンシングバック認証メールに気付かないということは十分にありうる。また、黒やぎさんも初心者だったら、白やぎさんからのメールがペンディングキューに落ちているのに気付かないかもしれない。かくして、やぎさんゆうびん問題は起こる。
　これを防ぐために考えられることは、バウンシングバック認証メールはpostmaster、mailer-daemon、または空アドレス（<>）を返送先アドレス（MAIL FROMコマンドで通知されるアドレス、すなわちReturn-Path）として送信するものとして、それらを返送先アドレスとするメールはバウンシングバック認証にかけずに通過させることである。そうすれば、宛先誤りのエラーリターンに気付かないというトラブルも避けることができる。しかし、そのことを知ったスパマーは、それらを返送先アドレスとするスパムを大量に送り込んでくるだろう。
　ところで、「やぎさんゆうびん問題」のお話を書いた時、私は、暗黙のうちに仮定を置いていた。バウンシングバック認証メールはpostmaster名で送信され、それに対するバウンシングバック認証メールはpostmaster宛になり、postmaster宛のメールはバウンシングバック認証にかけずに受けるという仮定である。しかし、postmaster宛のメールもバウンシングバック認証にかけるというヘボな実装をしていると、大変なことが起こる。

「黒やぎさんへ、白やぎです。」
「黒やぎさんちの郵便局の局長ですが、黒やぎさんにメールを送ったのは、本当に白やぎさん、あなたですか？」
「白やぎさんちの郵便局の局長ですが、白やぎさんにメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか？」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか？」
「白やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか？」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか？」

メールループが起こって、ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
　まさかとは思うが、バウンシングバック認証メールの返送先アドレスをpostmasterなどでなく受信者本人のアドレスにするというヘボな実装だったとしたら、やはり大変なことになる。

「黒やぎさんへ、白やぎです。」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか？」
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか？」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか？」

ディスク容量の余裕が少ない方のサーバがダウンするまで繰り返される。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
　これを避けるためには、白やぎさんが黒やぎさんにメールを送った時に、白やぎさんのサーバで自動的に黒やぎさんのアドレスをホワイトリスト登録すればよいというアイデアが浮かぶが、それは浅知恵である。たとえば、私が自分のサイトで公表している連絡先アドレスが「webmaster」、自分が送信するメールの送信者アドレスが「deo」であるように、送信者が宛てるアドレスとそれに対する返信の送信者アドレスが異なる場合がある。エイリアス展開した後のアドレスを返送先アドレスとしてバウンシングバック認証メールを送るというヘボな実装だと…

「ダンディー黒やぎさんへ、白やぎです。」
（白やぎさんのサーバで「ダンディー黒やぎ」がホワイトリスト登録される。）
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか？」
（白やぎさんのサーバでは「黒やぎ」はホワイトリスト登録されていないので…）
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか？」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか？」

以下同文。ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
　送信メールの返送先アドレスを自動的にエクスパンションアドレスに書き換えて送り出せば、それに対するバウンシングバック認証メールはエクスパンションアドレス宛になり、バウンシングバック認証にかからずに通過できる。この方法ならば、メールループは起こらない。しかし、エクスパンションアドレスの決め方が一定だと、スパマーに推測されて、エクスパンションアドレス宛のスパムが大量に送り込まれるおそれがある。だから、エクスパンションアドレスは時々変更しなければならない。作り込みがやっかいである。宛先サイトのサーバにホワイトリスト登録されるのがこのエクスパンションアドレスだとしたら、それを変更するたびにまたバウンシングバック認証メールが来る。
　身勝手どうしのぶつかり合いによるトラブルを避ける対処法を考えると、そこからまたスパマーに突かれる穴ができるような気がしてならない。あああ、頭いてえ…

バウンシングバック認証はやはりやっかい

　5月14日「バウンシングバック認証という無茶なやり方」で、バウンシングバック認証をやるとメーリングリストのメールやメールマガジンやオンラインショッピングの確認メールの受信に困ると述べた。しかし、それには解決法があることがわかった。エクスパンションアドレスという、バウンシングバック認証をかけないように登録した別アドレスで受信するという方法である。
　なるほど、グッドアイデア！…と思ったが、やはりやっかいな問題が残ることに気付いた。
　自動登録方式のメーリングリスト（たとえばBecky!のメーリングリスト）では、登録要求のメールを送ると、Fromヘッダのアドレスへ、登録の確認を求める自動返信メールが返される。それがバウンシングバック認証に引っかかる。それを避けるためには、Fromヘッダのアドレスをエクスパンションアドレスに変えて登録要求のメールを送る必要がある。ベテランのインターネットユーザーには何でもないことだが、初心者にはやっかいな作業だろう。なぜそんな巧妙なことをしなければならないのかを理解するのも、初心者には大変だろう。それに、バウンシングバック認証のメールは、メーリングリスト管理者にとっては“迷惑メール”である。
　そんな巧妙なことをしなくても、登録確認の返信メールを受けることはできる。バウンシングバック認証済みでないメールはペンディングキューに一定期間保管されるので、自分で取りに行けばよい。どのみち、正当なメールの送信者がバウンシングバック認証手続きをしてくれないかもしれないので、ベンディングキューを確認するのが受信者の日常作業として加わる。
　S25R方式では、正当なメールを受信できることはほぼ保証される（メールシステム管理者の手作業によって、またはtaRgreyなどの自動救済システムによって）。万一、来るはずのメールが来ないことがあっても、メールシステム管理者に言えば調査してもらえる。受信するスパムはゼロにはならないが、今まで一日100通のスパムを受けていた人の場合、素のS25R方式では3通程度、taRgreyでも7通程度（佐藤さんの発表に基づく）に減る。
　偽陰性判定された一日数通のスパムをメーラー上でごみ箱に捨てるか、正当なメールの偽陽性判定（バウンシングバック未認証）を心配して、メーラーの操作とは別の操作でたくさんのスパムの中から正当なメールを探し出す作業を毎日するか、ユーザーにとってはどちらが楽だろう？

やぎさんゆうびん問題

　白やぎさんが黒やぎさんにお手紙を送りました。
　黒やぎさんちをサービスエリアとする郵便局ではバウンシングバック認証をしているので、局長さんが白やぎさんにお手紙を送りました。「黒やぎさんにお手紙を送ったのは、本当に白やぎさん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」。
　白やぎさんちをサービスエリアとする郵便局でもバウンシングバック認証をしているので、局長さんが黒やぎさんちの郵便局の局長さんにお手紙を送りました。「白やぎさんにお手紙を送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」。
　黒やぎさんちの郵便局の局長さんは、白やぎさんちの郵便局の局長さんからのお手紙を見落としてしまいました。自分が出したバウンシングバック認証のお手紙が宛先不明で差し戻されてくること（バウンシングバック）があまりに多く、その中にバウンシングバック認証のお手紙へのそのまたバウンシングバック認証のお手紙が混じっているとは思いもしなかったのです。
　黒やぎさんちの郵便局の局長さんは、白やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、自分が白やぎさんに「黒やぎさんにお手紙を送ったのは、本当に白やぎさん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」と書いたお手紙は、白やぎさんに配達されませんでした。
　白やぎさんは、黒やぎさんちの郵便局の局長さんからの「ホワイトリスト登録手続きをしてください」というお手紙を受け取らなかったので、黒やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、白やぎさんからのお手紙は黒やぎさんに配達されませんでした。

　白やぎさんからお手紙が来るはずなのに来ないので、変だなあと思った黒やぎさんは、白やぎさんにお手紙を送りました。
　白やぎさんちをサービスエリアとする郵便局ではバウンシングバック認証をしているので、局長さんが黒やぎさんにお手紙を送りました。「白やぎさんにお手紙を送ったのは、本当に黒やぎさん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」。
　黒やぎさんちをサービスエリアとする郵便局でもバウンシングバック認証をしているので、局長さんが白やぎさんちの郵便局の局長さんにお手紙を送りました。「黒やぎさんにお手紙を送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」。
　白やぎさんちの郵便局の局長さんは、黒やぎさんちの郵便局の局長さんからのお手紙を見落としてしまいました。自分が出したバウンシングバック認証のお手紙が宛先不明で差し戻されてくること（バウンシングバック）があまりに多く、その中にバウンシングバック認証のお手紙へのそのまたバウンシングバック認証のお手紙が混じっているとは思いもしなかったのです。
　白やぎさんちの郵便局の局長さんは、黒やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、自分が黒やぎさんに「白やぎさんにお手紙を送ったのは、本当に黒やぎさん、あなたですか？そうなら、ホワイトリスト登録手続きをしてください」と書いたお手紙は、黒やぎさんに配達されませんでした。
　黒やぎさんは、白やぎさんちの郵便局の局長さんからの「ホワイトリスト登録手続きをしてください」というお手紙を受け取らなかったので、白やぎさんちの郵便局に自分をホワイトリスト登録する手続きをしませんでした。だから、黒やぎさんからのお手紙は白やぎさんに配達されませんでした。

バウンシングバック認証という無茶なやり方

　「ネオジャパンがスパム対策SaaSサービス，1通でもブロック漏れあれば返金」という情報を見つけた。韓国のヌリビジョンの「OptPlus」をサービス化したもので、スパム対策機能の一つとしてバウンシングバック認証というフィルタ機能を備えるという。
　バウンシングバック認証とは、初めてメールを送ってくる送信者に案内メールを返し、送信者がそれに従ってホワイトリスト登録手続きをすると受信者にメールが届けられるという仕組みだそうである。1月13日「厳しすぎる防御」で書いたmail.ruドメインのやり方に似て、無茶である。そりゃあ、ここまで無茶なスパム対策をすれば、「一通でもスパムを受信したら返金する」と豪語するほどの自信は持てるだろう。
　なぜ無茶か。メーリングリストや、メールマガジンや、オンラインショッピングの確認メールのことをちゃんと考えているとは思えないからである。
　メーリングリストの場合は、バウンスはメーリングリスト管理者へ行く。もしバウンシングバック認証を採用するサイトが増えたら、正当なメールを配信させるために、メーリングリスト管理者は大変な手間を強いられるだろう。メーリングリストの管理は相当神経を遣う仕事である。その上にさらに作業負担を強いられ、それが完璧にできなければ、配信を受けたかった受信者が受信できないことになる。
　メールマガジンの場合は、「このメールに返信されてもお答えできません」と断り書きがあることが多い。だから、バウンスを人が監視していないかもしれない。もしかしたら、バウンスを何度か受けたら自動的にアドレスをリストから削除してしまう仕組みのメールマガジンもないとは限らない。
　オンラインショッピングの確認メールの場合も同様である。確認メールの自動送信サーバの管理者が、バウンスを受けて一つ一つ手作業でホワイトリスト登録手続きをしてくれるとは期待できない。
　S25R方式にも、正当なメールを受け損なうリスクはある（2006年8月30日「リトライを短時間でやめるサーバ」、2006年9月1日「グレイリスティングを抜けられないサイト」）。しかし、そのようなまれなケースを除けば、送信者が追加の手作業をしてくれなければ受信できないということはない。正当なメールを救済する作業はもっぱら受信側で行うのがS25R方式のコンセプトだからである。
　S25R方式は、スパムの阻止率100%を達成することはできないが、正当なメールを受け損なうリスクの少なさにおいては、バウンシングバック認証よりもはるかにましである。

（この記事へ直接来られた方は、次の続編もご覧ください。）
やぎさんゆうびん問題
バウンシング・バック認証はやはりやっかい
バウンシング・バック認証の実装がヘボだと…
バウンシング・バック認証の破り方
「バウンシングバック認証」で検索上位
Opt Plusの機能を考える
「OptPlus」でも検索上位
バウンシング・バックはスパム受信を増やすかも
Opt Plusも失礼な受信拒否をしそうだ
バウンシング・バック認証のもう一つの穴
バウンシング・バック文例の問題点
バウンシング・バック認証に応じてもらえないケース
ペンディングキュー管理機能は使いやすいか？
メーリングリストはOpt Plusの鬼門
バウンシング・バック認証はタブーの技術
S25Rにもあるリスクだが…
Opt Plusの返金はない？
エクスパンションアドレスを設定していたら返金なし
Opt Plusの認証画面の脅し文句
Opt Plus売れていないんじゃないの？
（この記事を検索にかかりやすくするために、わざと「・」やスペースを挿入した題名に変えてあります。）

（関連記事）
日本の美徳
April fool

ブログ記事の正規表現も修正

　正規表現の間違いがあったので、このブログの過去の記事に書いた正規表現も修正した。

ホワイトリストファイルを提供

　ホワイトリスト情報のページに正当なホストの許可条件を記述していたが、ある人からのご要望により、ダウンロード可能なプレーンテキスト形式のホワイトリストファイルを分離して提供するようにした。ホワイトリストファイルのURLは
http://www.gabacho-net.jp/anti-spam/white-list.txt
である。

日経コミュニケーションに載るぞー

　日経コミュニケーションからS25R方式についての取材を受けた。6月1日発行号の「企業を熱くする最新テクノロジ」というコラムに載る予定である。どうぞお楽しみに。(^^)V

正規表現の間違い

　「ドットでない文字」の正規表現を今まで「[^\.]」と書いていたが、ある人に指摘されて、間違いだったことがわかった。「[ ]」の内側ではメタ文字をエスケープする必要はなく、「[^.]」が正しい。「[^\.]」は、「\」でも「.」でもない文字という意味になってしまう。ただし、FQDNに「\」が現れることはないので、間違った正規表現のままでも支障はない。
　ということで、論文を書き直した。ついでに、次の修正を加えた。

●ボットについて言及。エンドユーザーコンピュータからのスパムが多いのは、ボットに感染させたエンドユーザーコンピュータをスパマーが操るからだということは、論文を公開した当初はよく知らなかった。

●ホワイトリスト作成前の偽陽性判定率が約13%と推定されることを付記。

●ホワイトリスト登録の自動化技術（Rgrey、Starpit、taRgreyのこと）が提供されていることを付記。

　それと、微妙に言い回しを変えたのは、動的IPアドレスを使ったメールサーバのホワイトリスト登録の問題である。今まで「許可は困難である」と書いていたが、「許可にはリスクが伴う」という書き方にした。S25R方式がOP25BやIP25Bと同じように動的IPアドレスのメールサーバを排除するものだという誤解を避けるためである。