ブラックリスト掲載基準の見直し

　共有ブラックリストの試行運用に協力してくださっている方から、blackhole2.hknet.comおよびblackhole4.hknet.comから何度もスパムアクセスがあるとの情報をいただいた。www.hknet.comにアクセスするとまともなウェブが現れるが、それらのホストの挙動の悪質さを聞き、また、ホスト名を構成するblackholeという語の怪しさから、特例のつもりで

/^blackhole.*\.hknet\.com$/ 450 spam ex-convict

と掲載した。
　その後、その方からの追加のメールで、hknet.comは香港にあるNTTコミュニケーションズ・グループのネットワークサービス会社であることを知り、改めてウェブを見て確認した。hknet.comドメイン配下のホストを顧客がスパム送信に悪用していると推測される。
　そこで、共有ブラックリストへの掲載基準を以下のように見直した。

スパム送信（着信に成功したものに限らない）の前科があるホストであって、以下のいずれかに該当するもの。

• 「http://www.ドメイン名/」または「http://ドメイン名/」のウェブサイトがない。
• ウェブサイトがあっても、そのドメイン固有のまともなビジネスについての情報が掲示されていない。
• まともなビジネスのドメインであっても、顧客のコントロール下にあって悪用されるリスクのあるホストを収容するネットワークサービスである（スパム送信元はその事業者のコントロール下にあるメールサーバでないこと）。

　なお、「顧客のコントロール下にあって悪用されるリスクのあるホストを収容するネットワークサービス」とは、ボットに感染するリスクのあるエンドユーザーコンピュータを収容するISPも含むものとする。そのようなエンドユーザーコンピュータはS25Rの一般規則でほとんど阻止でき、阻止できない逆引き名を使っているドメインからのスパムアクセスはほとんど来なくなってしまったが、もしS25Rで阻止できないエンドユーザー回線の逆引き名を使っているISPが新たに見つかったら、共有ブラックリスト（本格運用後の公開ブラックリスト）に載せることになる。
　また、S25Rの一般規則を使わない代わりとするブラックリストを検討していた頃の2010年11月3日の記事で、ウクライナのvolia.netの配下の、S25Rに引っかからない多くのホストからスパムアクセスがあったことを述べた（私はローカルのブラックリストでvolia.netをまるごと一時的受信拒否の対象としている）。www.volia.netにウェブアクセスするとwww.volia.com/ukr/にリダイレクトされ、翻訳にかけてみると、ネットワークサービスの会社とわかる。そこで、今後volia.net配下のホストからのスパムアクセスを私が発見したか協力者から通報された時には、上記3点目の条件に基づいてホストごとの一時的受信拒否条件を共有ブラックリストに掲載することになる。

ウクライナのまともそうなサイトからのスパム――ブラックリストに登録せず

　今日（6月19日）、メールサーバっぽい名前のホストがSpamCopでブロックされた。

Jun 19 10:03:27 reject: RCPT from mail.malysh.ua[178.251.108.21]: 450 4.7.1 Service unavailable; Client host [178.251.108.21] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?178.251.108.21; from=<a***@malysh.ua> to=<d***@gabacho-net.jp> proto=ESMTP helo=<mail.malysh.ua>

　www.malysh.uaとmalysh.uaを順引きしたら別のIPアドレス77.87.194.17が検索され、ウェブアクセスしたらウクライナのベビー用品会社と思われるウェブページが現れた。
　メールアドレスはスパマーのプログラムで拾われないように伏せたが、送信者アドレスのユーザー名は「admin」である。受信者アドレスは私の個人アドレスで、whoisを調べればわかってしまうが、私が自分のウェブサイトで公開してはいないアドレスである（公開しているのはwebmaster）。受信拒否の応答コードは450にしているが、その後1時間以上過ぎてもリトライがない。このことから、一応はまともなビジネスの会社だが、多量のスパムのばらまきにチューンしたソフトをメールサーバにインストールして宣伝のスパムをばらまいたか、あるいはサーバが侵害されたと推測される。
　6月13日の記事で提案した「そのドメイン固有のまっとうなビジネスの情報を掲示するウェブがない」という条件に合わないので、共有ブラックリストに掲載しなかった。スパムを発信したとはいえ、この会社と取引のある国内会社が絶対にないとは言えないし、本格運用後の公開ブラックリストが外国でも使われたとしたら、その会社の顧客や取引会社が困ることになりかねない。だから、スパムの前科のあるホストについての「そのドメイン固有のまっとうなビジネスの情報を掲示するウェブがない」という掲載条件は妥当と言えると、今のところ考えている。

