土曜日, 5月 30, 2009

SPAMCOPの併用の効果

 4月29日にSPAMCOPの併用を開始した。4月26日から5月30日22時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は偽陽性判定を除いて1582、この期間に着信したスパムは8通。したがって阻止率は99.5%となった。
 S25Rをすり抜けてSPAMCOPでブロックされたスパムは5通あった。これらが着信していたとすると、阻止率は99.2%である。これもけっこう高い値だが、SPAMCOPの併用でさらに0.3%上がったことになる。SPAMCOPによる偽陽性判定は起こっていない。
 S25Rでブロックされたホストの中には、論文に示していない追加の一般規則とブラックリストで引っかかったものがあった。そのうち以下に○で示したものはSPAMCOPに登録されていた。

router.shtorm.com [195.62.14.1]
pursuant.age.volia.net [77.122.227.132]
smatteringness-warmth.volia.net [77.123.102.225]
devoted-parlayer.volia.net [93.74.8.151]

つまり、追加の一般規則とブラックリストがなかったとしても、4通のうち3通はSPAMCOPでブロックできたということである。
 SPAMCOPの併用はかなり役に立つ。一方、今までにスパムアクセスをしてきたホストをRBL.JPBlack list DB checkで調べたところでは、RBL.JPに登録されていたことは数えるほどしかなく、spamhausに登録されていたのを見たことは一度もない。

金曜日, 5月 15, 2009

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

 次のようなリトライアクセスがあった。

May 13 17:44:51 unknown [81.91.67.81] from=<ohflpiciqvMeredith@***.com> to=<deo@gabacho-net.jp> helo=<81.91.67.81>
May 13 17:52:05 〃
May 13 18:12:46 〃
May 13 18:46:47 〃
May 13 19:34:07 〃
May 13 20:34:48 〃
May 13 21:48:49 〃
May 13 23:16:29 〃
May 14 00:56:51 〃
May 14 02:50:52 〃
May 14 04:58:12 〃
May 14 07:18:54 〃

 送信者アドレスのユーザーIDがでたらめっぽいのがいかにも怪しい。HELOアドレスがIPアドレスなのに「[ ]」で囲んでいないのがいかにも怪しい。私がウェブで公開しているアドレスは「webmaster」なので、私の知らない人から初めて来るメールは通常「webmaster」に宛てられるのに、「deo」宛なのも怪しい。
 スパムに違いないとにらんで放置プレイを食らわせてみたら、リトライアクセスは13時間34分で止まった。
 送信元にSMTPアクセスしてみたら、MTAが応答した。ボットでなくメールサーバだった。まともなメールサーバならば24時間やそこらであきらめたりはしないのが普通だが(Postfixやsendmailのデフォルト設定で5日間)、14時間未満でリトライが止まったのは、スパム送信用にチューンしたサーバだからだろう。
 人間の知識と経験に基づいて「怪しい」とにらむ判断は、今のところ、機械に任せるのがむずかしい。この職人芸で、長時間リトライするスパムアクセスを放置する。正当なメールサーバがリトライを1時間ほどでやめてしまうというレアケース(私が見つけているのは、メールマガジン携帯電話会社からのエラーリターンのケース)を除けば、怪しいとにらんだリトライアクセスが24時間未満で止まったらスパムだったと判断してほぼ間違いない。S25R方式を素のまま使っていると、こういうサディスティックなプレイができて面白い。

*.cust.bit-drive.ne.jpの丸ごと許可を取り消し

 前回、*.cust.bit-drive.ne.jpを丸ごと許可するようにしたことを報告したが、個別許可に戻した。掲示板のゲストのKenjiさんから、*.cust.bit-drive.ne.jpがスパム送信サーバに使われているとの報告をいただいたからである。
 以下は、Kenjiさんの記事の引用。Kenjiさんのサイトで複数のユーザーからスパムの申告があった送信元ホストだけでこれだけあるとのことである。

202.94.129.36 から yahoo.co.jp を騙ったspam
202.94.129.226 から yahoo.co.jp を騙ったspam
202.94.147.83 から 出会い系(オプトインかどうかは不明)
202.94.153.85 から yahoo.co.jp を騙ったspam
202.94.153.86 から yahoo.co.jp を騙ったspam
202.94.153.87 から yahoo.co.jp を騙ったspam
202.94.153.197 から yahoo.co.jp を騙ったspam
210.172.21.90 から yahoo.co.jp を騙ったspam
210.172.31.190 から yahoo.co.jp を騙ったspam
210.172.31.191 から yahoo.co.jp を騙ったspam
211.9.45.148 から yahoo.co.jp を騙ったspam
211.9.50.239 から 出会い系(オプトインかどうかは不明)
219.106.230.243 から 出会い系のspam
219.106.230.245 から 出会い系(オプトインかどうかは不明)
219.106.230.253 から 出会い系(オプトインかどうかは不明)
61.45.193.225 から yahoo.co.jp を騙ったspam

月曜日, 5月 11, 2009

