送信ドメイン認証はスパムに勝てないだろう

前回述べた、迷惑メール対策について講演した某ISPの人は、送信ドメイン認証にえらくご執心のようだった。送信ドメイン認証のコンセプトは、「確固たるスパム対策のためには、送信者アドレスが簡単に詐称できるという問題を解決し、送信ドメインを信頼できるデータにすることが必要だ」というもの。多くの人がそう思っているだろう。
　私もかつては、送信ドメイン認証の普及と他の対策の併用によってS25R方式が不要になる時が来るだろうと思っていた。しかし今では、送信ドメイン認証はスパム問題の解決策にはならないだろうと思っている。スパマーが送信ドメイン認証を欺く方法があるからである。以下に、送信ドメイン認証の代表的な方式について、その原理と欺き方を述べる。

●SPF（Sender Policy Framework）
原理　送信側サイトは、自ドメインからのメールを送信するホストを自ドメインのDNSで宣言する。受信側では、受信したメールの送信ドメインでDNSを検索して、宣言された送信元ホストを知る。実際の送信元がそれと一致すれば、送信ドメインは詐称されていないと判断できる。
欺き方　スパマーは、使い捨てドメインを取得し、DNSで不当に広いIPアドレス範囲を送信元として宣言することにより、多数のボットからスパムを送信させてSPFチェックをパスさせることができる。このような手口は、仙石浩明さんが観測しておられる。

●DKIM（DomainKeys Identified Mail）
原理　送信側サイトは、公開鍵を自ドメインのDNSで公開する。そして、私有鍵を使ってメールヘッダとメッセージ本体から作った電子署名をメールヘッダに埋め込んで送信する。電子署名とは、データから生成したハッシュ値を公開鍵暗号方式における私有鍵で暗号化したものであり、私有鍵に対応する公開鍵でのみ復号できる。受信側では、受信したメールの送信ドメインでDNSを検索して公開鍵を入手し、それを使って電子署名を復号する。その結果、復号されたハッシュ値と受信側で生成したハッシュ値とが一致すれば、送信元は公開鍵に対応する私有鍵の所有者に違いない、すなわち、公開鍵を公開しているDNSのドメインの管理主体に違いないということになる。このことから、送信ドメインは詐称されていないと判断できる。
欺き方　スパマーは、使い捨てドメインを取得し、DNSで公開鍵を公開する。そして、私有鍵で作った電子署名を埋め込んだスパムを用意する。それを多数のボットから送信させれば、DKIMチェックをパスさせることができる。

　仮に送信ドメイン認証が普及したとしたら、スパマーは、送信ドメインを詐称したスパムを受信してもらえなくなるだろうから、詐称でない送信ドメインでスパムを送信しなければならなくなる。受信側では、受信してしまったスパムの送信ドメインは確かにスパマーのものだと判断できるから、それをブラックリストに登録して、以降、同じ送信ドメインのスパムを阻止できる。現状では送信ドメインは容易に詐称できるので、送信ドメインのブラックリストはまったく役に立たないが、その問題が改善され、送信ドメインのブラックリスト作りが意味のある作業になる。それが、送信ドメイン認証を推進している人たちの考えらしい。
　しかしスパマーは、送信ドメインを使い捨てることによって、相変わらずボットから大量のスパムを送信し、着信させることができるだろう。極端には、一つの送信ドメインで1種類のスパムを数億通ばらまいたらそのドメインを捨ててしまうというやり方も、ボットを活用できる限りはコスト的にペイするだろう。かくして、送信ドメインのブラックリスト作りのいたちごっこが復活するだけのことである^(*)。
　メールシステムの“偉い人”たちは、欺かれることが予見される送信ドメイン認証をなぜ一生懸命推進しようとするのだろうか。送信ドメインを詐称不可能なものにしなければならないという固定観念に凝り固まっているのではないかと思えてくる。
　仙石さんのブログ記事「迷惑メール送信者とのイタチごっこを終わらせるために (1)」にコメントした人は、書かれているアイデアがS25R方式に似ていることを指摘してS25R方式を批判し、「きちんと管理されたIPアドレスから送信されたメールを確認する提案ならば、SPFやDomainKeysの導入を進める方がよい」と言っているが、これはナンセンス。S25R方式は、スパムのほとんどを占めるボットからの送信に的を絞ることによって、（もちろん完全排除とはいかないものの）スパマーとのいたちごっこをほぼ終わらせた（なおかつ、1000サイト以上と推定される普及にもかかわらず、副作用による不達問題が騒ぎになってはいない）。これからの普及に期待する人が少なくないであろう送信ドメイン認証の方が、実はスパマーとのいたちごっこを終わらせることが期待できないのである。

