木曜日, 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もそうらしい。しかし、高い効果を謳うスパム対策製品を使っても、それだけではスパムによる業務効率低下の問題を十分に解決できていなかったという証言である。これは貴重な情報だと思った。
 システム管理者が楽になっただけでなく、お医者様もスパムを捨てるという無駄な仕事が減った。それでできた余裕は医療の向上に振り向けることができるだろう。私のアイデアとそれを発展させたボランティアの皆さんのアイデアが医療従事者にも貢献し、ひいては病気で苦しむ人たちを救うことにもつながると思うと感慨深い。

土曜日, 11月 16, 2013

SpamCopによる偽陽性判定が発生

 2009年4月29日の「SpamCopを設定してみた」で説明した方法で、S25RにSpamCopを併用するようにして以来、最近までSpamCopによる偽陽性判定を経験したことはなかった。ところが先日、ついに偽陽性判定が起こった。
 11月10日、兄からのメール(メールドメインはcatv296.ne.jp)を送信するメールサーバmail05.SiriusCloud.jpがSpamCopによる偽陽性判定でブロックされていた。誰かがこのメールサーバを利用してスパムを撒いたのだろう。maps_rbl_reject_codeを450に設定していたので、再送が続いているうちにローカルのホワイトリストに登録して受信できた。
 ブラックリスト入りしたのはこの一つのメールサーバだけではなく、周辺のIPアドレスも同時に登録されていた。11月11日にはmail02.SiriusCloud.jpもブロックされた。ホワイトリストを範囲指定に直して受信した。
 経験上、SpamCopは、DNSBLとしてはそこそこ信頼できる。しかし、正当なメールサーバの利用者がスパムを撒いて、それがSpamCopに通報されることもある。そうなると、maps_rbl_reject_codeをデフォルトの554のままにしていた場合、正当なメールが即座にエラーリターンして、善良な送信者と受信者が迷惑を被ってしまう。やはり、maps_rbl_reject_codeを450に変更して再送要求を返し、再送を監視することは必須である。

 ところで、SpamCopのブラックリスト登録は、ある程度の時間で自動的に解除される。そのため、まともなメールサーバを使って撒かれたスパムは、しばらくSpamCopによってブロックされても、再送期間(Postfixやsendmailのデフォルト設定で5日)が終わらないうちにブラックリスト登録が解除されると、受信されてしまう。実際、それでスパムが受信されてしまったことがあった。
 11月14日15:17に始まったaircel-mx1.aircelservices.inからのアクセスがSpamCopでブロックされ、その後再送が続いていた。送信者アドレスが怪しげで、スパムに違いないと判断したので、smtpd_sender_restrictionsパラメータのcheck_sender_access指定で指定したファイルに送信者アドレスを登録することにより、ブラックリスト登録が解除された時に送信者アドレス条件で蹴るようにした。11月16日03:39に拒絶に成功した。
 smtpd_client_restrictionsの条件がsmtpd_sender_restrictionsの条件よりも先に評価されるので、送信者アドレス条件を設定しても、SpamCopに引っかかっている間は再送要求を返し続ける。ログが膨らんでうざったい。しかし、運用手順が単純であることと、同じメールサーバからの他の正当なメールのエラーリターンを避けられることから、この方法が良いと思う。

日曜日, 8月 05, 2012

情報リテラシーを向上させるには

 前回、こう書いた。
 「spf=pass」「dkim=pass」の表示に安心してしまう癖が付くのはかえって危険である。なりすましメールにだまされないためには、送信ドメイン認証の普及よりも、偽情報を見破る情報リテラシーをみんなが持つことの方が重要である。
これに対しては、「個々人の情報リテラシーに頼るには限界がある」という反論があるだろう。しかし私は、「インターネットの危険性をよく知らない素人さんの情報リテラシーを向上させるには、プロがそれぞれの立場でできることがある」と主張したい。
 私はかつて、勤務先のポストマスターを務めていた。2000年に当社のドメインをかたったスパムが発生し、世界からたくさんの苦情メールが殺到した。私はすべてに返事を書いた。「その送信者アドレスは偽造です。当社はスパムを送信していません。そのReceivedヘッダが証拠です」。2001年以降には、当社のドメインをかたったスパムが相変わらず発生していたにもかかわらず、苦情は一件も来なくなった。2000年中に世界中のスパム被害者が、スパムの送信者アドレスを真に受けてはならないと知ったのである。つまり、その点において情報リテラシーが向上したということである。
 自社からのダイレクトメールを受信する顧客がなりすましメールにだまされないようにしたいと思う企業は、次のようにするとよい。
 ダイレクトメールに時折注意喚起を記載する。