*.cust.bit-drive.ne.jpを丸ごと許可

 今まで、210-172-21-218.cust.bit-drive.ne.jp (wserver.alliance.co.jp)をはじめ、cust.bit-drive.ne.jp配下のホストを、発見されるたびに一つ一つ公開ホワイトリストに登録していたが、掲示板のゲストのPyTaさんのご提案により、*.cust.bit-drive.ne.jpを丸ごと信用する許可条件に集約した。bit-driveは法人向けのインターネット接続サービスで、ボット化するエンドユーザーコンピュータはつながっていないだろうと思われ、実際、*.cust.bit-drive.ne.jpから不正メールアクセスが来たことはないからである。
 過去に掲載していた*.cust.bit-drive.ne.jpの許可条件は、しばらくコメントアウトで示しておくことにする。

# *** PUBLISHED S25R WHITE LIST ***
# Last update: May 11, 2009
# (*): reported by a contributor
#
# May 11, 2009: mail.ebookoff.co.jp (202-94-136-109.cust.bit-drive.ne.jp) (*)
/\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 15, 2009: (revised)
# Feb 03, 2008: mag.jobengine.jp (*)
#/^219-106-251-106\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Apr 15, 2008: legacy.transcend.co.jp (*)
#/^219-118-179-4\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 26, 2008: mail.dss-net.co.jp (*)
#/^218-42-147-99\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Mar 14, 2008: ns.ict-ics.com
#/^210-175-254-69\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Feb 03, 2008: mail.furuhonn.com (*)
#/^219-118-164-66\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Jan 14, 2008: ns.betterhome.co.jp (*)
#/^219-106-250-226\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Dec 14, 2007: nbn.co.jp's (*)
#/^210-251-250-78\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Dec 14, 2007: greeting-card.jp (*)
#/^210-251-251-204\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Nov 29: 2007: ig3.jp's (*)
#/^218-42-159-113\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Jun 19, 2007: mail.ifscorp.co.jp
#/^210-175-254-67\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Feb 08, 2007: tachikawa-roukikyo.or.jp (*)
#/^219-118-191-144\.cust\.bit-drive\.ne\.jp$/ OK
#
# May 11, 2009: (aggregated)
# Nov 24, 2004: wserver.alliance.co.jp (*)
#/^210-172-21-218\.cust\.bit-drive\.ne\.jp$/ OK

水曜日, 5月 06, 2009

君子は豹変するのだ

 2006年11月24日「DNSBLの利用価値はあるか?」で「DNSBLを使う積極的な理由は見出せない」と述べてから2年5ヶ月たってそろそろ舌の根が乾いた今、SPAMCOPの併用実験を開始した。S25Rをすり抜けるスパムをDNSBLでブロックできる率について、ある程度定量的なデータが得られたからである。
 「DNSBLの利用価値はあるか?」の記事では、「S25Rの偽陽性を減らすためにDNSBLを併用すると、阻止率はかなり下がってしまうのではないか」と述べた。これは正しかった。ウェブで見つけた証言によると、SPAMCOPによる阻止率は50~60%程度。DNSBLの応用であるトレンドマイクロのEmailレピュテーション70%程度。阻止率はその程度に下がってしまい、S25R方式の高い防御力が無駄になってしまう。
 一方、「阻止率を上げるためにS25RにDNSBLを併用しても、阻止率が大きく向上することはないだろう」と述べた。確かに大きく向上するとは言えないが、98.8%の阻止率はSPAMCOPの併用で99.2%程度に上がるという見積もりが得られた。「むしろ偽陽性が増えるおそれがある」とも述べたが、それはあまり心配しなくてよさそうである。蹴る時の応答コードを「450」に設定して再送要求すれば、偽陽性からの救済はS25R方式の運用と同じ手順でできる。4月29日にSPAMCOPの併用を設定してから5月6日までに、S25Rをすり抜けたホスト4個のうち、SPAMCOPで阻止されたホストは3個。その中にリトライしたものはなく、偽陽性判定はまだ起こっていない。SPAMCOPはそこそこ役に立っていると言える。
 私の場合、S25Rをすり抜けて着信するスパムは一日平均1通もなく、スパムを捨てる手間はまったく問題になっていない。だから、スパムの受信を減らすためにこれ以上がんばる必要はない。ただ、S25R方式で99%近いスパムを阻止できてもなおスパムの受信が多い人にノウハウが役立つかもしれないと思って、SPAMCOPの併用実験をやっている。
 正当なメールをエラーリターンさせる副作用ゆえに「DNSBLを使ってはいけない」という主張もあるが、物は使いようである。多少とも効果があり、副作用を克服できるなら、使えばよいと思う。副作用を克服するには、S25Rと同じくDNSBLによるブロックでも再送要求を返し、ログを監視して、リトライするメールサーバをホワイトリストで救済すればよい。それが、S25R方式と同じく、スキルの高くない人でも容易に実装・運用できる方法である。知識だけであれこれ言うのでなく、知恵を働かせればよい。
 抗がん剤にはがん細胞だけでなく正常細胞も殺す副作用があるが、だからといって抗がん剤を使ってはいけないなどとは言っていられない。知恵を働かせて副作用を克服できるならば、治療に有効な抗がん剤は使うべきである。それと同じことである。