(*) ブラックリスト作りはいたちごっこになるからホワイトリスト方式にすればよいと言う人がいるかもしれないが、ホワイトリスト登録された送信ドメインのメールのみを受け入れるというやり方は実用にならないだろう。未知の正当なドメインからのメールを受けるのに支障があるからである。ホワイトリスト作りのために送信者自身の手を借りるというのがバウンシングバック認証方式のコンセプトだが、それがいかに使い物にならないシステムであるかは、私がかつてさんざん指摘したとおりである。

続編：スパマー様御用達・送信ドメイン貸し出しサービスはいかが？

（関連記事）
送信ドメイン認証は誰にとって有益か

観念論

　3ヶ月ほど前のことなのだが、某ISPのセキュリティセミナーを聴きに行った。その中に、迷惑メール対策の演題があった。
　プレゼンテーションの中身は、「迷惑メールの動向」として4ページ、「迷惑メール対策」として2ページしかなく、「送信ドメイン認証技術」に12ページも費やしていた。「迷惑メールの現状とその対策」と題しながら、大半が送信ドメイン認証の話で、今どうすればスパムの被害を抑えることができるかという話はなく、そのISPで現状どのようにスパム対策を行っているのかという話もなかった。
　「迷惑メール対策」の項では、「安易な対策による弊害」と称して、今使われている対策では問題を起こすから困るのだと言わんばかりの説明。
　DNSBL（RBL）については、送信側から苦情が来ないと誤判定がわからないという問題を挙げていた。私だったら、DNSBLに引っかかったホストには応答コード「4xx」を返して、グレイリスティングにかけるか、ツールでリトライを発見することによって、正当な（かもしれない）メールを救済する方法をとるよう訴える。バウンシングバック認証方式のような、克服不可能な副作用のある対策方式とは違うのだから、使えない対策であるかのように批判して終わることはしない。
　グレイリスティングについては、「メール配送の遅延を招き、送信側サーバに負担を強いる」と。口頭で「ISPとしては困ることだ」と言っていた。2009年2月14日「「4xx」は迷惑か？」にも述べたとおり、「送信側サーバに負担を強いる」は観念論である。HELO、MAIL FROM、RCPT TOコマンドを再度やらされる処理に使われるCPUリソースやメモリリソースは、スパム1通を丸ごと受信する処理に比べてどれほどのものだと言うのか。相手サーバが受信してくれるまで送信メールがキューに5～30分程度滞留する^(*)ことによるディスクリソースの消費は、自サイトのユーザーに届いたたくさんのスパムが（ユーザーがダウンロードするまで）何時間も何日もスプールに滞留するのに比べてどれほどのものだと言うのか。生半可な知識を振りかざすアマチュアやセミプロにこういう観念論を主張する人がいることは知っていたが、ISPのプロまでがこんなことを言うとは驚いた。
　また、グレイリスティングの問題点として「迷惑メール送信側も対策することが可能」とも述べていた。それも、現実を見ていないという意味で観念論である。私は何年にもわたって、リトライするスパムアクセスの挙動を観察しており、グレイリスティングの突破率は1%くらい（あるいは時に2.6%）という統計結果を得ている。応答コード「4xx」で一時拒否する方法は、長期にわたってスパムの阻止に高い効果を保っているというのが事実である。
　大手ISPで技術を支える重要ポストにいる“偉い人”でもまともなことを言うとは限らないと認識した次第。

(*) 素のS25R方式では送信メールをキューに滞留させる時間は5～30分程度では済まないだろうと突っ込む人がいるかもしれないが、S25R方式はISPのメールサーバからのメールを一時拒否することはほとんどない。ISPのメールサーバの逆引き名がS25Rに引っかかることは少ないし、引っかかるとしても、ISPには送信するユーザーが多いので早期にそのメールサーバが発見され、ホワイトリスト登録されるからである。

続編：送信ドメイン認証はスパムに勝てないだろう

全ページにインデックスを設けた