怪しいホストの発見は順調

　昨日6月13日の記事で、着信したスパムに基づいて本文チェックの条件を変更したことを述べた。これが功を奏した。

Jun 14 19:41:43 reject: body Email: a***@sina.com from siyue.yujiazhan.com[64.110.129.130]; from=<k***@yahoo.de> to=<w***@gabacho-net.jp> proto=ESMTP helo=<siyue.yujiazhan.com>: 5.7.1 message content rejected

　これでsiyue.yujiazhan.comという新たな怪しいホストをまた発見して共有ブラックリストに掲載した。S25Rでは防御できないスパムを阻止しつつ、そのスパム送信元の情報を集めるということができている。なかなか快調である。
　こんなにちょくちょく怪しいホストが発見されると、本格運用開始後の公開ブラックリストの自動ダウンロードの頻度は、公開ホワイトリストの自動ダウンロードと同じく「一日1回まで」とお願いするよりも、もう少し高頻度でもかまわないとした方が、スパム阻止の成功確率が上がって喜ばれるかもしれない。そう考えていたら、ブラックリスト情報でご協力くださっている方がこれについてのご意見・ご提案もくださったので、今考えているところである。

本文チェックによるブロック条件の追加

　昨日6月12日と今日13日の2回、「business solutions」というサブジェクトで本文がまったく同じスパムが着信した。送信者アドレスと送信元ホストは異なっていた。昨日の送信元ホストcongcong.diqiutong.net [181.214.50.138]はその後共有ブラックリストに掲載していた。今日の送信元yixiang.3dsheji.cc [103.41.176.30]も、そのドメインのウェブサイトがないという掲載条件を確かめた上で掲載した（いずれも、末端ホスト名とその有無にかかわらず引っかける正規表現にしている）。
　そのスパムの本文に特徴的な部分は、

Email: a***@sina.com

であった。5月22日の記事で、body_checksに

/(E-?mail|Contact):.+@tom\.com/ REJECT
/(E-?mail|Contact):.+@aliyun\.com/ REJECT

と設定したことを述べたが、これに「@sina.com」を加えて、文字列サーチの処理効率を考慮して

/(E-?mail|Contact):.+@(tom\.com|aliyun\.com|sina\.com)/ REJECT

と一行の条件に書き換えた。
　www.sina.comにアクセスすると、中国のまともそうなウェブサイトが現れる。しかし、「@sina.com」は拒絶ログで何度も見た記憶がある。だからといってsina.comは怪しいドメインだという意味ではなく、アドレスをかたられたり標的にされたりしやすいドメインなのかもしれない。
　今までにも言っているが、上記のような本文チェックや、サブジェクトなどのヘッダチェックは、無実のメールを恒久的受信拒否で蹴飛ばすおそれが皆無ではないので、個人サイトか、受信者全員の同意を得ることができる小規模サイトにしかお勧めしない。しかし、このようなスパムの送信元を掲載した共有ブラックリストは、中規模以上のサイトでも使っていただいて差し支えない。一時的受信拒否で蹴るように書いてあるので、そのまま使えば、あるいは許可の遅れ時間を長めに設定したグレイリスティングによって、偽陽性からの救済の余地があるからである。

名前が怪しくないホストのブラックリスト登録

