木曜日, 12月 11, 2014

メーリングリスト制御スクリプトのご紹介

 スパム対策の話ではないのだが、私の自作のメーリングリスト制御スクリプトについて。
 私は、ある研究会のためにボランティアでメーリングリストを運用している。かつてはメーリングリストで議論も行われていたが、そのようなメールの受信を歓迎する会員ばかりではないので、議論は掲示板でやってもらい、メーリングリストの用途は原則として、事務局からの通達や会合案内、会員からの挨拶や情報提供や議論の開始・経過・結果報告などに限ることにした。
 それでも、会合案内に対する出欠回答(他の会員にとっては無駄な情報)をメーリングリストに同報してしまう人や、添付ファイルは投稿しないように(サーバの過負荷や受信者のPCの負荷の原因になるので)言っていても間違って投稿する人がいるので、メーリングリストはモデレートのポリシーにした。
 Majordomoのような高度なメーリングリストプログラムならモデレートのポリシーは設定だけで実現できるが、私は独自のメッセージ加工のためにGAWKスクリプトでメーリングリストを実現しているので、モデレートのポリシーは前段にPerlスクリプトをかませることで実現した。私以外の人からの投稿はいったん私に送り、私はメーラーBecky!の「手を加えずに転送」の機能を使って再投稿するという運用方法である。この時、メールのDate、From、To、CC、Subject、本文は元のままになるが、添付ファイルをはずすことはできる。再投稿した私のアドレスはResent-Fromヘッダに記録されるので、Perlスクリプトはそこに私のアドレスがあることを確認して配信用スクリプトへ送るという仕組みである。なお、添付ファイルが投稿された時には、それをはずしただけで再投稿するのでなく、ファイルをウェブのダウンロードサービスに掲載したことの説明を添えて、通常の転送で再投稿するようにしている。Perlスクリプトは、Fromが私のアドレスである場合も配信用スクリプトへ送る。

 その後、会合案内は時間遅れなしに配信された方が会員は嬉しいだろうと考えたので、新規メールで添付ファイルがない(ヘッダから添付ファイル付きとわからない場合でも、メール本体が30,000バイト以下である)ならば非モデレート(即時配信)、返信メールがメーリングリストに同報されたものと添付ファイル付きの投稿メールはモデレートというポリシーにした。
 会員には、「Toにメーリングリストアドレス一つだけが指定され、かつ添付ファイルがない投稿メールは即時配信されます。この条件に合わない投稿メールは保留され、私が確認してから配信します。会合の出欠回答など、全会員に知らせる必要がない情報は配信しません」と説明している。メーリングリストで配信されたメールに対する「全員宛返信」でメーリングリストに宛てられた返信メールでは、メーリングリストアドレスはCCに、またはメーラーによってはToに元の送信者に併記して指定されているので、「Toにメーリングリストアドレス一つだけ」の条件に合わず、モデレートになる。
 なお、「全会員に受信してもらう必要のない内容の返信を、わざわざToをいじって即時配信の条件に合わせて送信することはしないでください」と要請している。
 これで私のモデレート作業は楽になった。

 このスクリプトを私のサイトで「半モデレート・ポリシーのメーリングリスト用制御スクリプト」というコンテンツとして公開した。広く使われているMajordomoの前段にかませる方法を説明しているが、私はMajordomoを使っていないので、もし間違いがあったら指摘してください。
 なお、ポリシーに反して返信メールでわざわざToをいじる人がいるなら、In-Reply-Toヘッダがあることをもってそれを見破ることができるので、その方法も説明している。しかし、過去のメールやよそから得たメールを返信操作で引用した新規トピックが即時配信されなくなるので、意図的にポリシーに反することをしない善人ばかりのメーリングリストでは、そこまではしない方がよいと思う。
 需要が多いとは思わないが、このような半モデレートのポリシーというものもメーリングリストによっては便利なことがあるというアイデアの紹介のつもりでコンテンツを掲載した。

日曜日, 11月 30, 2014