　S25Rホームページの構成を変更し、全ページの上部と下部に他ページへのインデックスを設けた。これにより、どのページへ飛んで来た人も、全体にどのようなコンテンツがあるのかを一目で知ることができる。
　今まで、論文をちらっと見ただけでS25R方式を批判する人をなくそうと考えて、目次ページを案内するアラートを出すようにしていたが、その必要はなくなったので、アラートをやめた。アラートを出さないもう一つの論文ページpaper.htmlは不要になったが、ここへのリンクを公表している人がいるので、paper.htmlからは元の論文ページanti-spam-system.htmlへジャンプさせるようにした。
　また、この再構成に伴い、目次ページに掲載していたリンクと更新履歴はそれぞれ別ページに分離した。S25Rでメールがブロックされた人への説明は表紙ページ（index.html）へ移し、元の説明ページtrouble.htmlからはindex.htmlへジャンプさせるようにした。
　どのページからも、他のどのページへも目次ページを経由せずに直接飛べるのは、読者にとっては便利であろう。もっと早くこうすればよかったとは思うのだが、言い訳すると、こうするにはけっこう工夫が必要だったのである。
　インデックスはコンパクトに作る必要がある。他ページへの案内の情報をごちゃごちゃ書くと見にくくなるからである。しかし、コンパクトにするために文字数を減らすと、具体的に何の情報なのかがわかりにくくなることがある。このジレンマを解消するために、リンクにマウスカーソルを置くと説明が現れるようにした（こんな具合）。たとえば、拒絶ログソーティングスクリプトのページへのリンクは「監視ツール」と短く表記し、そこにマウスカーソルを置くと「S25Rスパム対策方式によって誤って阻止されているメールサーバを発見するのに有用なシェルスクリプト」という説明が現れるようにする。このテクニックを知って初めて、コンパクトなインデックスが実現した。
　各ページに他ページへのインデックスを置いたために、インデックスをちょっと修正するだけでも全ページを編集する必要があり、手間がかかる。しかし、読者の利便性とわかりやすさのためだから、手間を惜しんではいられない。

フィッシング詐欺のスパムを送信者アドレスで蹴る

　送信者アドレスのブラックリストはスパムの阻止にほとんど役に立たないので、今まで作っていなかった。しかし、前回述べた、こちらのドメインを送信者アドレスにかたったスパムを蹴る設定をしたのをきっかけに、送信者アドレスのブラックリストが役立つケースがあることに思い至った。
　2009年10月15日「48時間続いたスパムアクセス」と2010年3月28日「リトライするスパムたち」で、以下の送信者アドレスのスパムアクセスがあったことを述べた。

2009/10/11 paypal@60299.com
2010/03/13 paypal@800-500-6200.com
2010/03/15 paypal@71959.com
2010/03/18 MasterCard@10268.com
2010/03/23 paypal@51873926.com

また、これまでに、以下を送信者アドレスとするフィッシング詐欺のスパムがS25Rをすり抜けて着信していた。

2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com

　ユーザーIDがpaypalかMasterCardかVisaで、サイトドメイン名が数字のみか数字とハイフンから成るというきわめてわかりやすい特徴。蹴る条件はこの二つで十分で、トップレベルドメインがcomであることは条件に含めなくてよいだろう。
　前回述べた設定でのsender_restrictionsファイルに以下を追記した。

/^(paypal|mastercard|visa)@[0-9-]+\./ REJECT

　送信者アドレスにこの特徴を持つスパムアクセスはメールサーバの挙動でリトライするようなので、taRgreyなどで自動救済をしているサイトでは着信してしまう。このフィルタを設定しておけば、わずかながらもフィッシング詐欺のスパムの着信を減らすのに役立つだろう。

嘘つきfromを蹴る設定

　<deo@gabacho-net.jp>宛で送信者アドレスも<deo@gabacho-net.jp>にしたスパムアクセスが目立つ。今のところすべてS25Rで阻止できているのだが、S25Rをすり抜けたら癪なので、このような嘘つきfromを蹴る設定をしてみた。
　main.cfファイルのsmtpd_sender_restrictionsパラメータに以下の太字の行を追加する。

smtpd_sender_restrictions =   permit_mynetworks,   check_client_access hash:/etc/mail/dracd,   reject_non_fqdn_sender,   reject_unknown_sender_domain,   check_sender_access regexp:/etc/postfix/sender_restrictions