　nairobi.pollmans.co.keというホストから何度かスパムアクセスが来ている。まだロールアウトされていないログを見る範囲では5月20日以来6回あり、宛先は毎回<a***.s***@yahoo.com>と同じで、Relay access deniedで蹴っている。
　keはケニアの国ドメイン、coは日本と同じく企業の属性ラベル、pollmansも、ヨーロッパ人の姓としてpollmanというのがある（sはDenny's（デニーズ）のsと同じく英語の所有格語尾とも推測できる）し、nairobiは都市名。名前からは怪しさは感じられない。しかし、www.pollmans.co.keは順引きできず、ウェブは見つからない。
　「いかにも怪しいと見えるドメイン」ではないが、前回の記事で述べた「スパム送信の前科があり、かつそのドメインの（まともな）ウェブがない」という、感覚的でない明確化した判定条件に合致するとして、共有ブラックリストに登録した。このホストからのスパム送信アクセスが第三者中継を目論むものだけだとすれば、ちゃんと対策しているサイトにとっては被害はないが、このホストが正しい宛先にスパムを送り込むことがないとは断定できないので。

送信元の怪しさの判定基準

　試行運用を始めた共有ブラックリストは、スパム送信用のドメインをたくさん取得するという手口でS25Rが突破されるのに対抗することを主目的としている。数字ばかりのサイトドメイン名やランダムっぽい英字列のサイトドメイン名は怪しいと考えられる。
　しかし、スパム送信の前科があるからといって、一応はまともなメールサーバがスパム送信に悪用されただけだとしたら、すべてのS25R利用サイトに対して「このホスト（またはドメイン）からのメールは一時的受信拒否で蹴飛ばして大丈夫ですよ」と情報提供するというわけにはいかない。そこから送信される正当なメールを受信したいサイトでは、ホワイトリストによる救済作業が必要になるか、救済を自動化していても受信遅延は起こってしまう。だから、ブラックリスト情報を提供してくださる方々のためにも、「怪しい」と判定できる明確な基準が必要だと考えた。
　そこで考えたのは、「そのドメインのウェブサイト（ドメイン名の左に「www.」を付けてアクセスする）がない」という判定条件である。6月9日の記事に記載したブラックリスト項目の大多数はこの条件に合っていた。昨日6月12日に着信したスパムの送信元congcong.diqiutong.net [181.214.50.138]を共有ブラックリストに掲載したが、やはりwww.diqiutong.netはアクセスできなかった（順引きできない）。
　例外は

www.27838.net
www.7819888.com

で、いずれも中国語のウェブページが現れた。しかし、前者は英語で「This domain name is for sale」という表示があり、後者は中国語で「このドメイン名（7819888.com）は有効期限が切れています」という意味らしいことが書かれている。このことから、まっとうなビジネスのためにきちんと運用されているドメインではないということが推定できる。
　まとめると、スパム送信の前科があったドメインを怪しいドメインと判定する基準は、
「ドメイン名の左に『www.』を付けてウェブアクセスをした時にウェブページが現れない、または、現れても、そのドメイン固有のまっとうなビジネスについての情報が掲示されていない」
ということである。

共有ブラックリストの試行運用のお知らせ

　4月11日の記事で、数字だけのサイトドメイン名のホストからスパムが送られてくることが多いと報告して以来、スパマーがスパム送信のために取得したと思われるドメインがかなり多く見つかっている。また、6月3日の記事で、ランダムっぽい英字列のサイトドメイン名のホストからのスパムもかなり多いとの情報をコメントでいただいたことを紹介した。
　そのコメントをくださった方からメールをいただいた。日頃ホワイトリスト情報で協力してくださっている方だった。そういう、S25Rに引っかからない怪しいドメインを集めた共有ブラックリストを私が提供するなら協力していただけるとのことだったので、試行運用をしてみることにした。「ボットからのスパム送信を封じ込めてしまったS25Rが、多数のスパム送信用ドメインの取得という手口で裏をかかれ始めている」と思われるのが癪だからという思いもあってのことである。
　提供ファイルのURLは

http://www.gabacho-net.jp/anti-spam/black-list.txt

