水曜日, 1月 30, 2008

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]

日曜日, 1月 27, 2008

スパム送信サーバが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」に由来する。国名を四つの公用語で併記する代わりに単独で表記する国名として、どの言語話者にも不公平にならないようにラテン語を使っているのである。

月曜日, 1月 21, 2008

日本の美徳

 前回、善良な送信者に迷惑をかけまいという気配りの心が私にあったから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方式を日本発のアイデアとして誇る。そして、開発者の私を育んだ日本の文化を誇る。

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

日曜日, 1月 20, 2008

僕って天才?

 日経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方式は多くの人に受け入れられる実用的なものになった。それも私は誇ってよいことだと思う。
 そしてあと一つ、私が誇れるのは、スパムに困っている人々とのコミュニケーションを大切にしていること。質問には必ず答え、問題の解決のために支援する。また、善意の協力者から寄せられるホワイトリスト情報を感謝して受け取り、それをほかの人たちのために公開する。こうした活動を地道に続けている。このことにかけては私は無精者ではないのである。
 “天才的なひらめき”も、それだけで世の中に役立つものになるというものではない。「他人が使えるか」、「他人が困らないか」という、他人を思いやる思考も必要なのである。

土曜日, 1月 19, 2008

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

 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ヶ月、観測されていない。

火曜日, 1月 15, 2008

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による受信側の自衛策が不要になる時代は当分来そうにない。

水曜日, 1月 09, 2008

また激賞された

 国島丈生さんのブログ記事「某学会メールサーバの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を、受け取ることなく排除していることになる。この間、誤って拒否したメールは1通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。

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

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

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

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

日曜日, 1月 06, 2008

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

 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方式を採用するサイトが多数派になれば、それは送信サーバにも送達のための相応の努力を求める無言の圧力になるだろう。

金曜日, 1月 04, 2008

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

 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分以上リトライしていて救済が間に合わなかったと思われるアクセスが見つかったらユーザーに知らせてあげる。

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

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

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