日曜日, 5月 03, 2009

SPAMCOPが効いた

 4月29日にSPAMCOPを設定してみた。その後、5月3日までに、S25Rをすり抜けるスパムアクセスが3通あった。www.era.gov.etからの1通(4月30日)は着信したが、adsl.eb1-pacovchamarao.edu.ptから(4月30日)、syscom4.att.net.coから(5月1日)の2通がSPAMCOPでブロックされた。いずれも、応答コード「450」に対してリトライしなかった。
 ほかに、81-208-74-142.ip.fastwebnet.itからのアクセス(5月3日)がS25Rに引っかかって8時間以上リトライしていて、多分スパムだろうと思って受信してみたら、やっぱりスパムだった。これはSPAMCOPに引っかからなかった。
 4通のうち2通をSPAMCOPでブロックでき、リトライがなかったので、今のところ、SPAMCOPを設定してよかったと言える状況である。

水曜日, 4月 29, 2009

SPAMCOPを設定してみた

 前回、S25Rをすり抜けてスパムを着信させたホスト20個のうち7個(35%)がSPAMCOPのDNSBLに登録されていたことを述べた。このことから、すり抜けスパムを減らすためにSPAMCOPがどのくらい役立つかを調べてみたいと思った。
 3月29日から4月29日18時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1274、この期間に着信したスパムは16通なので、ここから計算した阻止率は98.8%である。1.2%のすり抜けが、SPAMCOPによってその65%、すなわち1.2%×0.65≒0.8%に減れば、阻止率は99.2%に上がり、16通のすり抜けは10通程度に減る計算になる。
 話はそううまくはいかないかもしれない。DNSBLによる偽陽性判定でメールをエラーリターンさせるわけにはいかないから、拒否応答コードを「450」に設定して再送要求する必要がある。S25Rをすり抜けてDNSBLに引っかかる送信元ホストはメールサーバである確率が比較的高いので、「450」に対してリトライしてくる可能性が高い。リトライしなかったアクセスはスパムだったと断定してよいが、メールサーバの挙動でリトライしてきたら、スパムかどうかは受けてみないと確認できない。もしS25Rをすり抜けてDNSBLに引っかかるホストの多くがリトライしてくるとしたら、受信して確認するためにホワイトリスト登録する手間が増える。一方、DNSBLが引っかけてくれるホストの多くがリトライしないボットであれば、阻止率をあと少し上げるのにDNSBLが役立つと考えられる。
 ともかく、やってみることにした。

 main.cfファイルに以下の太字の行を追加する。

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  check_helo_access regexp:/etc/postfix/helo_restrictions,
  reject_unauth_destination,
  reject_unlisted_recipient,
  check_client_access regexp:/etc/postfix/white-list.txt,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections,
  reject_rbl_client bl.spamcop.net
(smtpd_client_restrictionsパラメータは私の実際の設定を示しているが、必須でない指定も含まれている。誰もがこのように設定すべきだという意味ではない。)

 上記のように設定する前に、まずreject_rbl_client指定をS25Rチェックの前に置いて優先させることによって、DNSBLに引っかかった時のログがどうなるかを調べた。次のような記録がとれた。

Apr 29 11:27:56 reject: RCPT from 66.239.107.130.ptr.us.xo.net[66.239.107.130]: 450 4.7.1 Service unavailable; Client host [66.239.107.130] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.239.107.130; from=<***@elbloque.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<66.239.107.130.ptr.us.xo.net>

このような記録が拒絶ログソーティングスクリプトで拾われるように、スクリプトを次のように手直しした。

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host rejected:' | \

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host (rejected:|.*blocked)' | \

 これでしばらく様子を見ることにする。

すり抜けスパムがDNSBLにどれだけ引っかかるか

 3月から4月にかけてスパムを着信させたホストがDNSBLに引っかかるかどうかを、RBL.JPBlack list DB checkで調べてみた。このCGIによって、ホストがSPAMCOP、spamhaus、RBL.JPに登録されているかどうかを調べることができる(2008年3月20日「DNSBLって効くの?」を書いた時にはもっと多くのDNSBLについて調べることができたが)。
 送信元ホストと、それを登録しているDNSBLを表で示す。