である（以前、このファイル名で「S25Rの一般規則による偽陽性を避けるために一般規則をやめる代わりのドメインブラックリスト」を試行提供したことがあるが、立ち消えになってしまったので、そちらはもうやめることにする）。
　共有ブラックリストを利用するには、/etc/postfix/main.cfファイルで以下のように指定する（サイトごとのカスタマイズは適当に）。

smtpd_client_restrictions =
  permit_mynetworks,
  check_helo_access regexp:/etc/postfix/helo_restrictions, # 違法なHELOの拒否
  reject_unauth_destination, # 第三者中継の拒否
  reject_unlisted_recipient, # 受信者不明の拒否
  check_client_access regexp:/etc/postfix/white-list.txt, # 公開ホワイトリスト
  check_client_access regexp:/etc/postfix/white_list, # ローカルホワイトリスト
  check_client_access regexp:/etc/postfix/black-list.txt, # 共有ブラックリスト
  check_client_access regexp:/etc/postfix/rejections # ローカルブラックリストと一般規則

　cronジョブで自動ダウンロードされる場合は、試行運用期間中は一時間1回までならしていただいてよい。ただし、もし本格運用に至った時には、公開ホワイトリストと同じく一日1回までとお願いすることになると思う。
　ポリシーは以下のとおりとする。

• スパムの前科があり、S25Rチェックをパスする（つまり、逆引きできてパラノイド検査もパスする）送信元ホストのFQDNをコメント行に記載する。
• ドメイン自体が怪しいと推測される場合は、ドメイン丸ごとの拒否条件式を記載する。
• 拒否条件指定は「450 spam ex-convict」（スパムの前科者）とする。システム環境やポリシーに応じた書き換えは利用サイトで適当に。
• ドメインが消滅したか、または怪しいドメインではないことに、私が気付いたかまたは協力者から通知された時には、掲載を取り消す。

　協力いただける方は、メールか掲示板かこのブログへのコメントのいずれでもよいので、情報をお寄せください。

　このような怪しいドメインで、スパムアクセスがあってから1ヶ月も経たずにもう消滅しているものもあった。今日サーバに載せた内容は以下のとおりである。今日時点で、FQDNが順引きできることは確認している。

# *** PUBLISHED S25R BLACK LIST *** # Last update: Jun 09, 2015 # (*): reported by a contributor # Jun 09, 2015: yayi.armsgame.com /^(.+\.)?armsgame.com$/ 450 spam ex-convict # Jun 09, 2015: kongdao.hljccl.com /^(.+\.)?hljccl\.com$/ 450 spam ex-convict # Jun 09, 2015: sunshine.nunv.net /^(.+\.)?nunv.net$/ 450 spam ex-convict # Jun 09, 2015: coco.27838.net /^(.+\.)?27838\.net$/ 450 spam ex-convict # Jun 09, 2015: july.7819888.com /^(.+\.)?7819888\.com$/ 450 spam ex-convict # Jun 09, 2015: dove.150686.com /^(.+\.)?150686\.com$/ 450 spam ex-convict # Jun 09, 2015: pizza.89mt.com /^(.+\.)?89mt\.com$/ 450 spam ex-convict # Jun 09, 2015: chu.0530ok.com /^(.+\.)?0530ok\.com$/ 450 spam ex-convict # Jun 09, 2015: mar.xzmp4.com /^(.+\.)?xzmp4\.com$/ 450 spam ex-convict # Jun 09, 2015: black.loudiok.com /^(.+\.)?loudiok\.com$/ 450 spam ex-convict # Jun 09, 2015: right.68706.net /^(.+\.)?68706\.net$/ 450 spam ex-convict # Jun 09, 2015: maidong.20962.net /^(.+\.)?20962\.net$/ 450 spam ex-convict # Jun 09, 2015: white.91yuepao.com /^(.+\.)?91yuepao\.com$/ 450 spam ex-convict # Jun 09, 2015: jizhoudao.13015.net /^(.+\.)?13015\.net$/ 450 spam ex-convict

Fromヘッダでブロック

　すでに着信してしまったスパム、およびサブジェクトのチェック（「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年ほどのひどい状況ではないが）。これに対抗する工夫をするのもなかなか楽しい。