第三者中継によるスパム

 昨日2014年11月29日の記事「公開ホワイトリストのミス」で、digitalink.ne.jp配下のホストからスパムが来たことを述べたが、そのホストは、gr.jpを冠したあるドメインのMXだった。詐称された送信者アドレス(Return-PathおよびFrom)からMXを検索してわかった。
 昨日23時42分には、そのスパムと酷似した中国語のスパムが、co.jpを冠したドメインのメールサーバから来た。それら2通とも、発信源は[58.221.58.4]である。第三者中継をやられたと思われる。
 私のサイトでの観測では、最近、第三者中継を狙うスパム送信アクセスの割合が多くなっている。11月2日から11月30日7時までのログによると、rejectされた件数は245、そのうちRelay access deniedは129件。実にスパム送信アクセスの半数ほどが第三者中継を狙ったものである。典型的なアクセスを示す(ログ行から必要項目だけを抽出して示す)。

Nov 29 11:15:21 unknown[116.230.8.166]: from=<gibdjv@reto.jp> to=<***@sina.com>
Nov 29 11:15:21 unknown[116.230.8.166]: from=<gibdjv@reto.jp> to=<***@sina.com>
Nov 29 11:15:22 unknown[116.230.8.166]: from=<ligc@reto.jp> to=<***@sina.com>
Nov 29 11:15:22 unknown[116.230.8.166]: from=<ligc@reto.jp> to=<***@sina.com>
Nov 29 11:15:23 unknown[116.230.8.166]: from=<jxnbrv@reto.jp> to=<***@sina.com>
Nov 29 11:15:25 unknown[116.230.8.166]: from=<jxnbrv@reto.jp> to=<***@sina.com>
Nov 29 11:15:31 unknown[116.230.8.166]: from=<uuyya@reto.jp> to=<***@sina.com>
Nov 29 11:15:35 unknown[116.230.8.166]: from=<uuyya@reto.jp> to=<***@sina.com>
Nov 29 11:15:40 unknown[116.230.8.166]: from=<eevtj@reto.jp> to=<***@sina.com>
Nov 29 11:15:45 unknown[116.230.8.166]: from=<eevtj@reto.jp> to=<***@sina.com>

 スパムの標的になった被害者のtoアドレスは伏せたが、すべて同じである。「@reto.jp」は、私のサーバの逆引き名a.reto.jpから作ったものである。一つの宛先へ、送信者アドレスのユーザー名を変えながら第三者中継を試みている。第三者中継をしないサーバであることくらい、最初の1回のアクセスでわかるだろうに。ずいぶん効率の悪い手口だ。
 第三者中継を禁止する呼びかけが行われるようになってからもう17年くらい経つんじゃないかと記憶しているが、ボットを使う手口がだんだん効かなくなってきたから、再び第三者中継を狙うようになったのだろうか。今回見つかった国内のメールサーバ2つは、第三者中継がほとんどなくなっていたので油断して設定をミスしていたのだろう。当然すぐに直すはずである。
 第三者中継が使えなくなり、ボットもだんだん使えなくなってきて、もう再度第三者中継を狙うしか、大量スパム配信の道がなくなってきているのではないか。それはOP25Bが広まったおかげだろう。
 もちろんS25Rはボットからのスパム直送ルートをほぼふさいでしまう方式だが、インターネットの偉い人ではない私が一人で作ったS25R方式は、いわば日本の町工場の親父が職人技でトンテンカンと作った防御用の盾のようなもの。「誰が作ったものであろうと良いものは良い」と認めてくださった人たちには役立っているが、権威者が認めたものにしか目を向けない人の方がはるかに多いだろう。だから、ボットが使えなくなってきていることには、偉い人たちが寄ってたかって実施したOP25Bの方が効いているに違いない。

 なお、昨日スパムを送ってきたdigitalink.ne.jp配下のホストは設定が不備だっただけの善良なメールサーバとわかったが、digitalink.ne.jpの丸ごと許可を取り消したのはそのままにする。その善良なメールサーバからの受信が必要だとS25R導入サイトから言ってこられた時には公開ホワイトリストに掲載する。

土曜日, 11月 29, 2014

公開ホワイトリストのミス

 中国語のスパムが着信した。送信元ホストはsenyo8z207.digitalink.ne.jp [59.106.161.207]。S25Rチェックに引っかかるホスト名なのに通過したということは、公開ホワイトリストのミス。