a190.watel.vt.cust.gts.sk [85.248.46.190]SPAMCOP
blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]なし
gate49.cableone.ne.jp [61.7.42.49]なし
smtp.pyramide.co.ma [196.206.253.90]SPAMCOP
adsl.eb23-sjoaoponte.edu.pt [194.210.65.9]SPAMCOP
brevnov.drino.net [213.151.83.161]なし
adsl.ep-adrcisteralcobaca.edu.pt [194.210.105.124]なし
mail.gpk.lt [82.135.204.112]なし
cr-0.accnet.wireless.royell.org [208.91.182.67]なし
techfirewall.lighthouse.net [69.216.168.41]なし
unknown [211.12.212.178]なし
mail.thaibinh.gov.vn [222.252.216.155]SPAMCOP
o7.jdisonline.com [204.54.152.26]なし
mail.sistema102.net [200.50.20.150]なし
gprsinternet04.porta.net [200.25.197.97]なし
mail-fx0-f179.google.com [209.85.220.179]なし
pop.landrumshouse.com [209.194.32.242]なし
ttx01.ttx-net.sk [193.110.187.2]SPAMCOP
a2.sabnet.bj.cust.gts.sk [62.168.87.6]SPAMCOP
cerstef.b.astral.ro [83.103.177.74]SPAMCOP

 blu0-omc4-s29.blu0.hotmail.comとmail-fx0-f179.google.comはS25Rに引っかかるが、ここから着信したのは、hotmail.comとgoogle.comをホワイトリスト登録しているからである。正当なメールサーバを経由して送信されたスパムは、S25R方式ではいかんともしがたい。
 unknownのホストは、リトライの挙動からメールサーバと思われたものである。ホワイトリスト登録してみたら、着信したのはフィッシング詐欺のスパムだった。

 20個のホストのうち、SPAMCOPに登録されていたのが7個あった。ここから計算した阻止率は35%である。spamhausとRBL.JPには一つも登録されていなかった。このことから、S25Rをすり抜けるスパムをブロックするのにいくらかでも効果がありそうなDNSBLはSPAMCOPだけだと考えられる。
 また、2008年3月20日「DNSBLって効くの?」で述べたとおり、SPAMCOPだけが、S25Rで阻止されたスパム送信元ホスト10個のうち8個を登録していて、ほかのDNSBLは一つも登録していなかった。このことからも、役立ちそうなDNSBLはSPAMCOPだけだと思われる。ただし、その記事で述べたとおり、ウェブで見つけた証言によれば、そのSPAMCOPでも阻止率は50~60%程度しかないらしい。
 一方、SPAMCOPによる偽陽性判定のリスクも見て取れる。SPAMCOPに登録されていたsmtp.pyramide.co.maとmail.thaibinh.gov.vnは、名前からして明らかにボットではなくメールサーバである。第2レベルのラベルから見て、pyramide.co.maはモロッコの企業、thaibinh.gov.vnはベトナムの政府機関と推測される。これらのホストからスパムが送信されたのは確かでも、一時的にスパマーに悪用されただけかもしれない。同じホストから正当なメールも送信されるかもしれないのに、SPAMCOPは、ボットかメールサーバかを区別せずにブラックリストに登録している。ほかのDNSBLでも同じようなものだろう。DNSBLを信用して応答コード「5xx」で蹴るのがいかに危険かがわかる。
 とはいえ、蹴る時の応答コードを「4xx」にすれば、DNSBLを使っても、正当なメールをエラーリターンさせる事故を避けることができる。応答コードを変更するには、Postfixのmain.cfファイルで

maps_rbl_reject_code = 450

のように指定すればよい。この方法をとれば、SPAMCOPを利用してすり抜けスパムを減らすことができるかもしれない。
 次の記事で、SPAMCOPを利用する設定方法を説明する。

息子宛のスパムアクセスが再発した

 3月21日に、息子宛のスパムアクセスが1ヶ月以上途絶えたことを述べた。しかし、またかなりのスパムアクセスが来るようになった。4月12日から27日までの間に、アクセス回数26回。推定メッセージ数にして11通だった。やはり、一度メールアドレスがスパマーに漏洩すると、スパムアクセスが根絶することはないようである。
 スパムアクセスの中には、次のように3回トライするリトライアクセスがかなりあった。

Apr 24 20:57:16 unknown [189.79.211.229]
Apr 24 21:14:25 unknown [189.79.211.229]
Apr 24 21:41:33 unknown [189.79.211.229]

17分後に2回目、44分後に3回目のアクセスが来ている。このパターンは6シーケンスあった。グレイリスティングを併用していると突き抜けられてしまうパターンである。しかし、気付いた時には3回でアクセスが止まっていて、だまされてホワイトリスト登録することはなかったので、1通も着信しなかった。
 これらのリトライアクセスの送信者アドレスのユーザーIDは、「KichikawaMizuki」、「Fujino_Mitsuki」など日本人の名前だったことから、日本語のスパムだったと推測される。以前は、息子宛に着信したスパムは英語のものばかりだった。外国人スパマーがオンラインショッピングのサーバを侵害して盗んだメールアドレスが日本人スパマーにまで流れたようである。

土曜日, 4月 18, 2009