ランダムな英字のサイトドメイン名

　5月25日「数字で始まるサイトドメイン名――今までに見つかったもの」に対して、匿名さんからコメントをいただいた。

ランダムっぽい６文字の英字.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桁以上連続する数字で始まる」という条件には引っかからなかったもの。ヘッダチェックでブロックしていた。）

某著名サイトのホワイトリスト項目

　本日（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アドレスに一致する場合というのを公開ホワイトリストの記述の原則としてきたので。

数字だけのサイトドメイン名のホストの挙動

　前回、スパムを送ってくる、サイトドメイン名が数字だけから成る様々なドメインを挙げた。いずれも末端ホスト名は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

という設定はお勧めだと思う。

数字で始まるサイトドメイン名――今までに見つかったもの

　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になるようにしている）に宛てて何度もスパムアクセスがある。まともなウェブサイトが組まれていないようだということもあるし、怪しいドメインかな？

本文チェックによるブロック――続編

　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

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には共通性があるのである。

こんなドメインあるんだねえ

　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についてはその偽陽性回避策を採らなかったからである。

本文チェックによるブロックに成功

　本文に共通点のあるスパムが最近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通程度）と、仕事を邪魔されない程度にまではなっているはずだから、業務でメールシステム管理をしている人は、こんな趣味的なブロッキングにうつつを抜かすべきではない。

サブジェクトでの拒否が突き抜けられた

　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」と複数形だったが、単数形でも引っかかるようにした。もちろん、後続の文字の条件は指定していないので複数形でも引っかかる。

迷惑電話対策

　迷惑メールでなく迷惑電話の話。
　我が家の固定電話に、出たらすぐに切れてしまうという変な電話がかかってくることが時々あった。かつて使っていたISDNとは違って、ひかり電話では発信番号通知がデフォルトではないので、追加で契約した。
　出たらすぐに切れてしまうのは番号非通知のコールだとわかった。電話機に「ヒツウチ」と表示された時にはほったらかしてみたら、決まって呼び出し音10回で切れた。何のためにかけてくるのか、わけわからん。
　電話機に、番号非通知のコールに対して「番号を通知してかけ直せ」とアナウンスを返して切る機能があったので、ナンバーリクエストサービスを追加契約しなくても対策ができた。reject_unknown_clientのようなものだな。ちょっと違うけど。
　ひかりルータのログを見ると、番号非通知のコールは2014年12月に2回、2015年1月に1回、2月に1回、3月に9回、4月に2回あった。最も新しい記録は4月25日である。敵はまだあきらめてはいないものと見える。

　それで思い出したのだが、NTTの発信番号通知サービスの開始がアナウンスされたころ、タモリさんがラジオ番組で「かけ手側では番号の通知を（184をダイヤルして）拒否できる？でも受け手側では番号非通知の電話を拒否できる？わけわからん」という意味のことを言っていた。一見相対立するポリシーだが、かけ手が悩み事相談などで自分のプライバシーを守りたい時には番号通知を拒否できるし、受け手が「いのちの電話」や事業者ならば番号非通知のコールも拒否しない、一方、一般家庭では身元を隠すかけ手からのコールを拒否したいと思えばできるということである。ユーザーのポリシーで選択できるということで、それは言い換えれば、ユーザーは自分のために最も良いサービスの選択を自分で判断しなければならない、選択の自由度が高まれば選択の責任は自分が負うということである。今は広く理解されていることだと思うが、当初は一般ユーザーにはなかなか理解しにくかったようである。

サブジェクトで拒否＆数字だけのサイトドメイン名――続編

　前回、サブジェクトの拒否条件を紹介した。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桁以上続いたら、あとは英字が含まれていても不自然な名前として警戒してよいだろうと考えたこと、それと、末端ホスト名が省略された逆引き名であっても引っかけようと考えたからである。

似たスパムをサブジェクトで拒否＆数字だけのサイトドメイン名のチェック

　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時間未満でリトライをやめることはまずないので、放っておけばいいだろう。