なりすましメールにご注意を!必ずお読みください。
http://www.***.co.jp/narisumashi-gochuui.html
 そして、ウェブページでは、Receivedヘッダの読み方を説明するとともに、以下のように記載する。
ご注意
●弊社からは、電子メールでパスワードの変更をお願いすることはございません。
●弊社からのご案内メールにファイルを添付することはございません。
●弊社からのご案内メールでは、 www.***.co.jp 以外のウェブサイトのURLを記載することはございません。
●弊社の業務に関して他社(関連会社等)からご案内メールを差し上げることはございません。
●・・・
 不審に思われましたら、
●弊社を名乗るメールの差出人アドレスが弊社のドメイン ***.co.jp であるかどうかをご確認ください(紛らわしいドメインである場合もあり得ます)。別のドメインであれば、なりすましメールと考えられます。
●Receivedヘッダを見て、お客様のドメインのメールサーバへ送信した弊社のメールサーバが dm数字.***.co.jp であるかどうかをご確認ください。別のメールサーバ名であれば、なりすましメールと考えられます。
 ご不明の点があれば、下記のお問い合わせフォームからお問い合わせください。
https://www.***.co.jp/cgi-bin/otoiawase.cgi
 顧客にこのように説明すれば、顧客は、自サイトでSPFチェックやDKIMチェックを行っていなくても、また、SPFやDKIMでチェックアウトできないなりすましメールであっても見破る情報リテラシーを身に付けることができるだろう。

土曜日, 8月 04, 2012

送信ドメイン認証は誰にとって有益か

 送信ドメイン認証は、スパム(迷惑メール)対策という言葉と共に語られている。だから、かつて私は、送信ドメイン認証はスパム対策の一つだと思っていた。今にして思えば恥ずかしい間違いであった。
 送信ドメイン認証は、スパムのうちの一部にすぎないなりすましメール(単に実在の送信ドメインをかたっているスパムという意味でなく、特定の組織や個人をかたって受信者をだまそうとするメール)に対する対抗策である。ボットから大量に送信されているスパムの受信を劇的に減らせるわけではない。ドメインの詐称ができなくなればスパムは少しは減るかもしれないが、使い捨てドメインを使ったスパムは送信ドメイン認証をパスできてしまう。S25R方式やグレイリスティングほどにはスパムの受信を減らすことはできない。送信ドメイン認証を導入しても、相変わらずたくさんのスパムが受信される。ただ、まともに見えるメールが実はなりすましメールかもしれないと判断できる手段が得られるだけのことである。
 送信ドメイン認証は無益だとは言えない。たとえば、私が契約しているSBIネット銀行(ドメインはnetbk.co.jp)からのダイレクトメールのメールヘッダにはDKIMシグネチャが入っている。受信側サイトがDKIMに対応していれば、SBIネット銀行をかたる偽メールを判別することができる。つまり、netbk.co.jpからのメールのAuthentication-Resultsヘッダにいつもは「dkim=pass」と表示されるのに、ある時「dkim=fail」と表示されたら、「これはおかしい」と気付くことができる。
 銀行やクレジットカード会社の顧客が偽メールにだまされたら、大きな金銭的被害をこうむるおそれがある。だから、メッセージの正当性を検証できる手段を受信者に提供することは、顧客を詐欺の被害から守るために意味のあることだと言える。
 いや、これで顧客がだまされなくなるわけではない。悪者がたとえばnetbk-service.jpのようなドメインを取得してDKIMに対応し、SBIネット銀行の関連会社をかたってフィッシング詐欺メールを送信したら、やはりだまされる人はいるかもしれない。これはSBIネット銀行としてはいかんともしがたい。しかしそれでも、同社は「なりすましメールによる被害から顧客を守るために、当社は最善の努力をしている」と主張できる。つまり、なりすましメールを判別する技術があるにもかかわらず使っていなかった場合よりも、同社が責任を問われるのを回避しやすい。これは同社にとってのメリットである。
 では、送信ドメイン認証にはすべてのサイトが対応すべきだろうか。私は、送信側として送信ドメイン認証に対応するのは、名をかたられて自サイトが責任を問われるのを回避しやすくなるという、自サイトにとってのメリットがあると判断するサイトだけでよいと思う。たとえば、なりすましメールにだまされる自社の顧客が重大な金銭的被害をこうむりうる銀行やクレジットカード会社、名をかたられたデマで社会に混乱を起こされかねない政府・自治体機関などである。それ以外の企業、学校、個人サイトなどでは、あえて導入するまでもないだろう。「貴社からのメールに書かれていたURLをクリックしてウィルス感染させられた」と苦情を受けても、「Receivedヘッダを見せてください。ほら、当社から送信されたものではありませんよ」と説明して済むことである。
 送信ドメイン認証は、標的型攻撃への対抗策として注目が集まり始めているとの情報がある。しかし、標的型攻撃を仕掛ける敵は、著名企業の信用を利用するためにその関連会社と見まがうドメインを使って、また、知人を装うために別メールアドレスを取得したふりをして(携帯電話番号が変わったと嘘をつく振り込め詐欺のように)、ターゲットをだまそうとするだろう。送信ドメイン認証では、スパムを激減させることができないだけでなく、標的型攻撃も防ぎきれないのである。
 「spf=pass」「dkim=pass」の表示に安心してしまう癖が付くのはかえって危険である。なりすましメールにだまされないためには、送信ドメイン認証の普及よりも、偽情報を見破る情報リテラシーをみんなが持つことの方が重要である。

