30分リトライするスパムアクセス

　約5分間隔で30～31分リトライするスパムアクセスが2件見つかった。アクセス元はSMTPに応答しない。だからといってメールサーバでないとは断言できないが、ボットである可能性がある。

Jan 28 05:15:16 unknown [61.6.68.118]
Jan 28 05:20:22 unknown [61.6.68.118]
Jan 28 05:25:29 unknown [61.6.68.118]
Jan 28 05:30:35 unknown [61.6.68.118]
Jan 28 05:35:42 unknown [61.6.68.118]
Jan 28 05:40:48 unknown [61.6.68.118]
Jan 28 05:45:55 unknown [61.6.68.118]

Jan 30 02:06:20 unknown [92.113.198.254]
Jan 30 02:11:30 unknown [92.113.198.254]
Jan 30 02:16:40 unknown [92.113.198.254]
Jan 30 02:21:50 unknown [92.113.198.254]
Jan 30 02:26:58 unknown [92.113.198.254]
Jan 30 02:32:09 unknown [92.113.198.254]
Jan 30 02:37:43 unknown [92.113.198.254]

（1月31日追記）
　リトライパターンが同じ。ボットなのは間違いなさそう。

Jan 31 08:17:43 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:22:51 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:28:00 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:33:07 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:38:18 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:43:31 m85-94-186-66.andorpac.ad [85.94.186.66]
Jan 31 08:48:42 m85-94-186-66.andorpac.ad [85.94.186.66]

スパム送信サーバが4時間リトライ

　以下のようなリトライアクセスが見つかった。

Jan 25 15:04:30 unknown [219.234.95.15] from=<khfwkbrLeroy@olten.ch> to=<deo@gabacho-net.jp> helo=<hrwl.com.cn>
Jan 25 15:34:36 〃
Jan 25 15:40:38 〃
Jan 25 15:46:37 〃
Jan 25 16:47:38 〃
Jan 25 16:52:44 〃
Jan 25 16:57:50 〃
Jan 25 18:57:55 〃
Jan 25 19:03:57 〃
Jan 25 19:09:57 〃

　送信者アドレスのユーザーIDが無意味な長い文字列を含むのがいかにも怪しい。HELOアドレスが中国の国ドメインなのに送信者アドレスがスイスの国ドメインであることも怪しい。
　リトライは4時間5分で止まった。アクセス元にSMTPアクセスしてみたらMTAが応答し、HELOアドレスと同じホスト名を答えたが、人が送信したメールを中継する正当なメールサーバならもっと長く（少なくとも24時間）リトライするだろう。中国はスパム送信の多い国であることからも、スパム送信を目的としたサーバであることが考えられる。
　経験上、リトライが30分以上続いたら送信元はボットでなくメールサーバだと思ってほぼ間違いない。しかし、メールサーバから送信されるスパムもある。このようなアクセスがグレイリスティングを突破するのはやむを得ないが、素のS25R方式では、正当なメールらしいと判断したらすみやかにホワイトリスト登録し、怪しいとにらんだら数時間放置してみるという処置ができる。
　とはいえ、組織サイトでは、メールシステム管理者の勝手な判断で受信者が不利益をこうむるおそれがある。怪しいとにらんだ時には、受信者に「送信者アドレスに心当たりがありますか？」と問い合わせた上で処置を決めるのがよいだろう。
　受信者からすみやかに回答が得られなかった場合は、とりあえず24時間以内にホワイトリスト登録するのが無難であろう。その際、スパムかもしれないと思ったが通過させた旨を受信者に知らせ、スパムだったら知らせてもらって、ホワイトリスト登録を解除する。
　あるいは、スパムの可能性が非常に高いと判断したら放置して、受信者から回答が来る前にアクセスが止まったらアクセスの記録を知らせるという処置でもよいだろう。もし受けたかったメールだったならば、ホワイトリスト登録を申請してもらって、受信者から送信者に再送を依頼すればよい。

（参考）
　スイスの国ドメインchは、ラテン語国名「Confoederatio Helvetica」に由来する。国名を四つの公用語で併記する代わりに単独で表記する国名として、どの言語話者にも不公平にならないようにラテン語を使っているのである。

日本の美徳

　前回、善良な送信者に迷惑をかけまいという気配りの心が私にあったからS25R方式は実用的なものになったと述べた。気配りの心を自分の美点と自慢するつもりはない。むしろそれは、たいていの日本人が持っている、日本が世界に誇れる美徳だと思う。
　ロシアのmail.ruは、初めてメールを送ってくるホストをことごとく応答コード「550」で受信拒否し、送信者にホワイトリスト登録申請を要求している（2007年1月13日「厳しすぎる防御」）。インドのedkal.comは、正当なメールを誤判定して応答コード「550」で突き返している（2007年11月4日「失礼な受信拒否」）。アメリカのieee.orgもedkal.comと同じことをやっていることがわかった。

<***@computer.org> (expanded from <***-outgoing>): host     hormel.ieee.org[140.98.193.224] said: 554 5.7.1 Message scored extremely     high on spam scale.  No incident created. For details, send to     postmaster@ieee.org. You can also send a plain text message to the     recipient and request adding your address to his/her UCE whitelist. (in     reply to end of DATA command)