　「check_client_access hash:/etc/mail/dracd」は、DRACを使ったPOP-before-SMTP認証で送信した場合に送信者アドレスにかかわらず許可するための指定である。SMTP認証を使う場合は「permit_sasl_authenticated」を指定する。
　sender_restrictionsファイルには以下のように記述する。私はgabacho-net.jpとreto.jpの二つのドメインを運用しているので、これらが送信者ドメインであれば蹴るようにする。

/@(.+\.)?gabacho-net\.jp$/ REJECT /@(.+\.)?reto\.jp$/ REJECT

　S25Rをすり抜けられた場合をシミュレートするために、モバイル接続に使っているbmobile.ne.jpを一時的にホワイトリスト登録し、PCをモバイル接続して自分宛のメールを送ってテストした（自分宛なので、第三者中継を禁止するreject_unauth_destination指定には引っかからない）。POP-before-SMTPを行わなければ「554 Sender address rejected」とブロックされ、行えば送信できることが確認できた。
　組織サイトでは、この対策を取り入れるかどうかは慎重に検討していただきたい。単純なエイリアス定義によるメーリングリストが他サイトにあって、自サイトのユーザーがそこに投稿したメールが自サイトへ戻って来る場合、そのメールを蹴ってしまうからである。Majordomoやfmlなどのプログラムを使ったメーリングリストでは、送信者アドレス（エンベロープfrom）がメーリングリスト管理者のエイリアスに書き換えられるので、支障はない。今時、サイトをまたがった転送を行うメーリングリストをエイリアス定義だけで作るという危ない運用はあまりないとは思うが、ユーザーがそういうメーリングリストに関わっていないかどうかは確かめた方がよい。

公開ホワイトリストが1,200件突破

　公開ホワイトリストの登録件数は、5月初めの時点で約800件だった。5月4日に、約1,000のメールアカウントを運用する会社の人から約470件のホワイトリストの提供をいただいて、5月5日に掲載した。これで登録件数は約1,270件になった。大規模サイトでは1,000件ほどになると聞いていたが、ついにそれよりも多くなった。
　ホワイトリストファイルは96,617バイトになった。64kbpsのISDN回線では、スループットを56kbpsとして、ダウンロードに約14秒かかるようになっていたところだった。光回線を入れた後でよかった。

便利な時代になったものだ

　自宅にサーバを置いてGabacho-Netを開設したのは、11年前の1999年5月のことである。接続サービスにはOCNエコノミーを利用した。当初月額39,900円（税込み）、1999年10月からは33,600円と、今から見れば高額だが、128kbps（当時の規格ではメタリック回線で最速）の常時接続を初めて庶民の手の届くものにしたサービスである。
　2002年8月に、フレッツISDNに切り替えた。ISDNの基本料金が月額2,919円、フレッツISDNサービス料が2,940円、OCNのフレッツISDN対応IP8が7,140円で、計12,999円。OCNエコノミーよりもずっとコスト削減になった。回線速度は64kbpsと半分になったが、メールの送受や軽いウェブページの発信にはさほど不便ではない。当時すでにxDSLサービスは始まっていたが、雷などの電気的外乱に弱い変調正弦波を使うxDSLよりも、安定性の高いパルス波を使うISDNをあえて選んだ。
　そして今年4月に光回線に切り替えた。フレッツ光の料金が月額5,460円、インターリンクのフレッツ光ファミリータイプ対応のIP8が7,350円。さらに今日（5月8日）、ISDNをひかり電話に切り替えた。これで電話の基本料金が525円で済む。合計13,335円。フレッツISDNを使っていた時よりも336円だけ高い費用で100Mbpsのインターネット接続環境が手に入ったことになる。ちなみに、OCNで同じくIP8を利用するにはこれよりも12,390円高くなる。
　ひかり電話を利用するには、ルータをNTTからレンタルするひかり電話ルータに交換する必要がある。ひかり電話ルータは6日に届いた。複数のグローバルIPアドレスを割り当てたインターネット接続にも使えるルータなのだが、説明書がプロ向きでないために、使い方をマスターするのにかえっててこずった。ひかり電話ルータの設定を始めるためには、光回線を現用のルータからはずしてひかり電話ルータに接続しなければならなかったことや、ルータを切り替えた後にDNSクエリーの入りパケットがなぜかIPフィルタで許可されないというトラブルなどで、私のサイトへのアクセスが時々不通になった。アクセスしようとした方々にはご不便をおかけしてすみませんでした。すべての問題が解決したのは、NTTの局側でひかり電話への切り替え工事が行われた後だった。
　11年前のOCNエコノミーに比べて、回線速度は780倍、費用は1/3。便利な時代になったものである。これで、今まで我慢していたAKB48の動画も楽しめるようになった。

