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で逆引きドメイン名の登録者を調べて通報することを思い付いた。

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

考え直して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は超メジャーなサイトなので、論文中のホワイトリストのサンプルにも掲載した。

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

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

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

2009.01.20 ■テトラビット専用サーバサービスでは、SPAM対策の一つである、S25R（Selective SMTP Rejection）方式を推奨します。 　「S25R」は、正しく運用することによって、有効なSPAM対策となります。 　SPAMメールでお困りのお客様はぜひ一度弊社までご相談をください。

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

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

　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などがある。

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

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

「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を攻略するには、メールサーバを経由するか、脆弱なサーバを侵害するか、ボットに長時間リトライさせるしかなく、いずれにしても大量スパム配信にはコスト高な方法をとらざるを得ないからである。

日本語のスパムを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

手ごわいスパム攻撃

　受信拒否されたら別のボットから送信を試みるというやり方と思われるスパムアクセスを、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方式でも防御が困難になるだろう。もっとも、ボットに何時間もリトライさせることは、スパマーにとってはコスト高な方法である。スパマーはそこまでやるだろうか。今後、スパマーの戦略がどうなるか、観察を続けようと思う。

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表記は引っかからなくなる。
　これで解決したとの報告をいただいたので、論文を修正した。

「&#64;」は効果がある

　ウェブページにメールアドレスを書くと、mailtoアンカーにしていなくてもスパマーにアドレスを拾われてしまう。このことは私の経験からも言える。
　アドレスを拾われにくくするには、HTMLファイル上（あるいはHTML記述が可能なブログ記事上）でメールアドレスの中の「@」を「&#64;」というナンバーエンティティに書き換える方法がある。これにより、メールアドレスを拾い集めるプログラムには「@」という文字が見えなくなる。私のウェブサイトの連絡先のページでも、この方法で「webmaster@gabacho-net.jp」というメールアドレスを表示している。
　あるウェブサイトで、「この方法もすでにスパマーに破られているので、安全ではない」と書かれているのを見たことがある。確かに、メールアドレスを拾うプログラムをPerlなどで書くならば、メールアドレスの構文を定義する正規表現を少し変えれば済むので、ナンバーエンティティによる防御を破るのは簡単だろう。
　しかし、この防御は今なおかなり効果的であるということは、統計が物語っている。6月22日から7月20日22時までのログに基づいて拒絶ログソーティングスクリプトでカウントした推定メッセージ数は、個人アドレス「deo」宛は521通だったのに対して、「webmaster」宛は106通しかなかった。
　「deo」は、私が所有するドメインの管理者のアドレスとして登録しているので、おそらくwhoisデータベースから漏れ続けているものだろう。「webmaster」は私のサイトに掲載し続けている。メールアドレスの情報源としてwhoisデータベースを狙うスパマーよりも、一般のウェブページを狙うスパマーの方がおそらく多い。だから、もし多くのスパマーがナンバーエンティティによる防御を破っているとすれば、「webmaster」宛に押し寄せるスパムは「deo」宛の1/5程度では済まないはずである。かつてはナンバーエンティティを使わず、かつmailtoアンカーにしていたことがあったので、そのころ拾われて今もスパマーのアドレスリストに残っている分もあるだろうということを考えると、ナンバーエンティティで書いた「webmaster」のアドレスはほとんど拾われていない、あるいは拾われているとしても非常に少ないと考えられる。

信じられない阻止率

　2007年9月から、私の息子のアドレス（私のサーバにアカウントを設けている）にスパムが着信し始めた。オンラインショッピング会社から「サーバが侵害されてお客様の個人情報が漏洩しました」という詫び状が郵送されてきたので、息子のアドレスがここからスパマーに漏洩したと思われる。
　着信したスパムの数は、次のように変化してきた。

2007年9月：	3通
10月：	2通
11月：	2通
12月：	3通
2008年1月：	6通
2月：	5通
3月：	11通
4月：	3通
5月：	2通
6月：	0通