続編:情報リテラシーを向上させるには

水曜日, 8月 01, 2012

自分の記事の検索順位が上がるか?

 前回、「送信ドメイン認証」で検索した人にぜひ読んでもらいたい記事「送信ドメイン認証はスパムに勝てないだろう」の検索順位が30位であることを述べた(今検索してみたら、34位に下がっていた)。
 S25Rホームページの注目度が高いので、ここからリンクされるサイトの検索順位が上がることが期待されてスポンサーが付いた。ならば、S25Rホームページを、自分の記事の検索順位を上げるために使ったらどうか。なぜすぐに思い付かなかったのだろうか。
 S25Rホームページの下の方に「送信ドメイン認証はスパムに勝てないだろう」の記事へのリンクを設けてみた。さて、検索順位は上がるだろうか。

「spf dkim」で検索上位のコンテンツ

 前回、単純な検索ワードで上位にヒットする私のコンテンツを自慢したが、一つ自慢し忘れたものがあった。
 もしかしたら、検索する人のPCによっては1位にヒットしないかもしれないが、おそらくトップ10には入るだろう。SPFやDKIMについて基本的なことを解説する多くのコンテンツを抜いて上位にヒットするのは意外な気がする。
 これは2008年2月8日に書いた記事。「SPFとDKIMはドメイン認証方式として理想的なものではないと思う」と述べた。その後、「ドメイン認証方式はスパム対策として有益ではない」と気付いて、2010年5月30日に「送信ドメイン認証はスパムに勝てないだろう」を書いた。こちらの方をぜひ読んでほしくて、「SPFとDKIMの問題点」の記事に「送信ドメイン認証はスパムに勝てないだろう」の記事へのリンクを設けている。
 「送信ドメイン認証」で検索すると、「送信ドメイン認証はスパムに勝てないだろう」は残念ながらトップ10にランクインしない。しかし、30位にヒットする。「送信ドメイン認証とは」では26位である。このくらいの順位なら、送信ドメイン認証について調べようとした人の目にとまる可能性はほどほど高いと期待できる。でも、なんとかトップ10まで登りつめてほしいところだ。
 送信ドメイン認証が普及したとしても、使い捨てドメインを使ったスパムに対しては無力である。送信ドメイン認証がスパム対策になるという誤解(あえて誤解と言おう)を解くために、私のコンテンツが役立ってほしいと思う。

日曜日, 7月 22, 2012