　スパムを受けないためには正当なメールを間違って、あるいは故意にバウンスさせてもかまわないというやり方は信じられない。私だけでなく、たいていの日本人は同じことを思うのではないだろうか。この荒っぽさが大陸民族の文化というものなのだろうか。
　日本人ならこんなことはしないだろう。正当なメールを必ず受信できる完璧さをユーザーが求めるからということもあるが、メールシステム管理者は、メールを受信できないと困るユーザーに気配りし、善良な送信者に迷惑をかけないようにとも気配りする。「和を以って貴しと為す」という文化の中で育った日本人にとって、それはごく当たり前のことである。日本人の島国根性には「出る杭は打たれる」などの悪い面もあるが、他人への気配りは日本の美徳^(*)だと思う。
　韓国製のOptPlusに実装されたバウンシングバック認証方式のコンセプトも、私には理解しがたい。善良な送信者に認証手続きの手間を要求することを失礼だとは思わないのだろうか。スパマーに送信者アドレスをかたられた被害者にバウンシングバック認証要求メールを殺到させることを申し訳ないとは思わないのだろうか。自分がスパムの被害から助かりさえすればよいという観念も大陸文化なのだろうか。
　日本の美徳をわきまえた日本人にはOptPlusは売れないと思う。OptPlusを買っている人は、S25R方式を知らないに違いない。両方を知る人ならきっとS25R方式を選ぶ（なにしろ無料だし）。日本の気配りの文化をわきまえず、OptPlusが日本で売れると思って輸入したベンダーのビジネス感覚が、私には理解できない。
　S25R方式は、注意深く運用すれば、受信者にも善良な送信者にも迷惑をかけない。メール送信サーバにメールを一時滞留させることはあるが、送信者を困らせることはないし、手間をかけさせることもない。正当なメールの受信が遅延することはあるが、ちゃんと届く。私は、ユーザーへの気配りに根ざしたS25R方式を日本発のアイデアとして誇る。そして、開発者の私を育んだ日本の文化を誇る。

(*) ラフカディオ・ハーンの来日後の人生を描いたテレビドラマにこんなシーンがあった。ある女性が、夫の死のことを話しながらほほえんだ。ハーンは、悲しいのになぜ笑うのかといぶかしく思った。後に彼は、それは自分の悲しみを相手に押し付けまいとする気配りで、日本の美徳なのだと理解した。

僕って天才？

　日経BP社・ITproの「記者のつぶやき」に「昨年は「XP上で動くICAサーバー」と「S25R」に感動」という記事がある。1月17日の掲載である。S25R方式に対していただいている賛辞を要約すると、次のとおりである。

S25Rという創意工夫は、言われてみれば当たり前のことだが、普通の人には発想することのできない天才的なひらめきだ。記者がこれを知ったのは2007年も後半になってから。UNIXシステム管理をライフワークとしてきた記者が知らなかったのはまったくの不覚。受信側メールサーバにSMTP接続をしてくるクライアントがメールサーバなのかエンドユーザーコンピュータなのかを知るすべがないという思い込みがあった。逆引き名の文字列で判別しようという発想の転換が、まさにコロンブスの卵のごとき世紀の大発見なのである。

　天才的とまで絶賛されると気恥ずかしい。発想のきっかけは2006年10月21日「無精者の勝利」に書いた。思い付いたのは2003年5月。スパムが急に増え始めたのがきっかけだったが、スパムアクセス数はまだ今の1/10くらいのころだった。postgreyもDNSBLも知らなかった。Postfixが備える機能を利用して効率的にスパムをはじく方法を工夫した。大して高いスキルのない自分でもできる方法を考えたのである。
　個人用メールサーバを運用していたことが幸いした。組織サイトでこんな実験は危なくてできない。個人サイトでありながら、8個ブロックのIPアドレスをもらって逆引き権限の委譲を受けていることも幸いした。ドメイン管理者ならサーバにどのような名前を付けたがるかという思考ができた。S25Rに引っかかるお仕着せの逆引き名がISPから割り当てられる、IPアドレス1個の安い接続サービスを使っていたら、「そのようなサーバを拒否しても、ホワイトリストで救済すればよい」という発想はしにくかったかもしれない。
　「スパムの送信元には逆引きできないものが多いので、それを蹴ってみよう。次に、逆引きできても逆引き名がIPアドレスをそのまま反映したものも多いので、それも蹴ってみよう」――ここまでは、ほかの人でも容易に発想できたと思う。
　私がオリジナリティを誇るとすれば、その後の段階である。逆引き名からアクセス元を高い確度でエンドユーザーコンピュータと推定するための規則をわずか六つの正規表現に類型化した。これは、世界の誰もやっていなかった。数千回に及ぶ不正メールアクセスの逆引き名から単純な法則を見出したのは、私の特異な能力によるものかもしれない。これを「天才的」と褒めていただけるなら、私は喜んでお褒めを拝受しよう。
　これだけでは、S25R方式は使い物にならなかった。私は、誤判定される正当なメールを受信し損なわないために最善を尽くした。その方法も発表した。それは簡単な仕事である。ログの監視とホワイトリスト登録という単純作業を継続する忍耐があればよい。それは天才的な成果ではない。ただ、その背景として、善良な送信者に迷惑をかけまいという、他人への気配りの心が私にあった。だから、S25R方式は多くの人に受け入れられる実用的なものになった。それも私は誇ってよいことだと思う。
　そしてあと一つ、私が誇れるのは、スパムに困っている人々とのコミュニケーションを大切にしていること。質問には必ず答え、問題の解決のために支援する。また、善意の協力者から寄せられるホワイトリスト情報を感謝して受け取り、それをほかの人たちのために公開する。こうした活動を地道に続けている。このことにかけては私は無精者ではないのである。
　“天才的なひらめき”も、それだけで世の中に役立つものになるというものではない。「他人が使えるか」、「他人が困らないか」という、他人を思いやる思考も必要なのである。

属性ラベルホワイトリストの例外

　2007年9月14日に属性ラベルホワイトリストのアイデアを提案した時、最近はne.jp以外の属性型jpドメインからの不正メールアクセスがまったく来ないと述べたが、嘘だった。すみません。前回示したjpドメインからの不正メールアクセスの中に、asahi-net.or.jpからのものがあった。
　エンドユーザーPCをインターネットに直結させているISPで、or.jpを冠しているものがある。そこで、ウェブアクセスログからそれらしいクライアントを拾い出した結果から、一般規則に引っかかるパターンを属性ラベルホワイトリストの例外とする設定方法を考えた。以下にそれを示す。