　3月をピークに減り始め、5月16日を最後に着信が途絶えて、7月20日まで着信していない。着信が減ったのは、S25Rでブロックし続けたために、送達率を重視するスパマーの多くが息子のアドレスへの送信をあきらめたからに違いない。
　しかし、息子のアドレス宛のスパムアクセスが途絶えたわけではない。拒絶ログソーティングスクリプトに手を加えて息子のアドレス宛のアクセスを抽出してカウントした推定メッセージ数は、週50通ほどになっている。なのに9週間にわたって1通も着信していない。推定約450通押し寄せたスパムに対して阻止率なんと100%。「450通につき着信は1通未満」と考えても、阻止率は99.8%以上ということになる。
　おそらく、今も息子のアドレス宛にスパムを送り続けているスパマーのほとんどは送達率に無頓着。そういうスパマーは、サーバを経由させずにボットを使っているから、S25Rが大きく効いているのだろう。S25R方式がいかにボットに強いかを物語るデータだと思う。

エクスパンションアドレスを設定していたら返金なし

　前回の記事「OptPlusの返金はない？」を読み返していてふと気が付いた。
　返金プログラム申請フォームの「利用条件の確認」欄に、チェック条件の一つとして

「利用中のメールアドレスは、他のメールアドレス（エクステンションアドレスを含む）から転送もしくは設定していません」

というのがある。これをまともな日本語に直すと、

「利用中のメールアドレスには、他のメールアドレスから転送しておらず、また、エクステンションアドレスを設定してもいません。」

ということになるだろう。
　これは何を意味するか。エクスパンション（＝エクステンション）アドレスを設定していたら、通常のアドレスに宛てられたスパムが着信したとしても返金してもらえないということである。
　おそらく、スパムのメールヘッダを見ても、どのアドレスに宛てられて自分に届いたかがわからないことがあるからだろう^(*)。だから、たとえ通常のアドレスに宛てられたスパムだったとしても、エクスパンションアドレスに宛てられたものでなかったと証明できないので、返金には応じられないということになるのだろう。
　なんたることか。バウンシングバック認証方式の弊害を回避するために用意されているエクスパンションアドレスという機能を使わざるを得なくて使ったら、絶対に返金に応じてもらえないのである。そういうからくりを仕組んでおいて、「スパムを1通でも受けたら返金します」と宣伝している。これでは詐欺的である。

(*) Postfixの場合は、SMTPのRCPT TOコマンドで通知された受信者アドレスがReceivedヘッダの中に記録される。私が受信したスパムの例を示す。

Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236])  by a.reto.jp (Postfix)  with ESMTP id 204CC1C473 for <webmaster@gabacho-net.jp>;  Mon,  9 Jun 2008 21:18:07 +0900 (JST) …（略）… To: undisclosed-recipients:;

下線部が、RCPT TOコマンドで通知された受信者アドレスを示している。私は複数のアドレスでメールを受信しているが、どのアドレスに宛てられたメールだったかがここからわかる。しかし、MTAの機能あるいは設定によっては「for …」が記録されないこともある。

OptPlusの返金はない？

　Opt Plus ASPは「スパムを1通でも受けたら返金します」と豪語しているが、返金には条件がある。返金プログラム申請フォームの「利用条件の確認」欄に次のように書いてあり、すべての条件に適合することを利用者が誓約しなければならない。

□バウンシングバック機能はONにしていました □ホワイトリストに登録されていないメールアドレスからのスパム（迷惑）メールを受信しました □該当のメールはペンディングリストからインポートしたものはありません □利用中のメールアドレスは、他のメールアドレス（エクステンションアドレスを含む）から転送もしくは設定していません □同一のメールサーバもしくは同一ドメインからのメールではありません

　受けたスパムの送信者アドレスがホワイトリストに登録されているアドレスだったら、返金の条件からはずれる。このことから、知人のアドレスや、自分が受信しているメールマガジンのアドレスを送信者アドレスにかたったスパム（2007年5月27日「バウンシングバック認証の破り方」参照）を受けても返金してもらえないことがわかる。
　また、バウンシングバック認証にかけないように登録した別アドレスであるエクスパンションアドレス（上記の申請フォームではエクステンションアドレスと書いてあるが、同じ意味だろう）に宛てられたスパムも、返金の条件からはずれる。だから、メーリングリストにエクスパンションアドレスで参加したらアドレスが漏洩してスパムを受けたという場合（6月6日「メーリングリストはOptPlusの鬼門」参照）も返金されない。オンラインショッピングの確認メールをバウンシングバック認証にかけないようにエクスパンションアドレスを登録したら、そのオンラインショッピングのサーバが侵害されてアドレスが盗まれ、スパムを受けたという場合（実際、私の息子はそういう被害を受けている）も同様である。