# Jun 08, 2009: smtp.asahikei.co.jp (*)
/^senyo5z57\.digitalink\.ne\.jp$/ OK

# Jun 02, 2009: senyo6z161.digitalink.ne.jp (*)
/\.digitalink\.ne\.jp$/ OK

# Dec 14, 2007: kagakudojin.co.jp's (*)
/^senyo3z55\.digitalink\.ne\.jp$/ OK

 過去に登録したdigitalink.ne.jpのホスト3個のうち2個目で、何を考えたのかドメイン丸ごと許可にしていた。ne.jpは(携帯電話会社を除いて)丸ごと信用すべきでないというポリシーを私は今では持っているのだが、それを明確にする前だったのかな。
 幸い、FQDNをコメントに書き遺していたので、ホストの個別許可に直した。

# Nov 29, 2014: (revised)
# Jun 02, 2009: senyo6z161.digitalink.ne.jp (*)
/^senyo6z161\.digitalink\.ne\.jp$/ OK

 この修正によって、他のdigitalink.ne.jp配下の正当なホストからの受信ができていたサイトで偽陽性判定あるいは受信遅延(グレイリスティングを併用している場合)が起こる可能性がある。起こったら<webmaster@gabacho-net.jp>に知らせてください。
 申し訳ございませんでした。m(_"_)m

火曜日, 11月 11, 2014

lstrk.net

 すっかりブログをサボっていた1年前のことですみません。
 2013年10月にlstrk.netドメインからのスペイン語のスパムを連続して受けた。宛先は個人アドレス「deo」。差出人アドレスは一様に「"VivaAerobus.com" <newsletter@vivaaerobus.com>」。送信元ホストは以下のとおり。

2013/10/04 vmta-e-206.lstrk.net [66.216.133.206]
2013/10/07 vmta-e-207.lstrk.net [66.216.133.207]
2013/10/09 vmta-c-180.lstrk.net [66.216.136.180]
2013/10/10 vmta-c-180.lstrk.net [66.216.136.180]
2013/10/14 vmta-e-207.lstrk.net [66.216.133.207]
2013/10/14 vmta-e-207.lstrk.net [66.216.133.207]
2013/10/15 vmta-c-179.lstrk.net [66.216.136.179]

 「vmta」は仮想MTAの意味だろう。送信元はボットではなくメールサーバで、ご丁寧にDKIM-Signatureまで付いている。
 ドメイン丸ごとブラックリスト入りさせた。

/\.lstrk\.net$/ 450 past conviction for spam; contact <postmaster@gabacho-net.jp>.
(スパムの前科;postmasterに連絡せよ)

postmasterに宛てられていたら真っ当なメールと推定して受けてやろうと思ったが、その後次から次へと来るアクセスにpostmaster宛はない。再送信を放置したら2日間続く。
 リトライアウトによる送達失敗の連続に気付けばやむだろうと思ったが、何ヶ月もやまない。うざったくなってついに554で蹴った。

/\.lstrk\.net$/ REJECT past conviction for spam; contact from another network.
(スパムの前科;他ネットワークから連絡せよ)

そうしたらいつしかやんでいた。やっと拒絶の意思に気付いたか。今はlstrk.netの動静を観察しやすいように450の拒否条件に戻している。
 2009年2月14日「「4xx」は迷惑か?」で、S25R方式のアイデアを取り入れたフィルタリング方式のスパム対策システム「abmail」の説明に
「S25R派生の、拒否応答で防御策を敵に気付かれる手法では、いずれ敵の攻撃策が上回るから有効性の寿命は短い。abmailの手法は正常に受信したと敵に見せかけるので、敵は徐々に収益が低下していくことしか知り得ない。」
とあったことを取り上げて、「私の経験上、拒否応答を返し続けた方が、敵がだんだんあきらめてスパムアクセスが減るので得策である」と反論した。それは、lstrk.netにスパム送信をあきらめさせたことで一層実証された。
 S25R方式を発表してたくさんのサイトで採用されてから10周年を迎えてなおスパマーに破られていない実績をなめるんじゃねえぞ。:-P
 日本に恫喝外交を仕掛けてくる国に対して譲歩で丸く収めようとした外交姿勢は、要求のさらなるエスカレートという結果を生んだ。毅然とした外交姿勢をとったら、ある国はこれ以上押せないと気付いた様子を見せ始め、ある国は反日政策の自縄自縛でどうしようもない自国不利の状況に陥り始めている。スパム対策での「受けたふり」と「毅然と拒否」のポリシーの違いは、そういう外交問題を彷彿とさせる。

金曜日, 11月 07, 2014

拒絶ログソーティングスクリプトの新バージョンを少し修正

 拒絶ログソーティングスクリプトの新バージョンを10月27日に公開したが(こちらの記事)、全面的に変更していたegrepの式を少し修正した。

egrep 'reject: RCPT from [^ ]+ 4[0-9][0-9] ' | \

egrep 'reject: RCPT from [^]]+\]: 4[0-9][0-9] ' | \

 入力されるログ行の実例は次のとおり。

Nov  6 13:55:31 a postfix/smtpd[32141]: NOQUEUE: reject: RCPT from websmtp.sohu.com[61.135.130.240]: 450 4.7.1 Service unavailable; Client host [61.135.130.240] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?61.135.130.240; from=<***@sohu.com> to=<***@gabacho-net.jp> proto=ESMTP helo=<websmtp.sohu.com>

(「websmtp.sohu.com」と「[61.135.130.240]」の間にスペースがない)

だから、修正前の式でも問題ないのだが、もしPostfixのログフォーマットがクライアントホスト名とそのIPアドレスとの間にスペースを挟むように変更されたらと考えて(多分ないと思うが)、そうなった場合に誤動作しないようにした。
 実は、「from 」の後のスペースを探す代わりに「:」を探すようにしようと一度考えたのだが、おっと危ない。IPアドレスがIPv6の表記形式だったら誤動作してしまう。なので、「]:」を探すようにした。