　ところで、今日の朝、ペットのハムスターが突然死した。早朝の5時ころ、籠から出たがっていたので出してやったら、6時半ころ、衣装ケースの陰で死んでいるのが見つかった。手を差し出すと乗り、籠の外で遊ばせると私の体によじ登ったりして、心を癒してくれる家族の一員だった。ひかり電話への切り替えが今日の午前に予定されていたので、悲しみに耐えながら作業しなければならなかった。息子が動物病院へ行って心停止を確認してもらってきた。死因はわからない。

回線の切り替え

　今まで、私の家のインターネット接続はISDN回線だったが、4月21日に光回線（フレッツ光）を入れた。インターリンクのIP8をオンラインで契約し、その日のうちにクライアントPCのインターネット接続が開通した。インターリンクは、複数IPアドレスでも即刻払い出され、しかも逆引き名を自分のドメインのものに設定できるので、非常に便利である。さらに、フレッツ光ファミリータイプ対応のIP8で月額7,350円と他のISPより安い。
　23日に、予備サーバを新しいメインサーバに仕立てて光回線に接続し、Gabacho-NetのIPアドレスを新サーバ（116.58.188.194）に振り向けた。さっそく新サーバにウェブアクセスやメールアクセスが入ってきているが、多くのサイトで旧アドレスのDNSキャッシュが残っているので、24日朝現在、まだ旧サーバ（219.163.213.18）にもかなりのアクセスがある。
　掲示板にアクセスした時に「サーバを切り替えました」というタイトルの記事が見えたら、新サーバにアクセスできている。「サーバ切り替えのため投稿中止」というタイトルの記事が見えたら、それは旧サーバで、投稿不可の状態になっている。DNSキャッシュが切り替わっていないためなので、切り替わるまでお待ちください。なお、私のウェブサーバは仮想ホストの設定をしているため、URLに新サーバのIPアドレスを指定してもGabacho-Netのコンテンツを見ることはできないので、ご了承ください。
　光回線につながった新サーバにアクセスできるようになったら、S25Rホワイトリストなどの大きなファイルのダウンロードが速くなると思う。
　ところで、新サーバから旧サーバへインターネット経由でpingが飛ぶのに逆方向には飛ばないというトラブルでどつぼにはまってしまった。原因は、光回線のルータでIPマスカレードの対象IPアドレスをプライベートIPアドレスだけにしなければならないのに、デフォルトの「すべて」に設定していたためだった。そのため、サーバのIPアドレスもNATでIPマスカレード用IPアドレス（ルータのIPアドレスと同じ）に変換されたので、外へのアクセスはできるが、外からサーバにはアクセスできなかったのである。

リトライするスパムたち

　2月28日から3月28日までの間にあった、メールサーバの挙動を示すリトライアクセスで、スパムに違いないと判断して放置したものを紹介する（リトライ期間が5分未満であるためにグレイリスティングを突破しないと考えられるものは除いている）。リトライするスパムの挙動の観察は個人サイトでないとやりにくいだろうし、その観察結果を公表する人は他にほとんどいないだろう。グレイリスティングを突破するスパムの状況として参考になれば幸いである。
　リトライ間隔とリトライ期間がわかるように、各リトライシーケンスについて最初2回と最後2回のアクセスを示す。

Mar  1 01:10:33 168-143-90-82-compute-ag1-ash01.opsourcecloud.net [168.143.90.82] from=<> to=<deo@gabacho-net.jp> helo=<168-143-90-82-compute-ag1-ash01.opsourcecloud.net>
Mar  1 01:24:30 〃
…
Mar  1 12:42:00 〃
Mar  1 12:54:06 〃

　送信者アドレスが空アドレスなのは、正常ならばエラー差し戻ししかあり得ない。エラー差し戻しを受ける心当たりはないので、これはスパムかウィルスメールに違いない。