…（ホワイトリスト）…
…（ブラックリスト）…
/^[^.]*[0-9]{5}.*\.asahi-net\.or\.jp$/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.coara\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.din\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.fitweb\.or\.jp/ 450 S25R check, be patient
/^[0-9].*\.iij4u\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]\.[^.]*[0-9]\.iij4u\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]{5}.*\.janis\.or\.jp$/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.mitene\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9][^0-9.]+[0-9].*\.plala\.or\.jp/ 450 S25R check, be patient
/^[^.]*[0-9]\.[^.]*[0-9]\.tokai.or\.jp/ 450 S25R check, be patient
/\.(ac|ad|co|ed|go|gr|lg|or)\.jp$/ OK
/\.(pref|metro|city)\.[^.]{3,}\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]{3,}\.jp$/ OK
…（一般規則）…

　ここまでやるくらいなら、属性ラベルホワイトリストから「or」を削除してもよいかもしれない。
　もっとも、公開ホワイトリストが充実してきたので、属性ラベルホワイトリストを取り入れている人はいないかもしれないが。
　なお、asahi-net.or.jp以外の上記ドメインからの不正メールアクセスは、少なくともここ1ヶ月、観測されていない。

jpドメインからの不正メールアクセス

　国内のISPにはOP25B（Outbound Port 25 Blocking）がかなり広まったらしく、私がS25R方式を開発中だった2003～2004年ころに比べて、国内からの不正メールアクセスがめっきり減った。そこで、国内サイトで偽陽性判定を減らすために、日本のIPアドレスを全部許可する方法を提案しようかと考えていた。しかし、やめた。調べてみたら、国内からの不正メールアクセスはまだ途絶えたとは言えないことがわかったからである。
　以下は、2007年12月16日から2008年1月15日21時までの拒絶ログから、逆引きFQDNがjpドメインのものを拾い出した結果である。日時、逆引き名、拒否応答コードを示している。なお、Q&AのページのQ/A2-5で説明している設定によって、明らかに不正とわかるアクセスと宛先誤りのアクセスをS25Rチェックに優先してはじくようにしている。応答コード「550」のものはuser unknownエラー、「450」のものは宛先が正しくてS25Rチェックではじいたものである。

Dec 16 21:26:18 p3242-ipbfp1401osakakita.osaka.ocn.ne.jp 450
Dec 18 20:33:48 t01.combzmail.jp 550
Dec 19 03:25:30 203.141.132.142.static.zoot.jp 550
Dec 19 04:01:37 p1024-ipbf09takakise.saga.ocn.ne.jp 550
Dec 19 10:24:36 61.206.118.155.static.zoot.jp 550
Dec 19 22:37:14 203.141.132.142.static.zoot.jp 550
Dec 20 12:39:03 203.141.132.142.static.zoot.jp 550
Dec 21 14:53:23 opt-125-215-101-221.client.pikara.ne.jp 550
Dec 21 16:15:32 u004425.ueda.ne.jp 450
Dec 22 15:18:21 202-71-93-92.ap-w01.bb-west.ne.jp 450
Dec 23 04:33:46 203.141.132.142.static.zoot.jp 550
Dec 25 06:52:21 p2057-ipbf04motosinmat.mie.ocn.ne.jp 450
Dec 25 19:37:54 p6230-ipbf201sapodori.hokkaido.ocn.ne.jp 550
Dec 28 00:40:13 122x212x213x69.ap122.ftth.ucom.ne.jp 450
Dec 28 16:45:00 61.206.118.99.static.zoot.jp 550
Dec 29 01:55:10 61.206.118.99.static.zoot.jp 550
Dec 31 22:58:05 214.net059086069.t-com.ne.jp 550
Jan  2 07:19:05 p2225-ipbfp405yosemiya.okinawa.ocn.ne.jp 450
Jan  2 11:07:47 p1198-ipad12matuyama.ehime.ocn.ne.jp 450
Jan  3 01:10:56 p670c8e.tkyoea09.ap.so-net.ne.jp 550
Jan  3 21:14:23 p6083-ipad13fukuokachu.fukuoka.ocn.ne.jp 550
Jan  6 07:34:28 catv303135.tac-net.ne.jp 550
Jan  8 14:57:46 p1121-ipbf1102hodogaya.kanagawa.ocn.ne.jp 550
Jan 10 22:39:21 eatkyo050162.adsl.ppp.infoweb.ne.jp 450
Jan 12 17:08:53 w147078.ppp.asahi-net.or.jp 550
Jan 12 23:16:13 AI-203-132-116-124.kyo.access-internet.ne.jp 550
Jan 12 23:16:26 AI-203-132-116-124.kyo.access-internet.ne.jp 550