木曜日, 11月 06, 2014

DNSBLとしてbarracudaを使う推奨

 すっかりブログをサボっていた頃に、掲示板のゲストのもっちーさんから、SpamCopは偽陽性判定が多いからbarracudaを使うようにしたとの投稿をいただいた。
 確かにSpamCopによる偽陽性判定は私も経験しているが、さほど多くはないし、maps_rbl_reject_code=450を設定しているので受信に失敗したことはない。ただ、組織サイトではSpamCopの偽陽性判定が問題になるかもしれないので、もっちーさんが投稿してくださった設定方法の情報を紹介する。

他の方への参考用に linux postfix 環境用
参考サイト
http://stdman.blogspot.jp/2009/11/brbl.html

resolv.confに書いてあるDNSの登録が必要です。
resolv.confの記載がローカルIP等になっている場合はDNSの管理者に実際に上位に問い合わせるグローバルIPを聞いて登録する必要があります。(推奨)

面倒なときはgoogle dns(8.8.8.8)を使えば(resolv.confに書けば他のは削除)既に登録(恐らくいろいろな人が登録を実行している)されているので登録する必要がないです。(非推奨ですが^^;)

host 2.0.0.127.b.barracudacentral.org
こちらのテストは必須かと思います。
2.0.0.127.b.barracudacentral.org has address 127.0.0.2
が戻ってくればOK

main.cfのrblの記載は
reject_rbl_client b.barracudacentral.org
こうなります。

引っかかった場合のコードは私の場合は451を返すようにしています。(再送してもらえるように)

火曜日, 11月 04, 2014

今時未承諾広告メールとは

 10月に、*****DENTAL(一部伏せ字)という、国内の(ウェブを見る限りは)真っ当そうな歯科医療用品販売事業者からの未承諾広告メールが3通来た。送信元ホストは次のとおり。

b.ss35.on9mail.com [209.144.27.52] (1通目)
c.ss38.on9mail.com [209.144.21.149] (2通目、3通目)

 宛先は私の個人アドレス。whoisに載っているが、自分のウェブサイトで公表してはいない。連絡先として公表しているアドレスは「webmaster」である。あえてスパムと書かずに未承諾広告メールと書いたのは、送信者アドレスを偽った卑劣なスパムとは違うと思ったからだが、送信者は合法のつもりでも違法な「特定電子メール」(自己又は他人の営業につき広告又は宣伝を行うための手段として送信をする電子メール)である。
 慇懃かつ脅しを効かせたメールを送った。

