すでに着信してしまったスパム、およびサブジェクトのチェック（「image editing」）や本文チェック（「@aliyun.com」）や「5桁以上連続する数字で始まるサイトドメイン名」の条件でブロックされたスパムに、送信者エンベロープアドレスとFromヘッダのメールドメインが共に「@yandex.com」であるものがかなりあることに気付いた。そこでheader_checksに
/From:.+@yandex\.com/ REJECT
と設定しておいたら、これが効いていた。
Jun 2 20:20:32 reject: header From: "Louis" <q***@yandex.com> from coorner.yjec.net[108.170.60.178]; from=<q***@yandex.com> to=<w***@gabacho-net.jp> proto=ESMTP helo=<coorner.yjec.net>: 5.7.1 message content rejected
Jun 3 00:29:03 reject: header From: "Louis" <q***@yandex.com> from white.91yuepao.com[192.99.193.104]; from=<q***@yandex.com> to=<w***@gabacho-net.jp> proto=ESMTP helo=<white.91yuepao.com>: 5.7.1 message content rejected
「check_sender_accessで蹴った方がデータ伝送が減るのに」と思う人がいらっしゃると思うが、あえてFromヘッダをチェックするようにした。というのは、エラーメッセージが「sender address rejected」だと、スパマーは「ならば送信者アドレスを変えれば着信するだろう」と容易に推測できてしまうが、ヘッダチェックだとエラーメッセージが「message content rejected」になり、ヘッダと本文の中のどこが引っかかったのかがスパマーにはわからないからである。
2014年11月3日「一日中拒絶記録がなかった日」で、スパムアクセスが非常に減っていることを述べたが、またぞろ増えてきた（1ヶ月で6158個ものスパム送信元ホストが発見された2007年ほどのひどい状況ではないが）。これに対抗する工夫をするのもなかなか楽しい。
水曜日, 6月 03, 2015
ランダムな英字のサイトドメイン名
5月25日「数字で始まるサイトドメイン名――今までに見つかったもの」に対して、匿名さんからコメントをいただいた。
貴重な情報に感謝したい。
「5桁以上連続する数字で始まるサイトドメイン名」という条件は怪しさを定式化できたものだが、「ランダムっぽい英字列」は定式化しにくい。スパマーがスパム送信のために取得したドメインで、怪しさの定式化に合致しないものは、一つ一つブラックリストに載せるしかないだろう。その情報を皆で提供し合ってS25R導入サイトで共有できるようにしようとの気運が盛り上がれば、私が公開ホワイトリストと同様にそのまとめ役をしてもよいと思っている。
ちなみに、私のサイトで発見した、数字で始まるサイトドメイン名のスパム送信ホストとしては、冒頭でリンクした5月25日の記事で紹介したものに加えて、その後さらに以下が見つかっている。
subway.88881122.com [181.214.50.111]
maidong.20962.net [199.119.206.105]
white.91yuepao.com [192.99.193.104] *
martyi.10001688.com [192.99.193.103]
（*は「5桁以上連続する数字で始まる」という条件には引っかからなかったもの。ヘッダチェックでブロックしていた。）
| ランダムっぽい６文字の英字.com も、はやりのようです。 コメント(#)は、whois情報。 以下は、いわゆる、お馴染みさんの例です。（同じ登録者で複数のドメイン） いずれも、milter-greylist の数十分の再送要求期間を突破してきたものです。 逆引きが設定されていることは少ないですが、helo または エンベロープfrom で、ブロックすることができます。 # Lloyd, David ( Coxsackie NY, US ) /\.wbecse\.com$/ /\.gqxbut\.com$/ /\.nstjss\.com$/ # Ruiz, Aaron ( San Gabriel CA, US ) /\.svjpjp\.com$/ /\.dbdwdt\.com$/ # Robertson, Anna ( Auburn WA, US ) /\.tstdmt\.com$/ /\.xnqsad\.com$/ # Ray, Brian ( Queensbury NY, US ) /\.tfsmdk\.com$/ /\.rnjqdm\.com$/ /\.uuhwxd\.com$/ # Sun, Yingting ( Gangtang Hubeisheng, CN ) /\.anfpsk\.com$/ /\.kfkayj\.com$/ /\.picqym\.com$/ /\.qixjsf\.com$/ /\.typlej\.com$/ ６文字の英字.com 以外のお馴染みさんの例は、 # Marius Mica ( Bucuresti, RO ) /\.debita\.info$/ /\.sockinga\.info$/ /\.bristlesa\.info$/ /\.shutteremail\.info$/ # Sam Lin ( Shenzhen GD, CN ) /\.summerglasses\.info$/ /\.supsunglass\.info$/ これ以外にも沢山ありますが、きりがないので、サンプルとして。 |
貴重な情報に感謝したい。
「5桁以上連続する数字で始まるサイトドメイン名」という条件は怪しさを定式化できたものだが、「ランダムっぽい英字列」は定式化しにくい。スパマーがスパム送信のために取得したドメインで、怪しさの定式化に合致しないものは、一つ一つブラックリストに載せるしかないだろう。その情報を皆で提供し合ってS25R導入サイトで共有できるようにしようとの気運が盛り上がれば、私が公開ホワイトリストと同様にそのまとめ役をしてもよいと思っている。
ちなみに、私のサイトで発見した、数字で始まるサイトドメイン名のスパム送信ホストとしては、冒頭でリンクした5月25日の記事で紹介したものに加えて、その後さらに以下が見つかっている。
subway.88881122.com [181.214.50.111]
maidong.20962.net [199.119.206.105]
white.91yuepao.com [192.99.193.104] *
martyi.10001688.com [192.99.193.103]
（*は「5桁以上連続する数字で始まる」という条件には引っかからなかったもの。ヘッダチェックでブロックしていた。）
火曜日, 6月 02, 2015
某著名サイトのホワイトリスト項目
本日（2015年6月2日）、公開ホワイトリストに以下の著名サイトの項目を掲載した。
# Jun 02, 2015: outbound.apac.e.paypal.com
/^208\.94\.23\.107$/ OK
実は、私宛のアナウンスメールがブロックされているのを発見してホワイトリスト登録で受信したのは5月23日のことである。Postfixが表示した逆引き名はunknownだったが、逆引きできないのではなく、逆引き結果がoutbound.apac.e.paypal.com.23.94.208.in-addr.arpa.となり、パラノイド検査エラーになっていたのである。
著名なサイトだから、教えてあげればDNS設定を直してくれるだろう、そうすれば公開ホワイトリストに掲載するまでもないと思った。問い合わせフォームには適切な分類先がなかったが、近いと思われるものを選んで書き込んだ。
「私のメールサーバーが貴社からのメールを受信保留しました。原因は、貴社のメールサーバーのIPアドレス208.94.23.107の逆引き名がoutbound.apac.e.paypal.com.23.94.208.in-addr.arpa.と誤ったものになっていたため、不審なホストと判定したものです（許可条件を設定してすでに受信はできています）。DNSの設定で逆引き名の末尾のドットが抜けていると思われます。ご確認いただければ幸いです。」
世界的な企業なので、ネットワーク管理担当者は日本人ではないだろうと気を回して、英文も併記した。
日本語の回答が来て、「技術的な内容なので、テクニカルサポートへ」とたらい回しされた。
示されたテクニカルサポートのURLにアクセスして、また英文併記で書いた。英語で「関係部門で調査します」という回答が来た。
その後、問い合わせについてのフィードバック依頼が来たので、対応について「きわめて不満足」と回答した。「顧客サポートを依頼したのではなく、貴社のネットワークマネジメント上の不備を善意で教えて差し上げたのだから、どの担当者が受けたものであっても、たらい回しせず、貴社内で連絡を伝えてくださるべきです」。
結局、今日に至るまでDNSは直っていないので、公開ホワイトリストに掲載した。もちろん、同社のネットワークマネジメント上の不備を言いふらすためではなく、S25R導入サイトへの協力のためである。
［追記］
208.94.23.107の逆引き名を「outbound.apac.e.paypal.com.」と設定すべきところ末尾のドットを抜かしただけかと思ったら、そうではないようだ。outbound.apac.e.paypal.com（HELOアドレスもこうなっていた）を順引きしたら、96.47.30.195、96.47.30.198、96.47.30.197、96.47.30.196、96.47.30.181、96.47.30.182という、別のIPアドレス帯の複数のIPアドレスが検索された。通常は一つの名前から複数のIPアドレスが順引きされるのはかまわないが、逆引き名として設定された名前でこれをやっちゃいかん。同社のDNS設定はあまりきちんとしていないらしい。
で、公開ホワイトリストのコメント行は
# Jun 02, 2015: paypal.com's
と変えた。コメント行に正確なFQDNを記載するのは、その順引き結果のIPアドレスが、逆引きできないIPアドレス、またはS25Rに引っかかる逆引き名に対応するIPアドレスに一致する場合というのを公開ホワイトリストの記述の原則としてきたので。
# Jun 02, 2015: outbound.apac.e.paypal.com
/^208\.94\.23\.107$/ OK
実は、私宛のアナウンスメールがブロックされているのを発見してホワイトリスト登録で受信したのは5月23日のことである。Postfixが表示した逆引き名はunknownだったが、逆引きできないのではなく、逆引き結果がoutbound.apac.e.paypal.com.23.94.208.in-addr.arpa.となり、パラノイド検査エラーになっていたのである。
著名なサイトだから、教えてあげればDNS設定を直してくれるだろう、そうすれば公開ホワイトリストに掲載するまでもないと思った。問い合わせフォームには適切な分類先がなかったが、近いと思われるものを選んで書き込んだ。
「私のメールサーバーが貴社からのメールを受信保留しました。原因は、貴社のメールサーバーのIPアドレス208.94.23.107の逆引き名がoutbound.apac.e.paypal.com.23.94.208.in-addr.arpa.と誤ったものになっていたため、不審なホストと判定したものです（許可条件を設定してすでに受信はできています）。DNSの設定で逆引き名の末尾のドットが抜けていると思われます。ご確認いただければ幸いです。」
世界的な企業なので、ネットワーク管理担当者は日本人ではないだろうと気を回して、英文も併記した。
日本語の回答が来て、「技術的な内容なので、テクニカルサポートへ」とたらい回しされた。
示されたテクニカルサポートのURLにアクセスして、また英文併記で書いた。英語で「関係部門で調査します」という回答が来た。
その後、問い合わせについてのフィードバック依頼が来たので、対応について「きわめて不満足」と回答した。「顧客サポートを依頼したのではなく、貴社のネットワークマネジメント上の不備を善意で教えて差し上げたのだから、どの担当者が受けたものであっても、たらい回しせず、貴社内で連絡を伝えてくださるべきです」。
結局、今日に至るまでDNSは直っていないので、公開ホワイトリストに掲載した。もちろん、同社のネットワークマネジメント上の不備を言いふらすためではなく、S25R導入サイトへの協力のためである。
［追記］
208.94.23.107の逆引き名を「outbound.apac.e.paypal.com.」と設定すべきところ末尾のドットを抜かしただけかと思ったら、そうではないようだ。outbound.apac.e.paypal.com（HELOアドレスもこうなっていた）を順引きしたら、96.47.30.195、96.47.30.198、96.47.30.197、96.47.30.196、96.47.30.181、96.47.30.182という、別のIPアドレス帯の複数のIPアドレスが検索された。通常は一つの名前から複数のIPアドレスが順引きされるのはかまわないが、逆引き名として設定された名前でこれをやっちゃいかん。同社のDNS設定はあまりきちんとしていないらしい。
で、公開ホワイトリストのコメント行は
# Jun 02, 2015: paypal.com's
と変えた。コメント行に正確なFQDNを記載するのは、その順引き結果のIPアドレスが、逆引きできないIPアドレス、またはS25Rに引っかかる逆引き名に対応するIPアドレスに一致する場合というのを公開ホワイトリストの記述の原則としてきたので。
金曜日, 5月 29, 2015
数字だけのサイトドメイン名のホストの挙動
前回、スパムを送ってくる、サイトドメイン名が数字だけから成る様々なドメインを挙げた。いずれも末端ホスト名はS25Rに引っかからない、英字だけから成る名前なので、ISPに直結したPCがボット化したものとは思われず、スパマーがドメインを多数取得してスパム送信用コンピュータを運用しているものと思われる。
しかしその挙動は、まともに再送信するメールサーバのそれではなく、ボットそっくりである。拒絶ログソーティングスクリプトの表示形式で示す。
May 22 20:27:53 C alone.000086.net [69.12.83.148] from=<m***@mail.com> to=<w***@gabacho-net.jp> helo=<alone.000086.net>
1回きりの送信で、再送信していなかった。
May 25 12:34:41 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>
May 25 13:34:46 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>
1時間後に1回だけ再送信したように見える。しかし、2通のスパムを再送信なしで送信したものという可能性もある。
May 29 13:21:27 C right.68706.net [199.180.255.251] from=<d***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
May 29 13:50:16 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
May 29 16:26:05 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
前回挙げた中にない新しいホストである。送信者アドレスは2件で、2件目は再送信したように見えるが、時間間隔は2時間半以上。まともなメールサーバにはまずない挙動である。
こんな挙動だから、
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
という設定はお勧めだと思う。
しかしその挙動は、まともに再送信するメールサーバのそれではなく、ボットそっくりである。拒絶ログソーティングスクリプトの表示形式で示す。
May 22 20:27:53 C alone.000086.net [69.12.83.148] from=<m***@mail.com> to=<w***@gabacho-net.jp> helo=<alone.000086.net>
1回きりの送信で、再送信していなかった。
May 25 12:34:41 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>
May 25 13:34:46 C dove.150686.com [89.35.134.136] from=<m***@yandex.com> to=<w***@gabacho-net.jp> helo=<dove.150686.com>
1時間後に1回だけ再送信したように見える。しかし、2通のスパムを再送信なしで送信したものという可能性もある。
May 29 13:21:27 C right.68706.net [199.180.255.251] from=<d***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
May 29 13:50:16 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
May 29 16:26:05 C right.68706.net [199.180.255.251] from=<q***@yandex.com> to=<w***@gabacho-net.jp> helo=<right.68706.net>
前回挙げた中にない新しいホストである。送信者アドレスは2件で、2件目は再送信したように見えるが、時間間隔は2時間半以上。まともなメールサーバにはまずない挙動である。
こんな挙動だから、
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
という設定はお勧めだと思う。
月曜日, 5月 25, 2015
数字で始まるサイトドメイン名――今までに見つかったもの
5月1日の記事で紹介した
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
という拒否条件は、「トップレベルドメインがcomかnetで、サイトドメイン名は5桁以上連続する数字列で始まる」という条件である。これに引っかかるホストは、すでに着信してしまったものと阻止に成功したものとを併せて、これだけある。
coco.27838.net [103.1.149.180]
july.7819888.com [104.171.113.11]
rain.828873.com [162.244.79.167]
west.488859.com [107.179.86.53]
yamoy.9001888.com [178.251.230.21]
gonna.135328.com [198.144.181.6]
alone.000086.net [69.12.83.148]
dove.150686.com [89.35.134.136]
けっこうよく効く拒否条件のようである。
惜しくもこれに引っかからないものには
pizza.89mt.com [216.107.147.253]
chu.0530ok.com [192.254.79.254]
があったが、サイトドメイン名の数字列の条件を「5桁以上」よりも短くすることまではしていない。
それと、3qbo.netというドメインは見るからに怪しいとまでは言えないが、mta3.3qbo.netやmta44.3qbo.netなど配下の多くのホストから<otori1@gabacho-net.jp>というおとりのアドレス（2003年にスパムの研究のためにホームページに仕掛けたもので、とっくにuser unknownになるようにしている）に宛てて何度もスパムアクセスがある。まともなウェブサイトが組まれていないようだということもあるし、怪しいドメインかな？
/^(.+\.)?[0-9]{5}[^.]*\.(com|net)$/ 450 domain check, be patient
という拒否条件は、「トップレベルドメインがcomかnetで、サイトドメイン名は5桁以上連続する数字列で始まる」という条件である。これに引っかかるホストは、すでに着信してしまったものと阻止に成功したものとを併せて、これだけある。
coco.27838.net [103.1.149.180]
july.7819888.com [104.171.113.11]
rain.828873.com [162.244.79.167]
west.488859.com [107.179.86.53]
yamoy.9001888.com [178.251.230.21]
gonna.135328.com [198.144.181.6]
alone.000086.net [69.12.83.148]
dove.150686.com [89.35.134.136]
けっこうよく効く拒否条件のようである。
惜しくもこれに引っかからないものには
pizza.89mt.com [216.107.147.253]
chu.0530ok.com [192.254.79.254]
があったが、サイトドメイン名の数字列の条件を「5桁以上」よりも短くすることまではしていない。
それと、3qbo.netというドメインは見るからに怪しいとまでは言えないが、mta3.3qbo.netやmta44.3qbo.netなど配下の多くのホストから<otori1@gabacho-net.jp>というおとりのアドレス（2003年にスパムの研究のためにホームページに仕掛けたもので、とっくにuser unknownになるようにしている）に宛てて何度もスパムアクセスがある。まともなウェブサイトが組まれていないようだということもあるし、怪しいドメインかな？
金曜日, 5月 22, 2015
本文チェックによるブロック――続編
5月19日「本文チェックによるブロックに成功」で、
/@aliyun\.com/ REJECT
という本文チェックでスパムのブロックに成功したことを述べた。
過去に着信したスパムを調べたところ、「***@tom.com」というメールアドレスが本文に書かれたスパムも2月25日から5月20日にかけて7通あったことに気付いた。そこで、
/@tom\.com/ REJECT
というチェックも加えた。
その成果は3回あった。日付と送信元は以下のとおりである。
May 21 00:07:05 jelly.juiceupcleanse.net[103.41.176.17]
May 21 02:08:42 jelly.juiceupcleanse.net[103.41.176.17]
May 22 21:28:03 mar.xzmp4.com[103.41.176.16]
今気付いたんだが、送信元の逆引き名のドメインは全然違うけど、IPアドレスは隣なんだな。
なお、aliyun.comもtom.comもウェブサイトを持っていて、中国のサイトだとわかった。これらのサイトがスパムに一枚噛んでいるとも考えられるが、連絡先アドレスを単に利用されているかかたられている可能性も否定できないと思った。そこで、該当するどのスパムでもこれらのメールアドレスの前に「Email:」または「Contact:」という語があったことを考慮して、無実のメールが誤ってブロックされるリスクを減らすために、body_checksの記述を次のように変更した。
/(E-?mail|Contact):.+@tom\.com/ REJECT
/(E-?mail|Contact):.+@aliyun\.com/ REJECT
/@aliyun\.com/ REJECT
という本文チェックでスパムのブロックに成功したことを述べた。
過去に着信したスパムを調べたところ、「***@tom.com」というメールアドレスが本文に書かれたスパムも2月25日から5月20日にかけて7通あったことに気付いた。そこで、
/@tom\.com/ REJECT
というチェックも加えた。
その成果は3回あった。日付と送信元は以下のとおりである。
May 21 00:07:05 jelly.juiceupcleanse.net[103.41.176.17]
May 21 02:08:42 jelly.juiceupcleanse.net[103.41.176.17]
May 22 21:28:03 mar.xzmp4.com[103.41.176.16]
今気付いたんだが、送信元の逆引き名のドメインは全然違うけど、IPアドレスは隣なんだな。
なお、aliyun.comもtom.comもウェブサイトを持っていて、中国のサイトだとわかった。これらのサイトがスパムに一枚噛んでいるとも考えられるが、連絡先アドレスを単に利用されているかかたられている可能性も否定できないと思った。そこで、該当するどのスパムでもこれらのメールアドレスの前に「Email:」または「Contact:」という語があったことを考慮して、無実のメールが誤ってブロックされるリスクを減らすために、body_checksの記述を次のように変更した。
/(E-?mail|Contact):.+@tom\.com/ REJECT
/(E-?mail|Contact):.+@aliyun\.com/ REJECT
火曜日, 5月 19, 2015
hinet.net
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には共通性があるのである。
しかし、その中で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には共通性があるのである。
こんなドメインあるんだねえ
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を返すようにしています。（再送してもらえるように） |
登録:
投稿 (Atom)