　以上、27回。トータルで4477回（偽陽性判定を除く）なので、jpドメインからのものは0.6%。かなり少ないとは言える。しかし、応答コードが「450」、すなわち宛先が正しかったものは9回。jpドメインをすべて許可していたとしたら、これらを受けてしまっていた。国内のIPアドレスを全部許可していたとしたら、国内にあって逆引きできないホストやjp以外のドメインのホストも加わって、受けるスパムはもっと多かったかもしれない。この期間に受けたスパムは16通なので、国内のIPアドレスを許可することによってスパムの受信は1.5倍以上に増えることになる。これでは、OP25Bの普及を当てにして国内のIPアドレスを全部許可するなんてことはとてもできない。
　OP25Bを実施しているISPに名を連ねているOCNからの不正メールアクセスが目立つ。考えられる理由の一つは、OP25Bの対象にならないスタティックIPアドレスのホストがボットにやられているということである。*.static.zoot.jpというホストから不正メールアクセスが来ていることからも、そういうことは考えられる。もう一つ考えられることは、これらのアクセス元はダイヤルアップ回線だということである。ダイヤルアップ接続は、接続時間が短いため比較的スパムの発信源になりにくいことと、モバイルの利用でOP25Bをやられては非常に不便だということから、OP25Bの対象になっていないことが考えられる。実際、私がモバイルに使っているbモバイルは、携帯電話会社向けのポート25を規制しているだけであり、私は自宅のサーバを経由してPOP-before-SMTPでメールを送信することができている。
　なお、私の自宅サイトはOCNを利用しているが、ダイナミックIPアドレスから同じOCNの他顧客のネットワークへのポート25ブロッキングをしていないなんてことはまさかないだろうと思う。
　t01.combzmail.jpは、SMTPに応答するまともなメールサーバである。ここからのアクセスは、かつてわざとスパマーに拾わせたおとりのアドレスに宛てたものだった。combzmail.jpはメール配信ASPサービスである。顧客がスパムをばらまこうとしたか、顧客のPCがボットにやられたのかもしれない。
　もう一つ気付いたことは、OP25Bを実施しているISPに名を連ねていないISPもけっこうあるということだった。
　結局のところ、OP25Bの推進は不正メールアクセスの減少に功を奏してはいるが、スタティックIPアドレスやダイヤルアップ接続のホストもスパムの発信源になっていると思われる状況である。送信側の自主規制策としてのOP25Bがいくら普及しても、S25Rによる受信側の自衛策が不要になる時代は当分来そうにない。

また激賞された

　国島丈生さんのブログ記事「某学会メールサーバのSPAM対策」で激賞をいただいている。
　国島さんが管理するメールサーバでは、spam throttling（DATAコマンドに対する応答を遅らせることによってメールの流量を制限するものらしい）を施してもなお、学会の連絡用メーリングリスト宛に一日数百通のスパムが押し寄せていたとのこと。
　普通に考えると、実装の簡単な素のS25Rを導入してから、ホワイトリスト登録を省力化するために選択的グレイリスティングへのステップアップを考える人が多そうなもの。しかし、国島さんは逆のやり方をされた。正当なメールの受信失敗を避けるためにまず佐藤さんのQgreyを導入。偽陽性判定がほとんど起こらないことを確認した上で、廣島さんのqmail用S25R対応パッチに手直しを加えて素のS25R方式の運用に切り替えられた。
　Qgreyを使っている間、すり抜けがそこそこあったそうである。グレイリスティングがそんなにすり抜けられるものなのかと思って調べてみたところ、Qgreyの母体のqgreylistは、クライアントIPアドレスだけでグレイリスティングを行うらしい。だから、送信者アドレスを変えながら繰り返すスパムアクセスや、同じ送信元から複数の受信者へのスパムアクセスを受け入れてしまうようである。Postfixの場合は、設定項目にsmtpd_delay_rejectパラメータというものがあって、そのデフォルト値は「yes」である。これにより、クライアントにHELO、MAIL FROM、RCPT TOコマンドを送らせてから、次のDATAコマンドを受け入れるかそこで拒絶するかを決めることができる。グレイリスティング用ポリシーサーバのpostgreyは、クライアントIPアドレス、送信者アドレス、受信者アドレスを知って、それらがともに同じであるアクセスのみを正常なリトライと判定することができる。スパムウェアがpostgreyをだますには、まともなMTAと同じリトライをしなければならない。
　そういうわけで、qmailではPostfixに比べて、グレイリスティングを適用したときのスパムの阻止率の低下がやや大きいと考えられる。qmailでは、可能ならば素のS25R方式を用いた方が、スパムに対する防御力の観点では得策であろう。
　で、国島さんが素のS25R方式に切り替えた結果…

結果はというと…まさに驚異的の一語に尽きる。受け取るSPAMは1日10通程度にまで激減した。ログを解析すると、昨晩23:00から今日の12:00までにS25Rで一時拒否したSMTP接続数は2048。実に99%以上のSPAMを、受け取ることなく排除していることになる。この間、誤って拒否したメールは１通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。

　私は論文を「阻止率99%のスパム対策方式の研究報告」と題しているが、99%とは、user unknownになるおとりのアドレスやでたらめのアドレスに宛てられたものも含めた不正メールアクセス全体についての統計である。宛先の正しいスパムの阻止率は99%に至ることは少なく、月によって97～99%といったところである。しかし、メールアドレスをウェブで公開していて、今までスパムを受け放題だった人の場合は、高い阻止率を記録しやすいかもしれない。
　そして最後に…

こんなすごい方法を編み出した浅見秀雄さんに大感謝である。

喜んでいただけて幸いです。ご利用ありがとうございます。

　ところで、国島さんは直後の記事で、逆引き名を「localhost」と不正に設定したホストからのスパムがすり抜けたことを書いておられる。qmailはパラノイド検査（逆引き名の順引き検証）をしないからだろう。Postfixはパラノイド検査をするので、このような嘘にだまされるおそれはない。「localhost」の順引き結果が元のクライアントIPアドレスに一致することは絶対にないので、検証後の逆引き結果は逆引き名がないときと同じく「unknown」となり、応答コード「450」で蹴ることができる。

選択的グレイリスティングの代名詞？