半月後のE-mailレピュテーション

 前回、トレンドマイクロのE-mailレピュテーションによる推定阻止率を59%と述べたが、その後半月のデータをとったら、もう少し良い値になった。
 4月1日から16日までに受けたスパムは191通(30日あたりに換算して358通)。スパムの受信数は2月には969通、3月には1061通と増えつつあったことから、月あたりのスパム数は4月前半にはその増分の半分だけ増えた、すなわち1061+(1061-969)÷2=1107通と大雑把に仮定すると、推定阻止率は68%。トレンドマイクロの「70%くらい」という言葉は嘘ではないと言える。
 とはいえ、S25R方式による阻止率は97%以上だから、Emailレピュテーションによる見逃し率はS25R方式の10倍以上ということである。メールサーバの無駄な負荷を減らすには役立つだろうが、ユーザーをスパムの被害から救うというレベルではない。ユーザーは、メーラーのベイジアンフィルタや、Becky!によるS25Rフィルタリングなどの対策を手放すことができない。
 ちなみに、4月1日から16日までに受けたスパム191通のうち、Becky!によるS25Rフィルタリングをすり抜けたものは9通だった。すなわち、判別率は95.3%で、メールサーバでのスパム対策が行われる前には97%以上だったのに比べて低い。これは、S25Rに引っかかるホストの方が、引っかからないホストよりも高い割合でEmailレピュテーションで阻止されるということを意味する。まともなメールサーバを経由したスパムはEmailレピュテーションでも阻止されないから、これは当然の結果と考えられる。概算すると、Emailレピュテーションによる阻止率は、S25Rに引っかかるホストに対して約7割、S25Rに引っかからないホストに対して約5割ということになる。

金曜日, 4月 03, 2009

E-mailレピュテーション

 3月30日から勤務先でスパム対策が始まった。S25R方式ではない。トレンドマイクロのE-mailレピュテーションを利用したものである。社内IT部門としては、社員をスパム問題から救うというよりも、スパム問題のために何もしていないと言われないための手っ取り早い方法をとりたかったらしい。
 その後に私が受けたスパムは、3月31日には14通、4月1日には15通、4月2日には16通だった。2月には969通、3月には1061通だったことから、この3日間に月あたり1100通の割合でスパムが押し寄せていたと仮定すると、阻止率は59%ということになる。2008年3月20日「DNSBLって効くの?」で、SPAMCOPを利用した場合の阻止率は50~60%と推測されると述べた。それと同じくらいである。トレンドマイクロは70%くらいと言っていると聞いたが、それより低い。
 DNSBLのたぐいのIPアドレスブラックリスト方式の効果はしょせんそんなものだろう。データベースの維持にコストがかかっているだろうに。

水曜日, 4月 01, 2009

April fool

 韓国のヌリビジョンは、バウンシングバック認証方式で100%のスパム阻止を誇る同社のスパム対策アプライアンス「OptPlus」を機能改良したと発表した。これは、同社の日本進出後、日本のスパム対策研究者から指摘された懸念に応えたもの。
 改良点の第一は、バウンシングバック認証要求メールを返送するかどうかをユーザーが選択できるようにしたこと。OptPlusは、入ってくるメールを辞書攻撃チェック、ウィルスパターンチェック、スパムパターンチェックの3段階のフィルタにかけ、それを通過したメールのうち、バウンシングバック認証済みでないものをペンディングキューに入れる。従来は、ペンディングキューに入ったメールすべてに対してバウンシングバック認証要求メールを返送していた。正当な送信者は認証手続きをするので正当なメールは受信できるが、スパマーは認証手続きをしないのでスパムは受信せずに済むというのが「100%のスパム阻止」の仕組み。しかし、スパマーにアドレスをかたられた被害者に身に覚えのないバウンシングバック認証要求メールが届くのは迷惑になると指摘されていた。また、その被害者がバウンシングバック認証要求メールを受けて、事情がわからないまま認証手続きをすると、スパムが受信されてしまうという問題もあった。
 そこで同社は、ユーザーがペンディングキューを見て、スパムに対してはバウンシングバック認証要求メールを返送しないようにできる機能を設けた。これにより、スパマーにアドレスをかたられた被害者への迷惑が避けられる。また、その被害者が間違って認証手続きをすることによるスパムの受信も回避できる。さらに、OptPlusの導入サイト同士でバウンシングバック認証要求メールの投げ合いになって両ユーザーが互いに相手からのメールに気付かないという「やぎさんゆうびん問題」も、ユーザーがバウンシングバック認証要求メールに対してバウンシングバック認証要求メールを返送しないようにすることで解消されるという。
 改良点の第二は、ホワイトリスト登録された送信者アドレスを持つメールであっても、ペンディングキューにいったん保留し、本当にスパムでないかどうかをユーザーが判断した上で受信できるようにしたこと。これにより、ユーザーの知人などのホワイトリスト登録されたアドレスをかたったスパムが受信されてしまうという弱点が解消され、将来にわたって100%のスパム阻止を維持できるようになるという。
 同社は、日本人から寄せられた声をOptPlusに活かしたことにより、同製品の日本国内での更なる普及を目指したいとしている。

土曜日, 3月 28, 2009