コンテンツの価値が認められれば検索ランクは上がる

 前回の続き。
 S25Rホームページにスポンサーが付いたのは、このページの注目度が高く、ここからリンクする他サイトの検索ランクを上げることができるとエージェント(インターネットマーケティング会社)に評価されてのこと。
 コンテンツの検索ランクを上げるには、背景色と同じ色で一見見えない検索ワードを本文の中にたくさん記述するとよいといった話を聞いたことがある。しかし、私はそんな策を弄したことはない。まして、お金を払ってまで自分のコンテンツの検索ランクを上げたいと思ったことなどない。それでも、多くの人が指定していると思われる単純な検索ワードでトップ10にランクインするコンテンツは、後述のようにいくつかある。
 このことから推測すると、検索ランクを上げるためにコンテンツに策を弄したり、注目度の高いサイトからリンクしてもらったりしなくても、有用である/興味深いと認めてもらえていそうなコンテンツの検索ランクはおのずと上がるようである。検索ランクは、コンテンツに含まれる検索ワードの数、コンテンツをリンクしてくれているサイトの数などの客観的データだけで機械的に決まるのではなく、コンテンツに対する主観的な価値判断も影響していると考えざるを得ない。
 検索ランクの高いコンテンツを持つ私はどんな工夫をしているかというと…
  • 読者像をはっきりさせる。すなわち、「どんな人のお役に立ちたいのか」を考える。
  • 想定した読者が一瞥して関心を持ってくれるように見栄えを工夫する。
  • 読みやすいように段落を適切に区切る。
  • 文章はわかりやすく。
  • 一文を長くしすぎない。
  • 機種依存文字を使わないなどの基本をわきまえる。
 見栄えを良くするためには図画を活用するのが当然と思われるかもしれないが、私は必要最小限しか使っていない。見栄えのための図画のデザインには慣れていない。それでも私のコンテンツの検索ランクが上がるということは、見栄えだけのための図画はあまり重要でないということだろう。
 お金をもらっておいて言うのも変だが、広告のリンク先のサイトには「もっとこうすればいいのに」と思う点がけっこうある。注目度の高いコンテンツを書く私のノウハウが活かせるなら、これをビジネスにしてみたい気もする。

 多くの人が指定していると思われる単純な検索ワードでGoogleでトップ10にランクインする私の自慢のコンテンツの一部は以下のとおり。検索順位は、検索する人のPCによって多少変わるかもしれない。

S25Rホームページに広告リンクを掲載

 ブログを長いことほったらかしてすみません。
 インターネットマーケティング会社(以後、エージェントと呼ぶ)からの依頼で、7月2日からS25Rホームページに広告リンクを掲載した。
 リンクは10個。エージェントから指定されたそれぞれのリンク名は短く、全体の表示は2行に収まる(ブラウザウィンドウの横幅800~1024ピクセルのとき)。位置は、S25R方式の概要説明と「S25Rでメールが受信拒否された方へ」の説明の間。ブラウザウィンドウの高さが600ピクセルと小さめでも、スクロールなしで広告が目に入るようになっている。
 多くのリンク名は簡潔すぎるので、訪問者がリンク名を見てもあまり興味を惹かれそうにない。そこで、AタグのTITLE属性を使って、リンクにカーソルを置くとサイトの説明が表示されるようにしようと思ったが、エージェントからそれはやめてくれと言われた。リンクを入れ替える時に修正漏れでリンク名と説明表示が食い違うのは避けたいからとのこと。どうやら、S25Rホームページを訪れた人が広告リンクをクリックしてくれることが期待されているのではなく、注目度が高いS25Rホームページからリンクされていることだけでリンク先サイトの検索ランクが上がるということが期待されているらしい。
 これでいくらもらえるかというと、リンク1個につき1ヶ月で、明太子をトッピングした博多ラーメンを食べられるくらいの価格(と言えば推測できるでしょう)。リンク先は商用サイトではなく、非営利の情報サイトなのだが、クライアント(リンク先サイトのオーナー)は、この価格にマージンを加えた料金をエージェントに支払っていることになる。非営利サイトなのに、検索ランクを上げたくてそんなにもお金を払ってくださるとは、正直驚き。クライアントの希望をかなえるのに、私のサイトがそんなにも力になれるのだろうかと気がかりである。もっとも、私のサイトの価値を評価したのはエージェントであり、私はエージェントの注文に忠実に従うだけ。私のサイトに効果がなければ契約が打ち切られるまでのことだから、私が気にする必要はないのであるが。

月曜日, 4月 04, 2011

ドイツでのS25R設定にベルギーから苦情

 ベルギーのドメインの管理者からメールをいただいた。「うちのドメインからドイツの***.deというドメインへ送るメールがことごとく『550 S25R check reject』というメッセージで拒否される」とのこと。「S25R」で検索して私のサイトを見つけて連絡してきたらしい。
 宛先のドイツのドメインのオーナーへメールを送った。「拒否コード『550』を返しては絶対にいけません。S25Rはしばしば偽陽性判定を起こします。『450』を返して、再試行するクライアントをホワイトリスト登録するようにしてください。さもなければ自動ホワイトリスティングシステムを導入する必要があります」。
 最初、postmaster宛に送ったのだが、エラーリターンしてしまった。必須のエイリアスなのに、最近では設定していない人もいるようである。ドメインに「www.」を付けたURLでウェブサイトにアクセスし、連絡先アドレスを見つけ出してそこへ送り直した。
 ベルギーへは、「宛先ドメインの管理者にこのように伝えました。あなたからも苦情を送ってはどうでしょうか。あなたのメールサーバはS25Rに引っかかりません」と伝えた。
 3月31日にメールを送って、まだどちらからも返事がない。どうなっているのか…。