　JOMONインターネットが「S25R方式によるスパム対策を2007年10月27日から運用開始した」と告知している。もちろん、ISPで素のS25R方式を運用するのは無理がある。よく読むと、やっていることはRgreyと同じ選択的グレイリスティングである。しかし、RgreyではなくS25R方式の名を掲げている。S25R方式で誤判定からの救済のためにやることはグレイリスティングで自動化できると最初に気付いてRgreyを作られたのは佐藤さんだが、JOMONインターネットの人もS25R方式を調査した際にすぐに同じ発想を得たから、ベース技術であるS25R方式の名を掲げているのかもしれない。
　グレイリスティングという技術は、私がS25R方式を考案するよりも前からあった。しかし、当たり前のものとして広まってはいない。少なくとも国内では、採用するサイトの数において素のS25R方式が追い抜いているはずである。純粋なグレイリスティングは、初めてメールを送ってくるホストに無差別に応答コード「4xx」を返して受信を遅延させる。だから、知っていても採用に二の足を踏む人は少なくなかったのかもしれない。それがS25R方式との組み合わせで、逆引きできないか逆引き名がエンドユーザーコンピュータっぽいホストにのみグレイリスティングを適用する選択的グレイリスティングのアイデアになった時、「これなら使える」と思われたのだろう。つまり、後から現れたS25R方式がグレイリスティング技術に光を当てた。
　JOMONインターネットが、S25R方式をベースとした選択的グレイリスティングも「S25R方式」と呼んでいるのは、それはそれでうれしいことではある。ソニーの商標「ウォークマン」がヘッドホンステレオの、また、ヤマハの商標「エレクトーン」が電子オルガンの代名詞になっているようなもの。それだけ「S25R」の名前が有名になったということだろう。
　ところで、冒頭のJOMONインターネットのページでは、S25R方式の原典として私のサイトを紹介してくれてはいない。しかし、そのことに不平を言うつもりはない。JOMONインターネットの人は、原典を紹介しておこうとは思い至らないくらい、S25R方式の存在を常識だと思っているのかもしれないから。

多数派の圧力

　素のS25R方式を使っている受信側サイトにとって、リトライを短時間でやめる送信サーバやリトライしない送信サーバは困った存在である（前回の記事）。このような送信サーバがある以上、受信失敗の際のリカバリーを考えておくという危機管理で対処せざるを得ない。
　このような受信失敗をなるべくしないためには、S25R方式の導入者が相互協力することが望ましい。ホワイトリスト情報を私に知らせていただき、私が公表する公開ホワイトリストを共有するのである。ただ、ホワイトリスト情報を寄せてくださるのはあくまでもボランティアの行動であり、S25R方式の導入者みんながそうしてくださるわけではないので、限界がある。
　もっとも、S25R方式で受信に失敗するような送信サーバは今後減っていくことが期待できる。S25R方式が広まれば、多くの人がS25R方式を知るようになる。送信サーバを立てる人は、S25R方式を採用するサイトにもちゃんと受信してもらうことを考慮せざるを得なくなる。すなわち、S25Rの拒否条件に引っかからない逆引き名を付けるか、受信側サイトのメールシステム管理者が気付いてホワイトリスト登録してくれるまでリトライすることである（逆引きを設定しても、受信側でDNS検索に一時的に失敗することがあるので、どのみちリトライは必要であるが）。さもないと、受信に失敗したサイトから問い合わせや再送依頼を頻繁に受けることになりかねない。
　私は、S25R方式を提案するにあたって、S25R方式によるスパム対策の都合のために送信側で逆引きを設定してほしいとは言っていない。送信側はまともなMTAを使っていてくれさえすればよいという前提で、正当なメールを誤判定から救済する努力は受信側だけで行うことをS25R方式のコンセプトとしている。実際のところ、受信側の努力で正当なメールを救済できないケースもまれにある。しかし、S25R方式を採用するサイトが多数派になれば、それは送信サーバにも送達のための相応の努力を求める無言の圧力になるだろう。

送達の努力をしない送信サーバには…

　DNSBLの情報を信用して正当なメールサーバを応答コード「5xx」で蹴るサイトがある。内容チェックの誤判定で正当なメールを「5xx」で蹴るサイトもある。偽陽性のおそれがある判定でメールを（保留させるのでも印を付けて届けるのでもなく）バウンスさせることには反対である。私は、S25R方式を導入される方々に対して、正当なメールを受け入れるために最善の努力をするよう訴えている。つまり、絶対に不正メールだと確信できる場合（HELOアドレスが違法である、ポルノサイトであるなど）以外の受信拒否時には必ず「450」で再送要求し、ログを監視して、リトライアクセスを発見したらホワイトリスト登録する。
　ただ、受信側のこの努力によって正当なメールを受け入れるのは、応答コード「450」による拒否に対して送信側がある程度の期間リトライを続けてくれること、すなわち、送信サーバもメールの送達のためにある程度努力してくれることを前提としている。Postfixやsendmailのデフォルト設定で5日間リトライしてくれれば、週末や3連休を挟んでも救済できる。しかし、リトライ期間が2日以下だと、週末にスタッフが休む組織サイトではメールを受け損なうおそれがある。1時間くらいしかリトライしてくれないと（私が発見しているのは、メールマガジン、携帯電話会社からのエラーリターンのケース）、手動で救済することは非常に困難である。1時間くらいでリトライをやめるのは、受信側が何らかのトラブルに陥った時に1時間以内に復旧するのは期待しにくいということを考慮していない、つまり、メールを送達させる努力をする意思がないと考えざるを得ない。
　Rgreyを使えば、リトライ期間が短くても受信できる。しかし、Rgreyの導入に二の足を踏む人は少なくないだろう。S25R方式が多くの人たちに受け入れられた最も大きな理由は、スパムの阻止率もさることながら、Postfixの設定だけで実現できるという簡便さに違いない。メールシステム管理者の中には、Postfixのオペレーションがどうにかできるくらいのスキルレベルの人はおそらく少なくない。スキルの高い人は、ホワイトリスト登録という手間のかかる作業はなんとか自動化したいと考えるだろう。しかし、スキルの高くない人にとっては、単純作業の継続はさして苦にならず、むしろ、新たな付加ソフトウェアを導入するための勉強に頭脳と時間を費やすことはかなりの負担なのである。
　ところで、大規模サイトでRgreyを使っている人から聞いた話によると、Rgreyでも救えないメールがあるらしい。ウェブへの入力に応答してメールを送信するシステムなどで、リトライしないものがあるとのこと。このような送信サーバは、タールピッティングに耐えさえすればStarpitで救済できる。ところが、佐藤さんによれば、タールピッティングに耐えないメールサーバもあるらしい。そこで、タールピッティングに耐えるかリトライするかいずれかを満たせば救済できるようにしようと佐藤さんが開発されたのがtaRgreyである。しかし、これも付加ソフトウェアを要するから、スキルの高くない人にとっては、導入にはかなりの負担になる。
　正当なメールを受け入れるための最善の努力といっても限界がある。送達のための努力をしてくれないメールサーバを救済する努力は困難である。Postfixのオペレーションがどうにかできるくらいの人にとっては、RgreyやtaRgreyの導入は“最善”を超えた努力である。
　では、スキルの高くないメールシステム管理者がこの問題に対処するにはどうすればよいか。受信失敗がありうることを認識し、そのリカバリーのために最善を尽くすことである。その要点を次に示す。