OptPlus売れていないんじゃないの?

 「バウンシングバック認証」でググると、私のブログ記事が1位と2位を独占している。2007年5月29日「「バウンシングバック認証」で検索上位」を書いて以来、順位は落ちていない。「OptPlus」でも1位と2位に私のブログ記事がヒットする。「Opt Plus」では7位と8位だが、「Opt Plus ASP」だと、なんとOpt Plus ASPの本家サイトを抜いて私のブログ記事が1位である。
 OptPlusやバウンシングバック認証方式について調査しようとすると、痛烈な批判記事がいやでも目に付いてしまう。こんな状況の中で、OptPlusはどのくらい売れているのだろうか。
 いろいろ検索してみても、ユーザーの声はマスコミサイトのヨイショ記事にしか見当たらない(そのユーザーは、OptPlusのベンダーのビジネスパートナーである)。S25R方式については、「効果抜群でびっくりした」、「これほど効果があるとは予想していなかった」などの声がたくさん見つかるが、OptPlusについては見つからない。バウンシングバック認証要求メールを実際に受けたという話題も見つからない。
 2007年5月にたくさんのマスコミサイトがヨイショ記事を発表してから2年近くになるが、Opt Plus ASPやベンダーのSYSMATE社のコンテンツは代わり映えしない。私の指摘でユーザーが抱くであろう疑問(たとえば「やぎさんゆうびん問題は起こらないのか」など)に答えるコンテンツが追加されてもいないし、獲得ユーザー数やユーザーからの賞賛の声を誇示するコンテンツもない。売る気ないんじゃないだろうか。
 OptPlusが売れていないと思われるのは、おそらく、私のバウンシングバック認証方式反対キャンペーンによるものではない。もちろん、私のブログ記事を読んで、たくさんのマスコミサイトのヨイショ記事を鵜呑みにせずに済んだ人はいるかもしれない。しかし、私がキャンペーンを張らなくても、おそらくOptPlusは売れなかった。
 OptPlusを導入したASPやベンダーの失敗の原因は、日本人のニーズを正しく理解していなかったことである。たいていの日本人は、スパムを受けなくて済むことよりも、正当なメールを確実に受信できることの方を重視するのである。送信者が認証手続きをしなかったら正当なメールも受信されないというバウンシングバック認証方式には、おそらく多くの日本人は見向きもしなかったのである。メーラーに付いているベイジアンフィルタで80~90%のスパムをごみ箱に振り分けることができればそれでおおむね満足で、“スパムの阻止率100%”のために金を払おうと思う人などほとんどいないのである。
 失敗の原因のもう一つは、S25R方式を知らなかったことである。S25R方式を発表したのは2004年。「スパム 対策」のGoogle検索で1位か2位にヒットする状況が2005年以来ずっと続いている。なのに、2007年になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」などと言っている。ちょっと調べれば、スパムの阻止率97~99%、高スキルの技術者でなくても実装できる、しかも無料というS25R方式には勝てないということはすぐにわかったはずである。
 日本人の心と日本人の発明に目を向けなかった事業者の失敗である。

(4月6日追記)
 「OptPlus」と「Opt Plus ASP」での検索順位が少し下がった。しかし、トップ10には入っているので、アピール度は十分である。

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

OptPlusの認証画面の脅し文句

 「OptPlus」でググると、7位に面白いページがヒットする。

OptPlus メール
注 意: このシステムはそちらの接続環境(66.249.67.207)で認証したことを自動的に記録いたします。認証後、迷惑メールと判断されるメールを送られてきた場合、法的な処置をとる場合がございますので、翌゚ご了承下さい。 ...
mail.yungjin.co.kr:8886/mmpmgr/user/auth_view.php?msgid=498146C84719&lang=jp - 6k -
(ごみ文字が入っている)

 このサイトは韓国の製薬会社。OptPlusの認証画面である。
 66.249.67.207は、逆引きするとわかるが、GoogleのロボットのIPアドレスである。Googleはどうやってこのページを見つけたのだろうか。この会社にメールを送ってバウンシングバック認証要求メールを受けた人しか知り得ないURLのはずである。誰かが公表したのかと思ったが、検索しても見つからなかった。
 アクセスしてみると、警告文のIPアドレスの部分は自分のIPアドレスになることがわかる。サーバ側でアクセス元のIPアドレスを検出して表示して見せることができるのは当然のことだが、インターネットの仕組みに詳しくないユーザーは不気味に感じることがある。何かを問い合わせようと思ってメールを送った人は、自分のIPアドレスの表示と「法的な処置をとる」という脅し文句に恐れおののいて、認証手続きをせずにあきらめてしまうかもしれない。
 お客様への気配りの心をわきまえた日本人は、こんなことをしてはいけない。

日曜日, 3月 22, 2009

XMailCFG (for Windows)をリンク

 S25Rの目次ページに、XMailCFG (for Windows)へのリンクを掲載した。ホワイトリスト情報をお寄せくださった方から教えていただいたものである。
 XMailは、UNIXとWindowsで動作する、オープンソースのFINGER/SMTP/POPサーバ。XMailCFGは、XMailの設定やメンテナンスを行うソフトウェアであり、XMailにS25Rを組み込むことができる
 XMailとXMailCFGのおかげで、S25Rを組み込んだメールサーバをWindows上でも実現できるようになった。しかも、両ソフトウェアともフリーである。「S25RをWindowsサーバで実現できませんか」という質問を受けたら、これを紹介してあげることにしよう。