*****DENTAL様

 貴社を差出人アドレスとする未承諾広告メールをこれまでに3通、on9mail.comドメインのサーバーから受信しています。もし貴社がon9mail.comに送信を委託されたものであれば、私への送信は「特定電子メールの送信の適正化等に関する法律」第三条に違反します。私は、本条に挙げられた、事業者が広告メールを送信してよい受信者のどの条件にも当てはまりません。
 なお、メールに書いてあったunsubscribeのためのURLは、利用するとアドレスが他の迷惑メール送信者に転売される懸念が払拭できないため、利用しておりません。
 送信の停止をお願いいたします。(私のメールサーバーで受信拒否の設定準備が完了しておりますが、まだ設定してはおりません。)

 詫び状が来た。それによれば、インターネットで集めた私のアドレスを歯科医療関係者だと勘違いしたとのことだが、ほんとかいな。私の知らない人で、私に初めてメールを送ってくる時に私の個人アドレスに宛てるのは、私の所有ドメインに関する用件のためにwhoisでアドレスを知った人だけのはずで、さもなければスパマーしかいない。
 on9mail.comとはどういうサービスなのかよくわからない。「未承諾広告メールの送信請け負います」の事業者なんだろうか。名前の意味もよくわからん。「on9」というのは広東語で「馬鹿」というスラングらしいのだが。

 参考までに、「特定電子メールの送信の適正化に関する法律」第三条の条文は次のとおり。

第三条 送信者は、次に掲げる者以外の者に対し、特定電子メールの送信をしてはならない。
一 あらかじめ、特定電子メールの送信をするように求める旨又は送信をすることに同意する旨を送信者又は送信委託者(電子メールの送信を委託した者(営利を目的とする団体及び営業を営む場合における個人に限る。)をいう。以下同じ。)に対し通知した者
二 前号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを送信者又は送信委託者に対し通知した者
三 前二号に掲げるもののほか、当該特定電子メールを手段とする広告又は宣伝に係る営業を営む者と取引関係にある者
四 前三号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを公表している団体又は個人(個人にあっては、営業を営む者に限る。)

月曜日, 11月 03, 2014

一日中拒絶記録がなかった日

 昨日2014年11月2日には、メールログにrejectが一件も記録されなかった。最近、OP25Bが多数のISPに広まったのと、私へのスパム送信を多くのスパマーがあきらめたせいか(2006年9月28日「拒絶の効果?」)、スパムアクセスが減ってきたなあとは感じていたのだが、rejectが一日中一件も記録されなかった日は、2003年5月にS25R方式の開発を開始して以来初めてのことである。
 こんなことがあると、メールサーバに異常が起こったのではないかと心配になってしまう。でも、メールマガジンなどはちゃんと着信しているし、今日11月3日にはrejectが2件記録されたので、安心した。
 インターネットの世界全体でスパムが減ったのだろうか。でも、「導入者の皆様の声」の12番に掲載させていただいたHさんが10月1日にくださった礼状によれば、月20,000通ほど押し寄せるスパムの着信を月800通(GIDEONによる偽陽性判定を含む)まで減らすことができたというのはつい最近のこと。世の中でスパムが減っているとも思えない。
 私のサイトは強固な防衛力であまりにも平和になってしまって、2013年に会社勤めも辞めたので、外の世界の様子がわからなくなってしまった。よろしかったらどなたか最近のスパムの量の状況を教えてください。

(2014/11/04追記)2010年1月30日の記事に、「2008年11月からスパムの受信が急激に減少しており、これはボットを操るスパマーの上位ISPが通信を遮断したためらしい」と書いていた。同じようなことがあったのかもしれない。

またドイツで誤った設定

 すっかりブログをサボっていた今年8月5日のこと。旅行先からログをみたら、ドイツのドメインからのメールアクセスが引っかかっていた。許可してみたら、ドイツの人からのメールだった。