Mar  6 02:29:55 unknown [74.50.95.24] from=<dogbreedernetwor@dogbreedernetwork.org> to=<deo@gabacho-net.jp> helo=<win1.worldplanethosting.com>
Mar  6 02:30:57 〃
…
Mar  8 00:22:29 〃
Mar  8 04:22:33 〃

　人のメールアドレスとは思えない送信者アドレス。また、私が知らない人からの初めてのメールは「deo」でなく「webmaster」に送られてくるはず。だからスパムに違いない。

Mar  8 00:06:03 unknown [218.241.81.77] from=<charlesela111@aol.com> to=<deo@gabacho-net.jp> helo=<mail.nexcom.cn>
Mar  8 05:49:58 〃
…
Mar 12 17:37:44 〃
Mar 13 01:54:43 〃

　aol.comドメインを名乗りながら送信元ホストが逆引きできないこと、HELOアドレスが中国の国ドメインであることから、中国のサーバからばらまかれているスパムと考えられる。

Mar 13 02:53:14 LAubervilliers-153-53-26-210.w217-128.abo.wanadoo.fr [217.128.153.210] from=<paypal@800-500-6200.com> to=<deo@gabacho-net.jp> helo=<mrravieres.com>
Mar 13 02:54:15 〃
…
Mar 15 02:43:09 〃
Mar 15 02:58:21 〃

　PayPalをかたったフィッシング詐欺のスパムであることは間違いない。

Mar 15 15:31:39 unknown [213.42.154.10] from=<paypal@71959.com> to=<deo@gabacho-net.jp> helo=<mailfw.protools-uae.com>
Mar 15 15:54:58 〃
…
Mar 17 07:25:44 〃
Mar 17 08:49:19 〃

　これもPayPalをかたったフィッシング詐欺のスパム。

Mar 18 20:52:36 s142-179-185-85.ab.hsia.telus.net [142.179.185.85] from=<MasterCard@10268.com> to=<deo@gabacho-net.jp> helo=<gpserver.powell.local>
Mar 18 20:53:38 〃
…
Mar 19 23:59:15 〃
Mar 20 00:14:16 〃

　マスターカードをかたったフィッシング詐欺のスパムに違いない。

Mar 23 22:48:30 173-9-52-225-NewEngland.hfc.comcastbusiness.net [173.9.52.225] from=<paypal@51873926.com> to=<deo@gabacho-net.jp> helo=<mail.tristateneuro.com>
Mar 23 22:49:31 〃
…
Mar 25 22:33:47 〃
Mar 25 22:48:49 〃

　これもPayPalをかたったフィッシング詐欺のスパム。

Mar 24 04:21:10 133-20.trifle.net [195.24.133.20] from=<german3627@gmail.com> to=<deo@gabacho-net.jp> helo=<kit2005.com>
Mar 24 04:36:28 〃
…
Mar 25 21:38:48 〃
Mar 25 23:01:49 〃

　gmail.comドメインを名乗るメールが、聞いたこともない逆引きドメインから送られて来ていて、HELOアドレスも聞いたこともないドメイン。スパムによくあることである。

Mar 26 05:06:18 94.41.229.45.dynamic.str.ufanet.ru [94.41.229.45] from=<deo@gabacho-net.jp> to=<deo@gabacho-net.jp> helo=<mx3.aol.com>
Mar 26 05:11:20 〃
…
Mar 26 05:26:28 〃
Mar 26 05:31:31 〃

　受信者アドレスと同じ送信者アドレスをかたるのも、スパムによくある。自分がモバイルPCなどから自分宛に送信したわけではないのだから、当然スパムと断定できる。

　グレイリスティングを突破するスパムアクセスは、以上9通。拒絶ログソーティングスクリプトでカウントした推定メッセージ数は342通（偽陽性判定を除く）なので、グレイリスティングの突破率は2.6%ということになる。2年前の2008年3月22日には「グレイリスティングの突破率は1%くらい」と報告したが、それより高くなっている。しかし、スパマーがグレイリスティングを攻略しつつあると断言するのは早計である。リトライするスパムアクセスがたまたまここ1ヶ月に多かったのかもしれない。もっと多くの統計をとってみなければはっきりしたことは言えない。
　なお、2月28日から3月28日までの期間で、推定メッセージ数は342通、受けたスパムは3通なので、阻止率は99.1%であった。

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