●ある程度の期間（毎日ログを監視する場合は1日以上、スタッフが最大3日監視を休むとすれば4日以上）リトライしないメールを受信できないことがありうるということをユーザーに断っておく。

●拒絶ログソーティングスクリプトでログを監視し、おおむね30分以上リトライしていて救済が間に合わなかったと思われるアクセスが見つかったらユーザーに知らせてあげる。

●ユーザーが、来るはずのメールが来ないと思った時には、申し出てもらって、ログを調べてあげる。

●受信失敗とわかった時には、ホワイトリスト登録した上で、人からのメールだったならば送信者に再送を依頼するよう、また、オンラインショッピングの確認メールなどの場合は送信サイトに問い合わせるようユーザーに助言する。ユーザーが問い合わせ方法がわからない場合は、方法を調べてあげる。

　ここまでやれば、たとえ受信失敗が起こっても、ユーザーのために最善の努力をしていると言える。
　メールサービスでユーザーからお金をもらっているわけではない、企業や学校などの組織のメールシステム管理者は、ともすると「メールサービスを提供してやっている」、「スパムの被害から守ってやっている」という恩着せがましい意識に陥りがちであるが、ゆめゆめそんなことは思わないように。「ユーザーはお客様」という意識で最善を尽くしていただきたい。

ITproで紹介された

　日経BP社・ITproの連載「こちらセキュリティ相談室」の「第10回 迷惑メール対策（後編）」で、「即効対策はS25R」と紹介されている。著名なマスコミサイトで取り上げられたことで、ますます多くの人に知られて普及することになるだろう。
　図では、迷惑メールを送信するパソコンからの接続を拒否する際の返答が吹き出しで「出直してきなさい」と記されている。ここが重要なポイントであり、誤判定からの救済まで考えた方式であることがわかるように表してくれたのはうれしい。
　ただ、2ページ目の

S25Rを使うと，正しいメール・サーバーからの接続を拒否してしまう可能性がある。そこで誤認に備え，怪しい送信元には再送要求を出し，ちゃんと再送してきたら受け取るのがグレイリスティングという方法だ。

という記述は、

S25Rを使うと，正しいメール・サーバーからの接続を拒否してしまう可能性がある。そこで誤認に備え，怪しい送信元には再送要求を出し，ちゃんと再送してきたらホワイトリストに登録して受信する。これは，グレイリスティングという方法を併用することによって自動化することができる。

と書いてくれた方が、より正確である。
　サーバで阻止できなかったスパムをPC上のメーラーまたは付加ソフトウェアでフィルタリングする方法も述べられている。これはこれで有用な情報ではあるが、私としては、そこまでする必要があるだろうかと思う。素のS25R方式で97～99%、Rgreyで95%（佐藤さんの発表による）の阻止率があるのだから、一日100通のスパムを受けていた人の場合もすり抜けは平均5通以下。手動で捨てても大した手間ではないだろう。少しとはいえスパムを受けたらムカッとする気持ちはわかるが、PC上のスパムフィルタにも必ず偽陽性判定のリスクが伴うことを勘案した方がよい。スパムの受信が多ければ、偽陽性判定もそれなりに起こるので、ごみ箱に振り分けられたメールを確認することは習慣化するだろう。しかし、スパムの受信が減れば、偽陽性判定がめったに起こらなくなるので、ごみ箱を確認するのを忘れ、偽陽性判定が起こった時に気付くのがかえって遅れるかもしれない。
　最後に

今回のポイント ●迷惑メールの送信方法は進化しています。同じ対策がいつまでも通用するものではありません。 ●メール・サーバーで迷惑メールの受信を拒否するには，相手のIPアドレスからドメイン名を確認するS25Rという対策が今のところ有効です。

と記されている。S25R方式とていつまでも通用するものではないかもしれないというのは認める。2006年10月8日「S25Rが敗北する時は来るか？」で、「（受けてから送信元の逆引き名を検査する方法もあるから）S25R方式は半永久的にスパムに敗北しないと考える」と述べたが、もしたくさんのボットが正当なメールサーバと同じように長時間リトライし、またタールピッティング（応答遅延）にも耐えるようになれば、S25Rでスパムを受けずにはじくための運用は困難を極めるのは確かである。
　とはいえ、それは言い換えれば、S25R方式がより大きな攻撃コストをスパマーに強いるということである。そんなコスト高な攻撃をスパマーがこぞって始めるとしたら、それは、S25R方式がもっと普及してスパムの送達率が大幅に下がった時だろう。そのころにはきっとOP25B（Outbound Port 25 Blocking）や送信ドメイン認証が進展している。それらは、スパムの受信を減らす即効策にはならないが、スパム包囲網として徐々に世界に普及するだろう。そうなるまでの期間、S25R方式は、強力な即効策として役立ち続けると思う。

サブジェクトにスパム判定の痕跡

　私が運用しているメーリングリストで配信したメールに対する返信で、サブジェクトが

Subject: RE: [SPAM] …（元のサブジェクト）