「『550 S25R check reject』というエラーで送信が失敗しました。私のドメインを拒否リストからはずしていただければ幸いです。」
 メールにあったエラーメッセージの中の送信先IPアドレスを逆引きして、そのドメイン名を「www.」につなげてウェブを見たら、ドイツ国内のサイトだった。ドイツ語は読めないんだが(大学で履修した第二外国語はフランス語だった)、なんとか見当を付けて連絡フォームに書き込んでから、その人に返信した。
「メールありがとうございます。
宛先ホストはmail.****.netのようです。http://www.****.net/の連絡フォームに以下のように書き込みました。
------
私はS25Rスパム対策方式の開発者です。○○様が、貴サイトでのS25Rの誤った使用のために貴サイトへメールを送ることができません。S25Rはしばしば偽陽性判定を起こすので、応答符号550を返すことは絶対にしてはなりません。取り急ぎ155.130.***.deをホワイトリスト登録してください。
------
また、あなたのホストをS25R公開ホワイトリストに掲載しました。
もしなおもお困りなら再度ご連絡ください。」
 その後、その人からも宛先サイトからも何も連絡が来ていない。
 前にもこんなことあったっけと思い出した。2011年4月4日「ドイツでのS25R設定にベルギーから苦情」に書いていた。その時も、申告者からの「解決した」「なおも解決しない」という報告も、宛先サイトからの「対処した」という報告もなかった。その時のサイトとは、今回はまた別のサイトだった。
 日本人ならたいてい、「解決した」「対処した」という連絡をくれる。S25Rの間違った運用(リトライの放置)のせいで手間をかけさせられたのに「親切に対応してくれてありがとう」と謝辞をくださった人さえいた。これが日本の美徳だと思う。数少ない体験から他国の国民性をうんぬんすべきではないとわかってはいるが、こういうものなのかなと思ってしまう。もちろん、ドイツ車などから感じられるドイツ人の職人気質(日本の職人気質も相当誇らしいものだが)には尊敬の念を持っているし、どこの国にもいる「日本の文化好き」と言ってくれる外国人にはとても親しみと感謝の念が湧くのではあるが。

月曜日, 10月 27, 2014

拒絶ログソーティングスクリプトをバージョンアップ

 拒絶ログソーティングスクリプトをバージョンアップした。
 4XXで受信拒否した記録を全部拾い、受信拒否理由を符号で示すようにした。

CClient host rejected (S25Rによるもの)
B:Client host [...] blocked (DNSBLによるもの;maps_rbl_reject_codeを4XXに設定してreject_rbl_clientを使った場合)
SSender address rejected (reject_unknown_sender_domainを使った場合)
RRecipient address rejected (reject_unknown_recipient_domainを使った場合)
HHelo command rejected (reject_unknown_helo_hostnameを使った場合)
OOther (それ以外)

だから、S25R以外に、4XXを返す受信拒否を設定している場合も、リトライしているアクセスを容易に見つけることができる。
 最近のログの表示の一例を示す。

Oct 24 17:40:10 S web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>
Oct 25 12:48:41 B web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>
Oct 27 14:10:17 B web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>

1回目は、クライアントチェックを抜けた後、reject_unknown_sender_domainで蹴られていた。2回目からはSpamCopのチェックに引っかかった。
 受信拒否理由が一目でわかるのはなかなか便利である。
 なお、reject_unknown_recipient_domainとreject_unknown_helo_hostnameは設定していないので、これによる受信拒否がちゃんと表示されることの確認まではしていない。

火曜日, 10月 07, 2014

