2003年にS25R方式の開発を始めてから2004年の発表の数年後までの時期にスパム発信の常連さんだったドメインの多くは、スパムの発信源になることがほぼなくなった。逆引きをまともに設定しているISPの多くにOP25Bが普及したからだろう。
しかし、その中でhinet.netは、相当大規模なISPにもかかわらず未だにOP25Bの導入を拒んでいると見える。5月に入ってからもこーんなにある。
May 1 14:30:42 114-45-24-226.dynamic.hinet.net
May 1 18:08:11 118-161-243-204.dynamic.hinet.net
May 3 16:17:56 118-161-243-52.dynamic.hinet.net
May 3 18:03:58 118-166-215-6.dynamic.hinet.net
May 3 18:35:41 118-161-245-200.dynamic.hinet.net
May 4 16:00:05 111-243-59-212.dynamic.hinet.net
May 5 14:39:57 118-165-146-172.dynamic.hinet.net
May 8 06:50:46 118-166-236-82.dynamic.hinet.net
May 8 16:50:42 118-166-251-85.dynamic.hinet.net
May 12 13:08:20 36-224-128-84.dynamic-ip.hinet.net
May 14 09:01:55 114-37-190-188.dynamic.hinet.net
May 15 15:54:46 111-243-60-50.dynamic.hinet.net
May 18 09:40:41 114-43-245-162.dynamic.hinet.net
May 19 02:39:04 1-160-126-37.dynamic.hinet.net
May 19 06:18:22 36-225-28-13.dynamic-ip.hinet.net
なぜかここのところ、hinet.netからはことごとく第三者中継を目論むアクセスなのだが、正しいアドレスに宛てたスパムだろうと、S25Rに引っかかるから全然やっかいではない。かつて私は、「受信側対策としてのS25Rがあれば、送信側対策としてのOP25Bはやってくれなくても全然かまわない」と思っていた。
しかし今は、OP25Bの普及はつくづくありがたいと思っている。スパムアクセスの総数が非常に減ったからという理由もあるが、最も大きな理由は、「動的IPアドレスのメールサーバの存在を無視するS25Rはけしからん」という批判ができなくなったことである。「正当なメールは、送信側エンドユーザーコンピュータ（特に動的IPアドレスのもの）からは受信側メールサーバへ直送せず、送信側メールサーバで中継する」という具合にメール配送ルートに秩序を持たせるというコンセプトにおいて、S25RとOP25Bには共通性があるのである。
火曜日, 5月 19, 2015
こんなドメインあるんだねえ
2015年4月24日に、第三者中継を目論むこんなアクセスがあった。
Apr 24 09:16:49 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:51 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:52 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
euは欧州連合の国ドメインである。トップレベルドメインの直下がIPアドレスの上位3オクテットをそのまま反映したドメイン名になっているなんて初めて見た。
第三者中継はS25Rチェックよりも先にチェックするように設定しているので「Relay access denied」で蹴っているが、この送信元の逆引きFQDNは一般規則のルール4に引っかかる。ルール3はsmtp.246.ne.jp（実在）を蹴らないように、ルール5はmail1.number1.co.jp（ホスト名は架空、ドメイン名は実在）を蹴らないように上位3階層を検査から除外するようにしていて、ルール4もmail1.1-2-3.co.jp（ホスト名は架空、ドメイン名は実在）を蹴らないようにしようかと検討したのだが、wbar9.chi1-4-11-085-222.dsl-verizon.netやm226.net81-66-158.noos.fr（2003年のS25R開発時に発見されたスパム送信元の実例）を蹴れるように、ルール4についてはその偽陽性回避策を採らなかったからである。
Apr 24 09:16:49 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:51 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
Apr 24 09:16:52 reject: RCPT from ip98.ip-5-135-192.eu[5.135.192.98]: 554 5.7.1 <***@gmail.com>: Relay access denied; …
euは欧州連合の国ドメインである。トップレベルドメインの直下がIPアドレスの上位3オクテットをそのまま反映したドメイン名になっているなんて初めて見た。
第三者中継はS25Rチェックよりも先にチェックするように設定しているので「Relay access denied」で蹴っているが、この送信元の逆引きFQDNは一般規則のルール4に引っかかる。ルール3はsmtp.246.ne.jp（実在）を蹴らないように、ルール5はmail1.number1.co.jp（ホスト名は架空、ドメイン名は実在）を蹴らないように上位3階層を検査から除外するようにしていて、ルール4もmail1.1-2-3.co.jp（ホスト名は架空、ドメイン名は実在）を蹴らないようにしようかと検討したのだが、wbar9.chi1-4-11-085-222.dsl-verizon.netやm226.net81-66-158.noos.fr（2003年のS25R開発時に発見されたスパム送信元の実例）を蹴れるように、ルール4についてはその偽陽性回避策を採らなかったからである。
本文チェックによるブロックに成功
本文に共通点のあるスパムが最近4件着信していた。日付、送信元、サブジェクトを示す。
2015/04/03 july.7819888.com "we can bring you buyers"
2015/04/09 rain.828873.com "need pics retouching?"
2015/04/16 pizza.89mt.com "need email marketing?"
2015/05/06 boo.bianmingdai.com "find new customers"
本文の共通性というのは、
Contact: ***@aliyun.com
または
Email: ***@aliyun.com
という文が入っていることである。メールアドレスのユーザー名は毎回違っていたが、aliyun.comは一定。これはスパマーがコンタクトを受けるためのドメインだと推測した。ユーザー名をいくつでも用意するのは簡単だろうが、ドメインはそうそういくつも用意できないだろう。そこで、body_checksに
/@aliyun\.com/ REJECT
と設定していた。
これで5月15日に1件、送信元chu.0530ok.comからのスパムのブロックに成功していた。送信者アドレスのドメインはyahoo.comで、送信元はyahoo.comのSPFと一致しないので、蹴飛ばして問題なかっただろう。
なお、4月11日の記事にも書いたとおり、このようなブロッキングは、個人サイトか、ユーザー全員の了解を得ることができる小規模サイトでなければお勧めしない。私がこれを書いているのは、あくまでも自分の活動日誌として、また、閲覧者への単なる参考のためである。対策なしでは一日200通ほどのスパムを受けていた人も、S25Rによってスパムの受信は一日数通（グレイリスティングなどで偽陽性判定からの自動救済をしていてもおそらく10通程度）と、仕事を邪魔されない程度にまではなっているはずだから、業務でメールシステム管理をしている人は、こんな趣味的なブロッキングにうつつを抜かすべきではない。
2015/04/03 july.7819888.com "we can bring you buyers"
2015/04/09 rain.828873.com "need pics retouching?"
2015/04/16 pizza.89mt.com "need email marketing?"
2015/05/06 boo.bianmingdai.com "find new customers"
本文の共通性というのは、
Contact: ***@aliyun.com
または
Email: ***@aliyun.com
という文が入っていることである。メールアドレスのユーザー名は毎回違っていたが、aliyun.comは一定。これはスパマーがコンタクトを受けるためのドメインだと推測した。ユーザー名をいくつでも用意するのは簡単だろうが、ドメインはそうそういくつも用意できないだろう。そこで、body_checksに
/@aliyun\.com/ REJECT
と設定していた。
これで5月15日に1件、送信元chu.0530ok.comからのスパムのブロックに成功していた。送信者アドレスのドメインはyahoo.comで、送信元はyahoo.comのSPFと一致しないので、蹴飛ばして問題なかっただろう。
なお、4月11日の記事にも書いたとおり、このようなブロッキングは、個人サイトか、ユーザー全員の了解を得ることができる小規模サイトでなければお勧めしない。私がこれを書いているのは、あくまでも自分の活動日誌として、また、閲覧者への単なる参考のためである。対策なしでは一日200通ほどのスパムを受けていた人も、S25Rによってスパムの受信は一日数通（グレイリスティングなどで偽陽性判定からの自動救済をしていてもおそらく10通程度）と、仕事を邪魔されない程度にまではなっているはずだから、業務でメールシステム管理をしている人は、こんな趣味的なブロッキングにうつつを抜かすべきではない。
火曜日, 5月 12, 2015
サブジェクトでの拒否が突き抜けられた
4月11日の記事で
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
という拒否条件を設定したことを述べたが、今日（5月12日）、「image solutions」というサブジェクトで突き抜けられた（送信元はlondon.weisim.net）。拒否条件を次のように変更した。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out|solution)/ REJECT
今回は「solutions」と複数形だったが、単数形でも引っかかるようにした。もちろん、後続の文字の条件は指定していないので複数形でも引っかかる。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
という拒否条件を設定したことを述べたが、今日（5月12日）、「image solutions」というサブジェクトで突き抜けられた（送信元はlondon.weisim.net）。拒否条件を次のように変更した。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out|solution)/ REJECT
今回は「solutions」と複数形だったが、単数形でも引っかかるようにした。もちろん、後続の文字の条件は指定していないので複数形でも引っかかる。
日曜日, 5月 03, 2015
迷惑電話対策
迷惑メールでなく迷惑電話の話。
我が家の固定電話に、出たらすぐに切れてしまうという変な電話がかかってくることが時々あった。かつて使っていたISDNとは違って、ひかり電話では発信番号通知がデフォルトではないので、追加で契約した。
出たらすぐに切れてしまうのは番号非通知のコールだとわかった。電話機に「ヒツウチ」と表示された時にはほったらかしてみたら、決まって呼び出し音10回で切れた。何のためにかけてくるのか、わけわからん。
電話機に、番号非通知のコールに対して「番号を通知してかけ直せ」とアナウンスを返して切る機能があったので、ナンバーリクエストサービスを追加契約しなくても対策ができた。reject_unknown_clientのようなものだな。ちょっと違うけど。
ひかりルータのログを見ると、番号非通知のコールは2014年12月に2回、2015年1月に1回、2月に1回、3月に9回、4月に2回あった。最も新しい記録は4月25日である。敵はまだあきらめてはいないものと見える。
それで思い出したのだが、NTTの発信番号通知サービスの開始がアナウンスされたころ、タモリさんがラジオ番組で「かけ手側では番号の通知を（184をダイヤルして）拒否できる？でも受け手側では番号非通知の電話を拒否できる？わけわからん」という意味のことを言っていた。一見相対立するポリシーだが、かけ手が悩み事相談などで自分のプライバシーを守りたい時には番号通知を拒否できるし、受け手が「いのちの電話」や事業者ならば番号非通知のコールも拒否しない、一方、一般家庭では身元を隠すかけ手からのコールを拒否したいと思えばできるということである。ユーザーのポリシーで選択できるということで、それは言い換えれば、ユーザーは自分のために最も良いサービスの選択を自分で判断しなければならない、選択の自由度が高まれば選択の責任は自分が負うということである。今は広く理解されていることだと思うが、当初は一般ユーザーにはなかなか理解しにくかったようである。
我が家の固定電話に、出たらすぐに切れてしまうという変な電話がかかってくることが時々あった。かつて使っていたISDNとは違って、ひかり電話では発信番号通知がデフォルトではないので、追加で契約した。
出たらすぐに切れてしまうのは番号非通知のコールだとわかった。電話機に「ヒツウチ」と表示された時にはほったらかしてみたら、決まって呼び出し音10回で切れた。何のためにかけてくるのか、わけわからん。
電話機に、番号非通知のコールに対して「番号を通知してかけ直せ」とアナウンスを返して切る機能があったので、ナンバーリクエストサービスを追加契約しなくても対策ができた。reject_unknown_clientのようなものだな。ちょっと違うけど。
ひかりルータのログを見ると、番号非通知のコールは2014年12月に2回、2015年1月に1回、2月に1回、3月に9回、4月に2回あった。最も新しい記録は4月25日である。敵はまだあきらめてはいないものと見える。
それで思い出したのだが、NTTの発信番号通知サービスの開始がアナウンスされたころ、タモリさんがラジオ番組で「かけ手側では番号の通知を（184をダイヤルして）拒否できる？でも受け手側では番号非通知の電話を拒否できる？わけわからん」という意味のことを言っていた。一見相対立するポリシーだが、かけ手が悩み事相談などで自分のプライバシーを守りたい時には番号通知を拒否できるし、受け手が「いのちの電話」や事業者ならば番号非通知のコールも拒否しない、一方、一般家庭では身元を隠すかけ手からのコールを拒否したいと思えばできるということである。ユーザーのポリシーで選択できるということで、それは言い換えれば、ユーザーは自分のために最も良いサービスの選択を自分で判断しなければならない、選択の自由度が高まれば選択の責任は自分が負うということである。今は広く理解されていることだと思うが、当初は一般ユーザーにはなかなか理解しにくかったようである。
金曜日, 5月 01, 2015
サブジェクトで拒否＆数字だけのサイトドメイン名――続編
前回、サブジェクトの拒否条件を紹介した。header_checksに設定している条件は次のとおり。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
これでまた成果があった。日付、送信元ホスト、サブジェクトを示す。
2015/04/29 beijing.china-fxcm.com "pics editing solutions"
これの前の4月9日に着信したスパムのサブジェクトは「need pics retouching?」だったのだが、さらに語を変えてきたのをうまく撃退できた。
それと、4月16日に「need email marketing?」というサブジェクトのスパムがpizza.89mt.comから着信したので、header_checksに
/Subject: .*email +marketing/ REJECT
を加えておいたら、4月20日に「email marketing」というサブジェクトのスパム（送信元はkim.dq95.com）をブロックできた。その後、「email」を「e-mail」と変えてきてもブロックできるように、
/Subject: .*e-?mail +marketing/ REJECT
と変更している。
数字だけのサイトドメイン名に対する警戒策の成果は、その後2件あった。拒絶ログソーティングスクリプトの表示形式で示す。いずれもリトライはなかった。
Apr 21 23:52:10 C yamoy.9001888.com [178.251.230.21] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<yamoy.9001888.com>
Apr 23 19:36:16 C gonna.135328.com [198.144.181.6] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<gonna.135328.com>
その後、拒否条件を次のように変更している。
/\.[0-9]+\.(com|net)$/ 450 domain check, be patient
↓
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
理由は、ニッポン放送の1242.comのような真っ当なドメインはあるが（これはメール用であって逆引き名には使われていないかもしれないけれども）、スパムを送ってきた数字だけのサイトドメイン名はいずれも数字5桁以上であること、サイトドメイン名が数字で始まって数字が5桁以上続いたら、あとは英字が含まれていても不自然な名前として警戒してよいだろうと考えたこと、それと、末端ホスト名が省略された逆引き名であっても引っかけようと考えたからである。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
これでまた成果があった。日付、送信元ホスト、サブジェクトを示す。
2015/04/29 beijing.china-fxcm.com "pics editing solutions"
これの前の4月9日に着信したスパムのサブジェクトは「need pics retouching?」だったのだが、さらに語を変えてきたのをうまく撃退できた。
それと、4月16日に「need email marketing?」というサブジェクトのスパムがpizza.89mt.comから着信したので、header_checksに
/Subject: .*email +marketing/ REJECT
を加えておいたら、4月20日に「email marketing」というサブジェクトのスパム（送信元はkim.dq95.com）をブロックできた。その後、「email」を「e-mail」と変えてきてもブロックできるように、
/Subject: .*e-?mail +marketing/ REJECT
と変更している。
数字だけのサイトドメイン名に対する警戒策の成果は、その後2件あった。拒絶ログソーティングスクリプトの表示形式で示す。いずれもリトライはなかった。
Apr 21 23:52:10 C yamoy.9001888.com [178.251.230.21] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<yamoy.9001888.com>
Apr 23 19:36:16 C gonna.135328.com [198.144.181.6] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<gonna.135328.com>
その後、拒否条件を次のように変更している。
/\.[0-9]+\.(com|net)$/ 450 domain check, be patient
↓
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
理由は、ニッポン放送の1242.comのような真っ当なドメインはあるが（これはメール用であって逆引き名には使われていないかもしれないけれども）、スパムを送ってきた数字だけのサイトドメイン名はいずれも数字5桁以上であること、サイトドメイン名が数字で始まって数字が5桁以上続いたら、あとは英字が含まれていても不自然な名前として警戒してよいだろうと考えたこと、それと、末端ホスト名が省略された逆引き名であっても引っかけようと考えたからである。
土曜日, 4月 11, 2015
似たスパムをサブジェクトで拒否＆数字だけのサイトドメイン名のチェック
2013年以来、内容のよく似た英語のスパムが何度も着信している。送信元の逆引き名の多くはS25Rに引っかからない。ボットでなくメールサーバらしい。リトライを発見して許可してみたらスパムだったというものもある。
日付、送信元、サブジェクトは以下のとおり。サブジェクトが同じものの重複は省略している。
2013/05/06 mail.keremara.co.ke "Photo Retouching Services - Photo Cut Out - Photo Editing"
2014/07/15 miweier.net "Photo Retouching Services - Photo Editing - Photo Cutout"
2014/07/15 sangshuang.com "Photo Retouching Services - Photo Cut Out - Photo Masking"
2014/10/03 okbad.org "Photo Editing Services - Photo Cut Out - Photo Retouching"
2014/12/18 sichuan.top188.net "image editing services"
2015/01/22 air.hsntdhv.com "photo clipping path"
2015/01/22 blue.eejjbmn.com "photo cutout service"
2015/02/03 dallas.sbvqbwk.com "introducing our photo retouching"
2015/02/20 rvnrfck.com "just introducing our photo retouching"
2015/03/21 coco.27838.net "need photo clipping path and retouching?"
2015/03/24 fave.taodazhong.com "Are you interested in photo retouching?"
2015/04/09 rain.828873.com "need pics retouching?"
送信元ホストはばらばらなので、サブジェクトに基づく拒否を設定した。そうしたら敵は少しずつ語を変えて送り込んできたので、こちらもだんだん網を広げた。それで何度かブロックに成功した。4月9日には、「photo」や「image」に概念が共通している「pics」という語を使ってきたので、「pic」と、まだ来ていない「picture」も加え、さらにそれらに複数語尾「s」が付くか否かにかかわらず引っかけるようにした。header_checksに現在設定している条件は次のとおり。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
これで真っ当なメールを恒久的受信拒否してしまうおそれは皆無ではないので、個人サイトか、ユーザー全員の了解を得ることができる小規模サイトでなければ、この設定はお勧めしない。
もう一つ、coco.27838.netおよびrain.828873.comという送信元ホストに着目。数字だけのサイトドメイン名は、スパマーがスパム送信のために多数取得するドメインである可能性が高いと推測し、S25R拒否条件ファイル（/etc/postfix/rejections）に以下を加えた。
/\.[0-9]+\.(com|net)$/ 450 domain check, be patient
この形の真っ当なドメインとして思い出すのは、1242kHzのAMラジオのニッポン放送のドメイン1242.comであるが、そのMXはmailav.jolf.jp（JOLFはニッポン放送のコールサイン）。送信サーバもこれだとすれば問題ない。もし引っかかっても、一時的受信拒否だから救済可能。許可条件は、拒否条件ファイルの中でこれの直前に書くのがわかりやすいと思う。
これで新たな怪しいホストが引っかかった。以下は拒絶ログソーティングスクリプトによる表示。
Apr 10 22:41:22 C west.488859.com [107.179.86.53] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<west.488859.com>
Apr 11 00:32:20 〃
Apr 11 02:25:09 〃
Apr 11 03:01:52 〃
Apr 11 03:25:15 〃
Apr 11 04:01:55 〃
リトライは6時間未満で止まっていた。善良な送信者がメーラーで送信したメールならメールサーバが24時間未満でリトライをやめることはまずないので、放っておけばいいだろう。
日付、送信元、サブジェクトは以下のとおり。サブジェクトが同じものの重複は省略している。
2013/05/06 mail.keremara.co.ke "Photo Retouching Services - Photo Cut Out - Photo Editing"
2014/07/15 miweier.net "Photo Retouching Services - Photo Editing - Photo Cutout"
2014/07/15 sangshuang.com "Photo Retouching Services - Photo Cut Out - Photo Masking"
2014/10/03 okbad.org "Photo Editing Services - Photo Cut Out - Photo Retouching"
2014/12/18 sichuan.top188.net "image editing services"
2015/01/22 air.hsntdhv.com "photo clipping path"
2015/01/22 blue.eejjbmn.com "photo cutout service"
2015/02/03 dallas.sbvqbwk.com "introducing our photo retouching"
2015/02/20 rvnrfck.com "just introducing our photo retouching"
2015/03/21 coco.27838.net "need photo clipping path and retouching?"
2015/03/24 fave.taodazhong.com "Are you interested in photo retouching?"
2015/04/09 rain.828873.com "need pics retouching?"
送信元ホストはばらばらなので、サブジェクトに基づく拒否を設定した。そうしたら敵は少しずつ語を変えて送り込んできたので、こちらもだんだん網を広げた。それで何度かブロックに成功した。4月9日には、「photo」や「image」に概念が共通している「pics」という語を使ってきたので、「pic」と、まだ来ていない「picture」も加え、さらにそれらに複数語尾「s」が付くか否かにかかわらず引っかけるようにした。header_checksに現在設定している条件は次のとおり。
/Subject: .*(photo|image|pic|picture)s? +(retouching|editing|clipping|cut ?out)/ REJECT
これで真っ当なメールを恒久的受信拒否してしまうおそれは皆無ではないので、個人サイトか、ユーザー全員の了解を得ることができる小規模サイトでなければ、この設定はお勧めしない。
もう一つ、coco.27838.netおよびrain.828873.comという送信元ホストに着目。数字だけのサイトドメイン名は、スパマーがスパム送信のために多数取得するドメインである可能性が高いと推測し、S25R拒否条件ファイル（/etc/postfix/rejections）に以下を加えた。
/\.[0-9]+\.(com|net)$/ 450 domain check, be patient
この形の真っ当なドメインとして思い出すのは、1242kHzのAMラジオのニッポン放送のドメイン1242.comであるが、そのMXはmailav.jolf.jp（JOLFはニッポン放送のコールサイン）。送信サーバもこれだとすれば問題ない。もし引っかかっても、一時的受信拒否だから救済可能。許可条件は、拒否条件ファイルの中でこれの直前に書くのがわかりやすいと思う。
これで新たな怪しいホストが引っかかった。以下は拒絶ログソーティングスクリプトによる表示。
Apr 10 22:41:22 C west.488859.com [107.179.86.53] from=<***@mail.com> to=<***@gabacho-net.jp> helo=<west.488859.com>
Apr 11 00:32:20 〃
Apr 11 02:25:09 〃
Apr 11 03:01:52 〃
Apr 11 03:25:15 〃
Apr 11 04:01:55 〃
リトライは6時間未満で止まっていた。善良な送信者がメーラーで送信したメールならメールサーバが24時間未満でリトライをやめることはまずないので、放っておけばいいだろう。
土曜日, 2月 28, 2015
拒絶ログソーティングスクリプトの改造と公表はご自由に
ロシアの方から、拒絶ログソーティングスクリプトの改良の提案をいただいた。
「ご提案ありがとうございます。私の拒絶ログソーティングスクリプトは、私のシステム環境と私のニーズに合うように（様々なシステム環境やニーズを考慮せずに）、また、スキルフルでないメールシステム管理者にとって利用や改造がしやすいように作ってあります。私はこのスクリプトの著作権を主張しません。あなたの利便性のために改造すること、あなたの改造を公表することはご遠慮なくなさってください。」
- Suppress_single_access_recordsオプションをスクリプトの先頭に移動する。
- トランスペアレントログファイルの復元機能を加える。
- プログラム名AWKでコンフィグレーション可能にする。
- リトライの同一レコードを抑止するSuppress_duplicate_recordsオプションを加える。
「ご提案ありがとうございます。私の拒絶ログソーティングスクリプトは、私のシステム環境と私のニーズに合うように（様々なシステム環境やニーズを考慮せずに）、また、スキルフルでないメールシステム管理者にとって利用や改造がしやすいように作ってあります。私はこのスクリプトの著作権を主張しません。あなたの利便性のために改造すること、あなたの改造を公表することはご遠慮なくなさってください。」
木曜日, 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ヘッダがあることをもってそれを見破ることができるので、その方法も説明している。しかし、過去のメールやよそから得たメールを返信操作で引用した新規トピックが即時配信されなくなるので、意図的にポリシーに反することをしない善人ばかりのメーリングリストでは、そこまではしない方がよいと思う。
需要が多いとは思わないが、このような半モデレートのポリシーというものもメーリングリストによっては便利なことがあるというアイデアの紹介のつもりでコンテンツを掲載した。
私は、ある研究会のためにボランティアでメーリングリストを運用している。かつてはメーリングリストで議論も行われていたが、そのようなメールの受信を歓迎する会員ばかりではないので、議論は掲示板でやってもらい、メーリングリストの用途は原則として、事務局からの通達や会合案内、会員からの挨拶や情報提供や議論の開始・経過・結果報告などに限ることにした。
それでも、会合案内に対する出欠回答（他の会員にとっては無駄な情報）をメーリングリストに同報してしまう人や、添付ファイルは投稿しないように（サーバの過負荷や受信者の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導入サイトから言ってこられた時には公開ホワイトリストに掲載する。
昨日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
# 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
日本に恫喝外交を仕掛けてくる国に対して譲歩で丸く収めようとした外交姿勢は、要求のさらなるエスカレートという結果を生んだ。毅然とした外交姿勢をとったら、ある国はこれ以上押せないと気付いた様子を見せ始め、ある国は反日政策の自縄自縛でどうしようもない自国不利の状況に陥り始めている。スパム対策での「受けたふり」と「毅然と拒否」のポリシーの違いは、そういう外交問題を彷彿とさせる。
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の表記形式だったら誤動作してしまう。なので、「]:」を探すようにした。
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の偽陽性判定が問題になるかもしれないので、もっちーさんが投稿してくださった設定方法の情報を紹介する。
確かに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」である。あえてスパムと書かずに未承諾広告メールと書いたのは、送信者アドレスを偽った卑劣なスパムとは違うと思ったからだが、送信者は合法のつもりでも違法な「特定電子メール」（自己又は他人の営業につき広告又は宣伝を行うための手段として送信をする電子メール）である。
慇懃かつ脅しを効かせたメールを送った。
詫び状が来た。それによれば、インターネットで集めた私のアドレスを歯科医療関係者だと勘違いしたとのことだが、ほんとかいな。私の知らない人で、私に初めてメールを送ってくる時に私の個人アドレスに宛てるのは、私の所有ドメインに関する用件のためにwhoisでアドレスを知った人だけのはずで、さもなければスパマーしかいない。
on9mail.comとはどういうサービスなのかよくわからない。「未承諾広告メールの送信請け負います」の事業者なんだろうか。名前の意味もよくわからん。「on9」というのは広東語で「馬鹿」というスラングらしいのだが。
参考までに、「特定電子メールの送信の適正化に関する法律」第三条の条文は次のとおり。
第三条 送信者は、次に掲げる者以外の者に対し、特定電子メールの送信をしてはならない。
一 あらかじめ、特定電子メールの送信をするように求める旨又は送信をすることに同意する旨を送信者又は送信委託者（電子メールの送信を委託した者（営利を目的とする団体及び営業を営む場合における個人に限る。）をいう。以下同じ。）に対し通知した者
二 前号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを送信者又は送信委託者に対し通知した者
三 前二号に掲げるもののほか、当該特定電子メールを手段とする広告又は宣伝に係る営業を営む者と取引関係にある者
四 前三号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを公表している団体又は個人（個人にあっては、営業を営む者に限る。）
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が通信を遮断したためらしい」と書いていた。同じようなことがあったのかもしれない。
こんなことがあると、メールサーバに異常が起こったのではないかと心配になってしまう。でも、メールマガジンなどはちゃんと着信しているし、今日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.」につなげてウェブを見たら、ドイツ国内のサイトだった。ドイツ語は読めないんだが（大学で履修した第二外国語はフランス語だった）、なんとか見当を付けて連絡フォームに書き込んでから、その人に返信した。
前にもこんなことあったっけと思い出した。2011年4月4日「ドイツでのS25R設定にベルギーから苦情」に書いていた。その時も、申告者からの「解決した」「なおも解決しない」という報告も、宛先サイトからの「対処した」という報告もなかった。その時のサイトとは、今回はまた別のサイトだった。
日本人ならたいてい、「解決した」「対処した」という連絡をくれる。S25Rの間違った運用（リトライの放置）のせいで手間をかけさせられたのに「親切に対応してくれてありがとう」と謝辞をくださった人さえいた。これが日本の美徳だと思う。数少ない体験から他国の国民性をうんぬんすべきではないとわかってはいるが、こういうものなのかなと思ってしまう。もちろん、ドイツ車などから感じられるドイツ人の職人気質（日本の職人気質も相当誇らしいものだが）には尊敬の念を持っているし、どこの国にもいる「日本の文化好き」と言ってくれる外国人にはとても親しみと感謝の念が湧くのではあるが。
「『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で受信拒否した記録を全部拾い、受信拒否理由を符号で示すようにした。
C：Client host rejected （S25Rによるもの）
B：Client host [...] blocked （DNSBLによるもの；maps_rbl_reject_codeを4XXに設定してreject_rbl_clientを使った場合）
S：Sender address rejected （reject_unknown_sender_domainを使った場合）
R：Recipient address rejected （reject_unknown_recipient_domainを使った場合）
H：Helo command rejected （reject_unknown_helo_hostnameを使った場合）
O：Other （それ以外）
だから、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は設定していないので、これによる受信拒否がちゃんと表示されることの確認まではしていない。
4XXで受信拒否した記録を全部拾い、受信拒否理由を符号で示すようにした。
C：Client host rejected （S25Rによるもの）
B：Client host [...] blocked （DNSBLによるもの；maps_rbl_reject_codeを4XXに設定してreject_rbl_clientを使った場合）
S：Sender address rejected （reject_unknown_sender_domainを使った場合）
R：Recipient address rejected （reject_unknown_recipient_domainを使った場合）
H：Helo command rejected （reject_unknown_helo_hostnameを使った場合）
O：Other （それ以外）
だから、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の方が驚くほどの効果が得られたという事例は、貴重な情報である。
そこで、国島さんの許可をいただいて、ブログ記事からエッセンスの言葉を残して文章を圧縮し、掲載した。
今まで「導入者の皆様の声」には、私に連絡してきて賛辞を告げてくださった方々の声を掲載しており、私に連絡することなくブログなどに綴られた賛辞まで拾い集めて掲載することはしていなかった。しかし、国島さんの感動的な言葉は、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方式の導入報告と謝辞をいただいたので、内容を編集して「導入者の皆様の声」に掲載した（掲載文は私が作り、その方の意図どおりであることをご確認いただいている）。
スパム対策製品には、送信元がエンドユーザーコンピュータである可能性を逆引き名に基づいて評価するというS25R方式のアイデアを取り入れたものがあることは知っていたが、GIDEONもそうらしい。しかし、高い効果を謳うスパム対策製品を使っても、それだけではスパムによる業務効率低下の問題を十分に解決できていなかったという証言である。これは貴重な情報だと思った。
システム管理者が楽になっただけでなく、お医者様もスパムを捨てるという無駄な仕事が減った。それでできた余裕は医療の向上に振り向けることができるだろう。私のアイデアとそれを発展させたボランティアの皆さんのアイデアが医療従事者にも貢献し、ひいては病気で苦しむ人たちを救うことにもつながると思うと感慨深い。
| 複数の医療機関を統括する組織の情報システム管理をしています。 月20,000通ほど殺到するスパムの排除にセキュリティソフトウェアGIDEONを使っていますが、すり抜けるスパムの検体をGIDEONに登録するのが手間でした。 S25R方式を知ってPostfixに適用したところ、80%以上のスパムをGIDEONの前段で排除でき、検体の登録の手間が減りました。しかし、ホワイトリストとブラックリストのメンテナンスが大変でした。そこで、postgreyによるグレイリスティングをS25Rに組み合わせました。その結果、運用の手間が非常に少なくなりました。 スパムの受信は月約800通と、殺到するスパムの4%にまで減りました（この中にはGIDEONがスパムの疑いありと判定した正当なメールも含まれるので、実際のスパムはもう少し少なくなります）。医師たちからのスパム申告はほとんどなくなりました。素晴らしいアイデアを無償公開していただき、感謝しています。 唯一困っていることは、スパム対策のために毎日1時間費やしていた仕事がほぼなくなったので、私が“暇”しているように見られていることです。 |
スパム対策製品には、送信元がエンドユーザーコンピュータである可能性を逆引き名に基づいて評価するというS25R方式のアイデアを取り入れたものがあることは知っていたが、GIDEONもそうらしい。しかし、高い効果を謳うスパム対策製品を使っても、それだけではスパムによる業務効率低下の問題を十分に解決できていなかったという証言である。これは貴重な情報だと思った。
システム管理者が楽になっただけでなく、お医者様もスパムを捨てるという無駄な仕事が減った。それでできた余裕は医療の向上に振り向けることができるだろう。私のアイデアとそれを発展させたボランティアの皆さんのアイデアが医療従事者にも貢献し、ひいては病気で苦しむ人たちを救うことにもつながると思うと感慨深い。
登録:
投稿 (Atom)