となっているものがあった。配信されたメールが誤ってスパム判定されたらしい。11月24日「失礼な受信拒否」で述べたケースと同じく、メールの内容は会合案内であり、スパム判定された理由がわからないものである。サーバでスパム判定されたか、スパム判定機能付きのメーラーあるいは付加ソフトウェアを使っていたのだろう。
　スパム判定されたメールのサブジェクトに「[SPAM]」などの印を埋め込んで受信者に届けるのは、応答コード「550」で受信拒否するよりもましである。しかし、偽陽性判定の痕跡をサブジェクトに残したまま返信するのは、元のメールの送信者に失礼であろう。トレンドマイクロのウイルスバスターの迷惑メール対策機能も、サブジェクトの先頭に「[MEIWAKU]」という文字を埋め込むようになっている。偽陽性判定された正当なメールに返信する時は、これらの印を削除して送信するように注意すべきである。
　とはいえ、返信の時にはサブジェクトには注意が行き届かないことが多い。偽陽性判定されたメールに返信する際にサブジェクトの修正を忘れても失礼に思われないためには、スパム判定の印にそれとわからない文字を使ったらどうだろうか。たとえば、ドット＋スペースはサブジェクトの先頭に書かれることはまずないと思われるので、それをスパム判定の印にする。うっかりサブジェクトを直さずに返信しても、

Subject: Re: . 会合のご案内

のようになり、返信を受けた人は「あれ？変だな」とは思うかもしれないが、自分が出した元メールが迷惑メール扱いされたとはあからさまにはわからないからよいだろう。

偽陽性判定の見つけ方の説明を修正

　拒絶ログソーティングスクリプトのページの「活用法」の節で、「連続して表示されたアクセスが次のすべての条件を満たすならば、クライアントはおそらく、ホワイトリストに登録すべき正当なメールサーバです」と説明しているが、その条件の説明を修正した。

●再試行間隔が1分以上、4時間以下である。（ただし、一人の送信者が一人の受信者に複数のメッセージを送信したならば、見かけ上の再試行間隔が短くなることがあります。）
●送信者アドレスのドメイン名が実在する。
●受信者アドレスが正しい。

これに

●再試行が30分以上続いている。

という条件を加えた。今までの経験から、スパムアクセスが25分以上リトライすることはまれであることがわかっており、また、正当なメールアクセスが30分未満で止まったのを見つけたことはないからである。
　一方、

●HELOアドレスがFQDNであり、それの順引きがクライアントIPアドレスに一致する。（ただし、正当だけれどもHELOアドレスの設定が不備なメールサーバがあるかもしれません。）
●クライアントにSMTPアクセスすると、PostfixやsendmailなどのMTA（Mail Transfer Agent）が応答する。（ただし、この条件を満たさない正当なメール送信サーバがあります。）

という記述は削除した。私自身、ホワイトリスト登録の際にHELOアドレスの順引き検査とSMTPアクセスの試験はしていないからである。HELOアドレスは、受信側のドメインまたはIPアドレスを名乗るという違法なものでない限り、不備なものだからといって送信元が不正だとは断定できない。また、送信元がSMTPアクセスに応答しないからといって、送信専用サーバからと思われるアクセスを受け入れないわけにはいかない。
　リトライが1分以上の間隔で30分以上続いていたら、送信元はボットでなくメールサーバだと思ってほぼ間違いない。もっとも、受信するメールがメールサーバを経由したスパムであることはあるけれども。

失礼な受信拒否

　私が運用しているメーリングリストの配信メールがスパム判定されて受信拒否された。受信者アドレスのユーザー名とメーリングリスト名は伏せるが、ドメイン名は暴露する。インドの会社である。

<***@edkal.com> (expanded from <***-outgoing>): host     mail.edkal.com[202.71.131.52] said: 550 Rejected. Classified as     ****SPAM**** (in reply to end of DATA command)

　「550」による拒否にムカッときた。配信しようとしたメールは、日本語で書かれた会合案内で、スパム判定される理由がまったくわからないものである。おそらく、ベイジアンフィルタのたぐいか、あるいはさらにそれに何らかの条件を組み合わせた複雑な計算をしていて、“スパムらしさ”の点数が誤って閾値を超えたのだろう。
　スパム判定された理由がわからないから、どこをどう直せば受信してもらえるのかわからない。こんな失礼な受信拒否をすれば、顧客を怒らせる危険もあるだろう。まだしも、「IPアドレスで書かれたURLは（不正メールに多いため）受け付けられません」などのような明確な理由を示した受信拒否の方がましである。

GAWK 3.1.4でスクリプトの表示がおかしくなる

　BBSで、拒絶ログソーティングスクリプトの表示がおかしくなるという申告をいただいた。GAWKのバージョンは3.1.4で、クライアントのFQDNとIPアドレスが表示されないことがあるとのこと。
　私は今までGAWK 3.1.0を使っていて、何も問題なかった。3.1.4をインストールしてみたら、確かに所々でFQDNとIPアドレスが表示されなくなる。どういう場合にそうなるかの規則性はつかめなかった。問題を起こしているのは

client=substr($0, match($0, /from [^]]+\]/)+5, RLENGTH-5)

という式の中のmatch関数らしい。その人は

client=substr($0, match($0, /from .+\]: /)+5, RLENGTH-7)

と書き直して回避したとのこと。
　しかし、3.1.5にバージョンアップしたら問題は起こらなかった。3.1.4特有のバグと思われる。こんな簡単な正規表現で発現するバグとはお粗末ではないかと思うが。
　なお、最新版は3.1.6だが、私の環境ではなぜかmakeでエラーになってインストールできなかった。

l.root-servers.netのIPアドレスが変わった

　11月1日からl.root-servers.netのIPアドレスが198.32.64.12から199.7.83.42に変わったそうです。旧のIPアドレスも6ヶ月は有効ですが、その後退役します。ルートキャッシュファイルを入れ替えてください。