「導入者の皆様の声」をもう一つ追加

 前回、S25R方式の導入報告と謝辞をいただいて「導入者の皆様の声」に追加したことを述べた。これがきっかけで、非常に感動的な言葉で激賞してくださった方が他にもいたことを思い出した。もう7年近くも前になるが、2008年1月9日「また激賞された」で紹介した、国島丈生さんのブログ記事「某学会メールサーバのSPAM対策」である。
 今まで「導入者の皆様の声」には、私に連絡してきて賛辞を告げてくださった方々の声を掲載しており、私に連絡することなくブログなどに綴られた賛辞まで拾い集めて掲載することはしていなかった。しかし、国島さんの感動的な言葉は、S25R方式の良さをより強くアピールするにはありがたいもので、英訳して世界に発信するにもふさわしいと考えた。また、学会へのメールはほとんど会員の職場から送られてきて、S25Rに引っかからないことがほとんどであるという条件のもとで、qmailでのグレイリスティングよりも素のS25Rの方が驚くほどの効果が得られたという事例は、貴重な情報である。
 そこで、国島さんの許可をいただいて、ブログ記事からエッセンスの言葉を残して文章を圧縮し、掲載した。

 某学会のサーバを運用しているが、メールアドレスをウェブで公開している学会の連絡先メーリングリストには、Spam throttleを使ってもなお、一日に数百通のスパムが押し寄せてきてほとほと困っていた。
 S25Rという対策を見たことがあったのを思い出し、試してみる価値はあると考えた。
 正規のメールが受け取れないケースが多発しては問題なので、まず、誤って拒否をする可能性が少ないと予想されるQgreyを導入した。かなりのスパムを排除してくれたが、すり抜けてくるスパムがそこそこあった。
 Qgreyが阻止したSMTP接続は100%スパムであった。阻止された正規のメールは一日あたり1通もない。学会にメールを送るのは圧倒的に職場からの場合が多く、したがってS25Rの拒否条件に引っかからない場合がほとんどであろう。ならば、純粋なS25R方式を導入しても大丈夫ではないか。そこで、qmailにS25Rパッチを当て、運用を開始した。パッチ中の記述は少々古かったので、最新のものに書き換えた。
 結果はというと…まさに驚異的の一語に尽きる。受け取るスパムは一日10通程度にまで激減した。13時間の間にS25Rで一時拒否したSMTP接続数は2048。実に99%以上のスパムを、受け取ることなく排除していた。この間、誤って拒否したメールは1通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。
 すり抜けてくる10通については、個別にブラックリストパターンを書くなどして対処している。10通なら、日常の仕事の合間でも充分解析作業ができる。
 こんなすごい方法を編み出した浅見秀雄さんに大感謝である。
ブログ記事(2007/12/18)の要約;掲載許諾]

土曜日, 10月 04, 2014

「導入者の皆様の声」を追加

 医療機関を統括する組織で情報システム管理者を務めている方から、S25R方式の導入報告と謝辞をいただいたので、内容を編集して「導入者の皆様の声」に掲載した(掲載文は私が作り、その方の意図どおりであることをご確認いただいている)。

 複数の医療機関を統括する組織の情報システム管理をしています。
 月20,000通ほど殺到するスパムの排除にセキュリティソフトウェアGIDEONを使っていますが、すり抜けるスパムの検体をGIDEONに登録するのが手間でした。
 S25R方式を知ってPostfixに適用したところ、80%以上のスパムをGIDEONの前段で排除でき、検体の登録の手間が減りました。しかし、ホワイトリストとブラックリストのメンテナンスが大変でした。そこで、postgreyによるグレイリスティングをS25Rに組み合わせました。その結果、運用の手間が非常に少なくなりました。
 スパムの受信は月約800通と、殺到するスパムの4%にまで減りました(この中にはGIDEONがスパムの疑いありと判定した正当なメールも含まれるので、実際のスパムはもう少し少なくなります)。医師たちからのスパム申告はほとんどなくなりました。素晴らしいアイデアを無償公開していただき、感謝しています。
 唯一困っていることは、スパム対策のために毎日1時間費やしていた仕事がほぼなくなったので、私が“暇”しているように見られていることです。

 スパム対策製品には、送信元がエンドユーザーコンピュータである可能性を逆引き名に基づいて評価するというS25R方式のアイデアを取り入れたものがあることは知っていたが、GIDEONもそうらしい。しかし、高い効果を謳うスパム対策製品を使っても、それだけではスパムによる業務効率低下の問題を十分に解決できていなかったという証言である。これは貴重な情報だと思った。
 システム管理者が楽になっただけでなく、お医者様もスパムを捨てるという無駄な仕事が減った。それでできた余裕は医療の向上に振り向けることができるだろう。私のアイデアとそれを発展させたボランティアの皆さんのアイデアが医療従事者にも貢献し、ひいては病気で苦しむ人たちを救うことにもつながると思うと感慨深い。