　では、ホワイトリストに登録されていなかったアドレスからのスパムに対してバウンシングバック認証要求メールが返され、スパマーがまともに認証手続きをした場合、あるいは、送信者アドレスが実在の他人のものであり、アドレスをかたられてバウンシングバック認証要求メールを受けた人が認証手続きをした場合はどうか。これは「ホワイトリストに登録されていないメールアドレスからのスパムメールを受信しました」の条件が満たされ、他のすべての条件も適合するならば、返金の対象になるように思える。
　ところが、6月8日「バウンシングバック認証はタブーの技術」にコメントしてくださったPyTaさんは、この場合も返金の対象にならないのではないかと指摘しておられる。なぜなら、認証手続きが行われた時点でその送信者アドレスはホワイトリスト登録されるので、「ホワイトリストに登録されていないメールアドレスからのスパムメールを受信しました」の条件が満たされなくなるというのである。確かに理屈は通っている。
　PyTaさんいわく、OptPlusはホワイトリスト登録されたアドレスからしかメールを受けないシステム。だから、「ホワイトリスト登録されていないアドレスからスパムを受けた」という条件は成立し得ない。もしその条件が成立するなら、システムの根幹が壊れているということだから、請求すべきは返金でなく解約である――と。
　本当のところはどうなのかは、ベンダーに問い合わせてみなければわからない。しかし、PyTaさんは、ただ質問するだけでも住所や会社名が必須だというのでやめたとのこと。そこまで個人情報を明かさないと質問に応じてもらえないなら、私も問い合わせる気はない。
　Opt Plus ASPのサービスを買いたい人は（このブログを読んでもなおそう思う人はいないことを祈るが）、「スパマー自身またはアドレスをかたられた人が認証手続きをしたためにスパムが受信された時には返金されるのか」をベンダーに確認した方がよいだろう。

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

（続編）
エクスパンションアドレスを設定していたら返金なし

外国から礼状をいただいた

　外国の方から、「あなたのスパムフィルタリングの研究に感謝します」というメールをいただいた。外国からも反響があって非常にうれしく思う。
　その人は、フィルタリング条件を少し変更し、「3ヶ月間でスパムは70～80%減少、偽陽性判定は1件だけ」という効果を得たそうである。おそらく、偽陽性判定の確率を減らすためにフィルタリング条件を緩めたのだろう。独自のフィルタリング条件も工夫したかもしれない。それにしても、偽陽性判定が3ヶ月で1件だけとは驚きである。交信相手の中に逆引きを設定していないサイトがほとんどないのだろうと思われる。
　オリジナルのフィルタリング条件では、ブラックリストと併せて阻止率97～99%を達成できるが、阻止率を下げてでも偽陽性判定を避けたいというポリシーも当然あるだろう。そういう工夫はそれぞれのサイトの自由である。いろいろな工夫があってよい。そうした工夫は、私のオリジナルのアイデアがあってこそ生まれる。私はそのことを光栄に思う。

S25Rにもあるリスクだが…

　5月27日「バウンシングバック認証に応じてもらえないケース」を参照したはてなブックマークに、次のようなコメントが書かれていた。

「業者はあなただけじゃない、商機を逃す」って意見がいいねー でもそれS25Rでもありえるリスクでしょ。