掲示板のスパム対策

 協力者からのホワイトリスト情報は、メールよりも掲示板で寄せられることの方が圧倒的に多い。掲示板は、メールとは違って、個人情報を明かさずに投稿できることと、自分の貢献が公になることから、協力者にも好まれるようである。掲示板がなければこれほど多くのホワイトリスト情報は集まらなかったかもしれない。
 掲示板のスパム投稿も問題になっている。スパム投稿のために掲示板を維持できなくなり、閉鎖した人もいる。
 私の掲示板は、他の多くの掲示板に比べてスパム投稿を受けにくかった。トップ画面に投稿フォームがなく、投稿画面へ移るのにワンクリック必要であることが幸いしたようである。また、トップ画面は記事タイトルのスレッド表示で、記事の内容の表示にもワンクリック必要であることから、スパム投稿の宣伝効果に欠けると敬遠されたことも幸いしたかもしれない。
 それでも、私の掲示板にもスパム投稿が来るようになった。そこで、スクリプトに手を加えて、投稿画面のURLを変更してみた。これにより、投稿画面をダイレクトに狙うアクセスをエラーに落とすことができる。しかし、これも破られていたちごっこになった。
 そこで、掲示板スクリプトのファイル名を変えるという方法をとった。「raib.cgi」というファイル名は「raib_3036.cgi」として、また攻撃が来たら数字の部分を変更してかわすことにする。そして、元の名前の「raib.cgi」は、掲示板へジャンプさせるHTMLを吐くシェルスクリプトにする。これが吐くHTMLは、METAタグで掲示板へジャンプさせるようになっている。Aタグは書かず、また、METAタグ中のURLは相対パスにしてフルパスをわかりにくくする。これにより、ブラウザでアクセスする人は手間なく掲示板に到達できるが、スパマーが使う自動プログラムでは掲示板に到達しにくくなる。この方法をとってからは、スパム投稿は根絶した。
 私は無精なので、スパム投稿対策機能を持つ新しい掲示板スクリプトを導入するのでなく、使い慣れたスクリプトを使い続けたかった。これでスパム投稿を排除できたのは幸いだった。投稿してくださるゲストにとっても、CAPTCHA認証の手間を強いられないのは楽だろう。
 掲示板の内容が検索エンジンに拾われなくなるが、そのくらいはやむを得ない。むしろ、ロボットによってPerlスクリプトが連続で動かされてサーバのCPU負荷が上がるよりはよいだろう。
 対策をとったのは2007年だが、今なお、投稿画面の古いURLへのアクセスが日に数回来ている。アホなボットである。

 この方法は私のネットフレンドにも勧めたのだが、その人の掲示板は、この方法をとっても何度か破られている。トップ画面に投稿フォームがあるので、スパマーに狙われやすいのだろう。それでも、古い掲示板スクリプトを使い続けたいならば、これ以上に運用が楽な防御方法はないと思う。

 参考までに、掲示板へジャンプさせるHTMLを吐くシェルスクリプトのコードは次のとおり。「euc-jp」の部分は、メッセージの文字コードに合わせる。シフトJISの場合は「shift_jis」にする。

#!/bin/sh
echo 'Content-type: text/html'
echo
echo '<HTML LANG="ja">'
echo '<HEAD>'
echo '<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=euc-jp">'
echo '<META HTTP-EQUIV="refresh" CONTENT="0; URL=./raib_3036.cgi">'
echo '</HEAD>'
echo '<BODY>'
echo '<CENTER>掲示板への攻撃を防御するため、別URLへ移動します。</CENTER>'
echo '</BODY>'
echo '</HTML>'

土曜日, 3月 21, 2009

息子宛のスパムアクセスが途絶えた

 2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信数について述べた。オンラインショッピング会社のサーバが侵害されて息子のメールアドレスがスパマーに漏洩したものと思われ、2007年9月から届き始めた。今年3月までの着信数の推移は次のとおりである。

2007年9月:3通
10月:2通
11月:2通
12月:3通
2008年1月:6通
2月:5通
3月:11通
4月:3通
5月:2通
6月:0通
7月:0通
8月:1通
9月:0通
10月:0通
11月:0通
12月:1通
2009年1月:0通
2月:0通
3月:0通

 2008年12月22日を最後に着信していない。2月14日「「4xx」は迷惑か?」の中で、
「今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。」
と述べた。この日時点で、過去1ヶ月のスパムアクセスがそのくらいだった。
 今日(3月21日)、ログを見たら、息子宛のスパムアクセスが2月15日以降一度もないことがわかった。ピーク時には月に着信11通、ということは月に数百回あったスパムアクセスが、1ヶ月以上にわたって途絶えている。
 わざとスパマーに拾わせたおとりのアドレス、ウェブページから拾われた間違いアドレス、それらを改変したでたらめのアドレス(2006年9月15日「宛先の正しいスパムの阻止率」参照)へのスパムアクセスは、どんなに「550」を返し続けても、何年たっても減っていない。だから、息子宛のスパムアクセスも、減ることはあっても途絶えることはないと思っていた。途絶えたのは意外だった。
 推測するに、オンラインショッピング会社のサーバを侵害するという難しい方法で盗まれたメールアドレスは、少数のスパマーにしか利用されず、その少数のスパマーのほぼ全員が、息子宛のスパムの送達率の悪さに送信をあきらめたのかもしれない。だとすれば、S25R方式の勝利である。