http://blog.icann.org/?p=227

# スパム対策の話じゃないけど、情報のサービス。

ホワイトリストの正規表現の原則

　今日（10月30日）、ホワイトリスト情報をいただいて公開ホワイトリストファイルに掲載したついでに、過去の許可条件をいくつか修正した。
　これまで、許可条件の正規表現は、サイトドメインを丸ごと許可したり、サブドメインまで条件に含めたり、末端ホスト名の先頭の綴りを条件に含めたりと、作り方が一定していなかった。今後は、「エンドユーザーPCをインターネットに直結させているISPでないと認められるサイトについては、サイトドメインを丸ごと信用する」という原則で正規表現を作ることにした。
　たとえば、S25Rに引っかかるホストとしてmp-mta01011.bellemaison.jp、およびその数字部分が変わるものが報告されたことがある。この場合、

/^mp-mta[0-9]+\.bellemaison\.jp$/ OK

で許可されるが、末端ホスト名の構文の条件をはずして

/\.bellemaison\.jp$/ OK

としても危険はない。www.bellemaison.jpにアクセスすれば、bellemaison.jpが通販会社のドメインであることがわかる。まともな会社からスパムやウィルスメールが発信されることは、サーバが侵害された時か、サイト内のウィルス感染したPCから通常のメールルートでウィルスメールが出た時（本来、S25R方式では阻止できないケース）以外あり得ない。こういうサイトは丸ごと信用する方が、末端ホスト名の文字が異なる別のメールサーバがあった場合にまた引っかかるということを避けることができて好都合である。
　この原則で見直した過去の許可条件は、コメント行に「(revised)」と記している。
　一方、ISPが逆引き名を決めている接続サービス（通常、IPアドレス1個単位の販売）を使ったメールサーバの許可条件は、たとえば

# Jun 19, 2007: mail.ifscorp.co.jp
/^210-175-254-67\.cust\.bit-drive\.ne\.jp$/ OK

のように、当然ながら従来どおりホスト1個単位で許可するようにしている。

Becky!でタイプBのフィルタリングができない問題

　「Becky!でスパムメールを自動的に90%以上捨てる方法」で説明している、タイプBのReceivedヘッダ（qmailのフォーマット）のフィルタリングができないという申告をBBSで受けた。フィルタリングができないスパムのメールヘッダのコピーを送っていただいた。Receivedヘッダ（受信メールサーバの名前を仮にmail.example.jpとする）は

Received: from unknown (HELO SPK07.localdomain) (122.43.126.192)
 by mail.example.jp
 with SMTP;
 25 Oct 2007 16:02:34 +0900

振り分け条件（正規表現）は

from (unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-|_)+|\.)[0-9]).* by mail\.example\.jp

である。
　手動のSMTPで、上記のReceivedヘッダを含む自分宛のメールを作り、Becky!で受信して試験した。確かに最新版の2.41.00でフィルタリングできない。振り分け条件を変えながら試験したところ、正規表現処理のバグらしいとわかった。
　2.30.03にバージョンダウンすると問題が起こらないことがわかった。Readmeファイルによると、2.30.04へのバージョンアップで正規表現処理のバグを修正したとのことなので、その時にデグレード（別のバグの混入）が生じたのだろう。作者さんに報告した。
　問題が起こるのはタイプBの場合だけのようである。私は勤務先（MTAはsendmail）でタイプAのフィルタリングをしているが、問題は起こっていない。
　タイプBのフィルタリングをしたい人は、対処されるまで2.30.03にバージョンダウンするしかないだろう。
http://www.rimarts.jp/downloads/B2/bk23003j.exe
を実行すれば2.30.03をインストールできる。
　2.30.03の後にいろいろなバグ修正が行われているが、発現頻度の低いバグだと思う。重大なセキュリティ問題への対処は報告されていないので、特に支障がなければ、次のバージョンアップまで2.30.03を使っていても問題ないだろう。

（10月30日追記）
　作者さんがさっそく対処してくださった。テストバージョンの提供を受けて試験したところ、問題は解決されていた。近いうちにバージョンアップが出るだろう。

（11月1日追記）
　Becky! 2.42.00が出た。問題が解決されていることを確認できた。
http://www.rimarts.jp/downloads/B2/bk24200j.exe

7日間見逃しなしの新記録

　勤務先でのBecky!によるフィルタリングで、10月15日23時49分に着信したスパムが見逃された後、次の見逃しは10月23日2時52分着信のものだった。その間、まるまる7日間、341通のスパムが連続してスパム用フォルダに振り分けられた。偽陽性判定はなかった。
　自宅サイトでは、押し寄せるスパムが勤務先に比べて少ないので（2006年9月28日「拒絶の効果？」）、1週間以上スパムの受信がないことはざらにあるが、勤務先では見逃しなしの最長記録である。
　もっとも、これはたまたまであり、長期間平均の判別率が99%を超えているわけではない。10月に入ってから23日までに受信したスパムは1200通余り、判別率は98.5%である。
　とはいえ、判別率がこれだけ高ければ、ほかに何もいらない。メールシステム担当がサーバでスパム対策をしてくれなくてもちっとも困らない。まして、スパムの排除率100%と称するサービスに金を払うなどまったくばかばかしくなる。

Adobe ReaderおよびAcrobatのパッチ

　Adobe ReaderおよびAcrobatの脆弱性に対応するパッチが出た。対処されたバージョンは8.1.1である。
　Adobe Reader日本語版の8.1.1は、10月23日現在、まだダウンロードできないようである。8.1よりも古いバージョンを使っていた人は、まず8.1をインストールする。それから、8.1.1 update（ファイル名：ReaderUpd811_all_incr.msp）をダウンロードして実行してください。
　Adobe Acrobat 8.0および8.1対応のパッチはここからダウンロードできる。