　そのとおり。素のS25R方式でも、正当なメールを受け損なうことでビジネスチャンスを失うリスクはある。DNSBLでもベイジアンフィルタでも同様である。偽陽性判定からの救済を自動で行わないスパム対策方式すべてにそのリスクがある。
　ただ、そのリスクのコントロールのしやすさは異なる。
　OptPlusでは、初めてメールを送ってきた人のメールは、送信者がバウンシングバック認証に応じなければ、受信者のメールボックスに入らずにペンディングキューに留め置かれる。つまり、偽陽性と同等の状態になる。そこからの救済は各ユーザーの責任になる。ペンディングキューの内容が時々メールで通知されるので、差出人アドレスとサブジェクトを手がかりに、バウンシングバック未認証の正当なメールを救済する必要がある。
　S25R方式では、偽陽性判定された送信元ホストからはリトライアクセスが来る。それを発見してホワイトリストで救済するのはメールシステム管理者の責任である。もし正当なメールだったかもしれないリトライアクセスの救済が間に合わなかったのを発見したら、受信者に知らせて判断を委ねる必要がある。DNSBLでもベイジアンフィルタでも、拒否応答コードを「4xx」（再送要求）にして偽陽性判定からの救済を図っている場合は同様である。
　ビジネスチャンスになるかもしれないメールを受信し損なうことは、企業にとって損失になりうる。そこで、「偽陽性判定されたメールが受信者のメールボックスに届かない」ことをリスクととらえて、社を挙げてそのリスクの回避を図ろうとする場合、どんな対策が必要になるか（メールボックスに届いたメールをユーザーが見落とすリスクは、スパム対策のいかんにかかわらずありうるので、ここでは考えない）。OptPlusの場合は、「ペンディングキューを必ず確認せよ」というユーザー教育が必要になる。S25R方式の場合は、ログの監視とホワイトリスト登録、および救済に失敗したと思われるときの受信者への通知を作業手順として定め、メールシステム管理スタッフに守らせる必要がある。
　どちらの方がリスクコントロールがしやすいか。OptPlusでは、どんなにユーザー教育を徹底しようとしても、誰か一人でもペンディングキューの確認の作業手順を怠る確率はゼロにはしにくい（腰を落ち着けてメールを読むことができないほど忙しい人のことを考えてみてほしい）。それに対してS25R方式では、作業手順の教育をメールシステム管理スタッフだけに集中できる。少数のスタッフがログの監視とホワイトリスト登録の作業手順を確実に守ることにより、偽陽性判定されたメールが受信者のメールボックスに届かないというリスクを回避できる。もし救済が間に合わなかったとしても、受信者に知らせることにより、受信者から送信者に連絡をとってコミュニケーションをリカバーできる。
　リスク回避の対策の対象は、ユーザー一人一人に分散させるより、メールシステム管理スタッフに集中させた方がよい。その意味でも、OptPlusよりもS25R方式の方が安全なのである。

違法なHELOアドレスが増えている

　6月には、不正メールアクセス元ホストは7329個だった（うち、フィルタをすり抜けて着信させたものは14個、リトライが長時間続いたのでブロックを解除したらスパムだったのが5個）。そのうち、宛先サーバのIPアドレスまたは受信者のドメインを名乗るという違法なHELOアドレスを名乗ったホストは、驚いたことに4163個（56.8%）もあった。2007年6月の統計では、不正メールアクセス元ホスト6158個のうち違法なHELOアドレスを名乗ったものは866個（14.1%）だった。それに比べて極端に増加している。不正メールアクセスをしてくるホストは増えているが、HELOアドレスが違法でなかったホストの数は、2007年6月には6158-866=5292個だったのに比べて、今年6月には7329-4163=3166個とむしろ減っているのである。
　ただ、違法なHELOアドレスを蹴飛ばすという、副作用のまったくない対策だけでスパムの受信を56.8%前後減らせるかというと、そうとは言えないようである。HELOアドレスが違法でなかったホスト3166個のうち宛先が正しかったものは1066個（33.7%）だったのに対して、HELOアドレスが違法だったホスト4163個のうち宛先が正しかったものは174個（4.2%）しかなかった。つまり、宛先の正しいスパムを送り込もうとしたホスト1066+174=1240個のうちHELOアドレスが違法だったものは174個（14.0%）だから、違法なHELOアドレスのチェックだけではスパムの受信を14%くらいしか減らすことができないということになる（ホスト数とスパムメッセージ数はほぼ同じと仮定している）。
　このことから言えることは、違法なHELOアドレスを名乗るボットを使うスパマーの多くは、送達率に無頓着に（2006年9月15日「宛先の正しいスパムの阻止率」参照）でたらめのアドレスへ多くのスパムをばらまいており、そのようなボットが増えているということである。
　それにしても、なぜ違法なHELOアドレスを名乗るボットが増えているのだろうか。これによって何らかのスパムフィルタを突破できるわけではなく、むしろ、確実に不正なメールアクセスだと判断できる手がかりを与えるだけである。こんなアホなボットを使うスパマーの考えていることがさっぱりわからない。

「阻止率97%以上」

　「スパム対策技術」の目次ページに記載しているS25R方式の要点に

効果： ●スパムとウィルスメールの全アクセスに対する阻止率約99%。 ●宛先の正しいスパムの阻止率約97%。