(3月23日追記)
 3月22日に息子宛のスパムアクセスが1回あった(逆引き失敗で蹴っていた)。根絶はしていないようである。

水曜日, 3月 18, 2009

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

 3月14日の記事の続編。
 公開ホワイトリストファイルへの5分間隔のアクセスを見つけた時、アクセス元ホストにSMTPアクセスをしてみたら、HELOコマンドへの応答で名乗ったFQDNは「.ne.jp」を冠していた。そのFQDNは順引きできず、また、HELOアドレスは信用できないという思い込みがあって、そのサイトドメインを疑おうとは思いもしなかった。逆引きドメイン名の登録者に通報したが、今なお返事がない。
 再度HELOアドレスを確認し、そのサイトドメイン名のMXレコードを検索してみた。すると、セカンダリMXのIPアドレスがそのホストのものと一致していた。
 逆引き名から、犯人は小規模サイトか個人サイトと推測していたが、そうではなかった。非営利の某ネットワークサービス提供団体だった。常軌を逸したダウンロードをしていたセカンダリMXは、他社の回線を借りて接続していたもので、だから逆引き名からはその団体のサーバだとはわからなかったのである。
 ログを再度調べたら、そのサイトのプライマリMXも公開ホワイトリストファイルをダウンロードしていることがわかった。こちらは一日1回である。セカンダリMXに常軌を逸したダウンロードをさせていたのは何だったのか。cronの設定ミスだったとしたらお粗末。
 手動のSMTPでpostmaster宛のメッセージを打ち込んだが頻繁なアクセスがやまないので、ルータでHTTPをブロックしていた。今日、ブロックを解除してみたら、アクセスはやんでいた。メッセージに気付いたのか、cronジョブがフェールしているのに気付いたのか。HTTPをブロックしてダウンロードを拒絶したのが制裁措置と映っただろうか。設定を直したと連絡をくれればすぐにブロックを解除したものを。
 非営利とはいえ、業務でネットワークサービスを提供しているからにはプロ。小規模サイトや個人サイトのノンプロとは違う。プロならなおのこと、自分の事業のために一個人の無償ボランティアを利用するからには常識として何を守るべきかをわきまえてほしいものである。

火曜日, 3月 17, 2009

公開ホワイトリストファイルから冗長なスペースを削除

 これまで、公開ホワイトリストファイルでは、見栄えのために「OK」のカラム位置をそろえていたが、冗長なスペースを削除して、正規表現との間のスペースを1個だけにした。
 理由の一つは、公開ホワイトリストファイルから「OK」を削除する加工をして使う人がおられることである。加工のしやすさのためには、冗長なスペースはない方がよく、それは見栄えよりも大きな利点だと考えた。
 もう一つの理由は、ファイルサイズの削減である。これで約7KB(約20%)減った。わずかながらダウンロード時間の短縮になる。
 ただし、論文中のホワイトリストサンプルでは、見栄えのために「OK」のカラム位置をそろえたままにしている。

月曜日, 3月 16, 2009

ちゃんとログ見てるんでしょうね

 3月14日「S25Rの採用サイトの推定数」で述べたとおり、公開ホワイトリストファイルを毎日ダウンロードしているサイトは50ほどある(気を遣ってくれる人は、ファイルのタイムスタンプを見て、更新されている時だけダウンロードするようにしてくれているが)。「定期的に取得していいですか」と事前に打診してくれた人は一人しかいない。
 まあいいです。節度をもって利用してくだされば。1回きりのアクセスは単に見ただけかもしれないが、毎日定時にアクセスがあると、どこのサイトがS25R方式を採用してくださっているかがわかって面白い。誰でも知っている某国際空港とか、超有名な某大手出版会社とか。もちろん、私から無断で公言することはしないけれども。

 それはそうと、気になったことがある。cronジョブで公開ホワイトリストを毎日ダウンロードすればホワイトリストのメンテナンスを自動化したことになるとは、まさか思っていないでしょうね。
 公開ホワイトリストを組み込めば、偽陽性判定の確率を下げることはできる。しかし、ゼロにはできない。公開ホワイトリストには、S25Rに引っかかる正当なメールサーバのうち、私と協力者がたまたま見つけたもの(S25Rに引っかかるサイトからの申告を含む)しか収録されていないのである。素のS25R方式を使っている以上、必ずログを監視して、偽陽性判定からの救済を手動で行わなければならない。偽陽性判定はめったに起こらないかもしれないが、ログの監視をサボってはならない。
 ホワイトリストのメンテナンスを自動化したいと思ったら、その方法は、公開ホワイトリストの自動取得ではない。グレイリスティングかタールピッティングの併用、あるいは自動ホワイトリスティングプログラムの組み込みである。くれぐれも勘違いしないでいただきたい。