と書いていたが、「宛先の正しいスパムの阻止率97%以上」と書き直した。宛先の正しいスパムの阻止率が1ヶ月ほどの統計で97%を下回ったことはほとんどなく、むしろ最近では98%くらいになることが多いので、効果をよりアピールする表現にした。
　でたらめのアドレスに宛てられたものも含む不正メールの全アクセスに対する阻止率は、99%を下回ることがあるかもしれないが、それでも98%くらいにはなっていると思う。S25R方式の効果は衰えていないので、「阻止率99%のスパム対策方式の研究報告」という論文のタイトルを今さら取り下げる気はない。おとりのアドレスを拾わせてわざとスパムアクセスを増やして統計をとった結果、2004年4月に阻止率99.1%になったというのは嘘ではないのだし。

バウンシングバック認証はタブーの技術

　届いたメールに対して「メールを送ったのは本当にあなたですか？」と確認を求めるメールを自動返送するバウンシングバック認証方式は、なにもOptPlusの開発元のヌリビジョン社の発明ではない。昔から使われている工夫である。
　たとえば、自動登録方式のメーリングリストでは、参加希望者が登録要求メールを送ると、登録確認要求メールが自動返送されてくる。そこにはパスワードが書かれていて、それをもう一度送信すると登録される。
　このバウンシングバック認証は、誰かが他人のアドレスをかたってメーリングリストに登録するといういたずらを防ぐためである。アドレスをかたられた被害者には、身に覚えのない登録確認要求メールは迷惑なものには違いない。しかし、これをしないことには、被害者は、望んでもいないメーリングリストの配信メールを多量に受けるという、より大きな迷惑を受けてしまう。被害者を大きな迷惑から守るために、メーリングリストの自動登録のバウンシングバック認証は必要なのである。そこが、スパマーにアドレスをかたられた被害者にとってはただ迷惑なだけのOptPlusのバウンシングバック認証要求とは異なる。
　メーリングリストの自動登録に昔から使われているバウンシングバック認証方式を、自分がスパムを受けないための対策に使えないかというアイデアを思い付いた人は、おそらく何人もいるだろう。しかし、メールシステムを理解している人はすぐにいろんな問題に気付く。

●メールトラフィックを増やすことになる。
●送信者に手間をかけさせるのは失礼ではないか？
●送信者が認証手続きをしてくれなかったら、正当なメールを見逃すおそれがある。
●自分が送信したメールのエラー差し戻しに対して認証要求をかけたら、エラーに気付かない。認証要求をかけないようにしたら、エラー差し戻しを装ったスパムを防御できない。
●スパマーに送信者アドレスをかたられた被害者に届くバウンシングバック認証要求は迷惑メールになる。
●送信側でもバウンシングバック認証方式をとっていたら、バウンシングバック認証要求のメールループが起こるから、その防止策も考えなければならない。
●送信側でもバウンシングバック認証方式をとっていたら、互いに相手からのメールに気付かないデッドロック状態（やぎさんゆうびん問題）に陥る。

これほどいろんな問題が懸念されることに気付いたら、「これじゃ使い物にならない」と思うだろう。
　メーリングリスト登録やその他のサービスの自動受付プログラムならともかく、人に宛てられたメールにバウンシングバック認証方式を適用することは、メールシステムを知る技術者にとってタブーだったのである。だから、スパム対策の研究者の間で議論にもなっていなかったのである。そのタブーを犯したのがOptPlusである。すべての問題を解決してタブーを破ったのなら賞賛もしようが、本質的に避け得ない問題をバウンシングバック認証方式は内在しているのである。
　企業の経営者層の人は、メールシステムをよく知らなくてバウンシングバック認証方式の問題点に気付かず、「OptPlusは画期的なスパム対策製品」という宣伝を鵜呑みにしかねない。バウンシングバック認証方式のタブーに漠然と気付いていながら、それを経営者層にうまく説明できない技術者は、OptPlusの導入を阻止できないかもしれない。そうなると、宛先の不正なバウンシングバック認証要求メールで他人に迷惑をかけ、また、ユーザーは、バウンシングバック未認証を心配してペンディングキューを見なければならない、メーリングリストに投稿する時にはFromヘッダのアドレスをエクスパンションアドレスに変えなければならないという不便を強いられるのである。
　バウンシングバック認証方式の問題に漠然と気付くのにとどまらず、緻密に考察して指摘してきたのは、おそらく私だけだろう。メールシステムをよく知らない人たちを、OptPlusを買わないよう説得するため、また、簡単で効果が高くて無料で使えて、すでに多くのサイトで使われている実績のあるS25R方式という対案があることを説明するために、2007年5月14日「バウンシングバック認証という無茶なやり方」に始まる私のバウンシングバック認証方式反対キャンペーンの一連の記事が役立てば幸いである。