第144回「
IPアドレスに基づくスパムメール防御策」の続編です。その後の研究で、スパムメールの拒絶の打率が向上しました。2004年4月の1ヶ月間で、スパムメールとウィルスメールを合わせた不正メールアクセス(スパムかウィルスかは、拒絶ログから判別できないことがあります)を873回受けながら、
スパムメールを受けてしまったのは1回だけで、
ウィルスメールは一度も受けませんでした。
その拒絶方式のポイントは、SMTP(メール転送プロトコル)アクセスをかけてくるコンピュータがまっとうなメールサーバであるかどうかを推測するというものです。善良なメールはたいてい、プロバイダや組織のまっとうなメールサーバを経由して送られてきます。一方、スパムメールやウィルスメールは、今ではたいてい、ADSLなどのエンドユーザー用回線につながったコンピュータから直接送られてきます。そこで、エンドユーザー用回線からのアクセスを拒否すれば、スパムメールとウィルスメールのほとんどを阻止できるのです。
アクセス元がまっとうなメールサーバであるかどうかは、そのIPアドレスに基づいて推測します。きちんと管理されたメールサーバはたいてい、DNSでIPアドレスからFQDN(Fully Qualified Domain Name:完全修飾ドメイン名)を逆引きできます。したがって、逆引きができないIPアドレスからのアクセスを拒否することにより、不正メールの受信を減らすことができます。また、今ではエンドユーザー用回線も逆引きできることが多くなりましたが、そのFQDNのほとんどには、まっとうなメールサーバのFQDNとは違って数字が多用されているという特徴が見られます。そこで、FQDNの文字パターンを定義しておくことにより、エンドユーザー用回線からのアクセスと見破ることができます。その設定は、
Postfixでは容易にできます。
以下に、私が作り上げた阻止条件と、2004年4月の統計に基づく阻止率を説明します。阻止条件は、まっとうなメールサーバのFQDNをなるべく引っかけないように工夫してあります。なお、当月、不正メールアクセス回数は873回、IPアドレス数は567個でした。阻止率はIPアドレス数についてのものです。
- 逆引きできない
この条件によって38.4%が阻止されました。第144回の記事を書いた2003年6月ころには90%以上を阻止できていましたが、逆引きできないIPアドレスの割合は減ってきています。
- 逆引きされたFQDNの最下位(左端)の名前が、数字以外の文字列で分断された二つの数字列を含む
-
例: |
220-139-165-188.dynamic.hinet.net
evrtwa1-ar3-4-65-157-048.evrtwa1.dsl-verizon.net
a12a190.neo.rr.com
|
ここまでで82.9%が阻止されました(44.5%アップ)。
- FQDNの最下位の名前が、5個以上連続した数字を含む
-
例: |
YahooBB220030220074.bbtec.net
pcp04083532pcs.levtwn01.pa.comcast.net
|
ここまでで90.5%が阻止されました(7.6%アップ)。なお、「5個以上」という条件は、ドメインを代表するMX(Mail eXchanger:メール交換サーバ)のホスト名を私が調べた中で数字4桁が最長だったことから決めました。
- FQDNの最下位または下位から2番目の名前が数字で始まる
(FQDNの上位3階層は検査除外)
-
例: |
398pkj.cm.chello.no
host.101.169.23.62.rev.coltfrance.com
|
ここまでで97.0%が阻止されました(6.5%アップ)。
- FQDNの最下位の名前が数字で終わり、かつ下位から2番目の名前が、1個のハイフンで分断された二つの数字列を含む
-
例: |
wbar9.chi1-4-11-085-222.dsl-verizon.net
m226.net81-66-158.noos.fr
|
ここまでで97.9%が阻止されました(0.9%アップ)。
- FQDNの下位2階層の名前がともに数字で終わる
(FQDNの上位3階層は検査除外)
-
例: |
m500.union01.nj.comcast.net
d5.GtokyoFL27.vectant.ne.jp
|
ここまでで98.2%が阻止されました(0.3%アップ)。
- FQDNの最下位の名前が「dhcp」、「dialup」、「ppp」、または「adsl」で始まり、かつ数字を含む
-
例: |
dhcp0339.vpm.resnet.group.upenn.edu
dialupM107.ptld.uswest.net
PPPbf708.tokyo-ip.dti.ne.jp
adsl-1415.camtel.net
|
この条件で初めてひっかかるFQDNはわずかに存在しますが、統計期間中にはありませんでした。
これらの条件で阻止できなかったIPアドレスは10個(1.8%)でしたが、そのうち、
- すでにドメイン名をブラックリストに登録していてはじいたもの:3件
- SMTPセッションのHELOコマンド(第105回参照)で自分のFQDNでなく相手のIPアドレスまたは宛先ドメイン名を名乗るという不正動作を検出してはじいたもの:2件
- おとりアドレス(不正メールをおびき寄せるために、閲覧者に見えないようにホームページに仕掛けたアドレス)に宛てられていたためにはじいたもの:2件
- 「bwebmaster」という不正アドレス(前回参照)に宛てられていたためにはじいたもの:1件
- 無効になっていたアドレスに宛てられていたためにはじいたもの:1件
でした。ドメイン名のブラックリストおよびHELOコマンドのチェックという対策によって阻止したものが5件(0.9%)でしたから、宛先誤り(おとりアドレスを含む)のために受信せずにすんだものを除いても、私の防御策による阻止率は合計で
99.1%ということになります。
ついに阻止できなかったのは1件だけで、それは、日本のまっとうな小企業のWindowsサーバから送り込まれた英語のスパムメールでした。私の推測では、ウィルスに感染してスパムメールの踏み台にされたのではないかと考えられます。
この防御方式にも以下の問題がありますが、解決可能です。
- 阻止できないことがある
エンドユーザー用回線のFQDNには、最下位のホスト名に数字が3〜4桁しか使われていないものや、番号が十六進数であるために見かけ上数字が少ないもの(十六進数が8桁の場合、番号全体のうち4%は前記の条件をすり抜けます)があります。また、独自のドメイン名を持つメールサーバからスパムメールが送られてくることもあります。
この問題は、そういうコンピュータから一度でもスパムメールを受けたらそのドメイン名をブラックリストに登録するという方法で解決できます。私のサーバでは、現在のところ、ブラックリストへの登録は19件になっています。
- 誤って阻止することがある
まっとうなメールサーバの中に、IPアドレスが逆引きできないものや、逆引きされたFQDNが前記の条件に引っかかってしまうものがまれにあります。また、まっとうな個人サイトや小企業のメールサーバの中に、エンドユーザー用のADSL接続サービスを使っていて、その逆引きFQDNが前記の条件に引っかかってしまうものがあります。
この問題は、アクセスを拒否する際に「後で送信を再試行せよ」の意味の「450」というエラーコードを返すという方法で回避できます。スパムメールやウィルスメールのほとんどは送信を再試行しませんが、まっとうなメールサーバなら数日間再試行します。ログを監視していて、まっとうな再試行を発見したら、許可条件を設定することによって受信します。私のサーバには、現在のところ、メールマガジンや予約確認メールの送信サーバなど、9件が許可リストに登録されています。
エラーコード「450」に対するまっとうな再試行を発見して許可条件を追加する処理を自動化することは技術的に可能です。これが実現できれば、私のサイトのような個人サイトだけでなく組織サイトでもこの方式を導入できるでしょう。
私のメールサーバは、スパムメールに対する防御力がおそらく世界最強になっていると思います。スパマーは、私の防御方式をとるドメインに対してはエンドユーザー用回線から直接スパムメールを送り込むことはできません。自分の利用するプロバイダのメールサーバを経由すれば、メールサーバを過負荷にしてプロバイダからペナルティを食らうでしょう。自分のドメイン名を持つという方法もありますが、一度スパムメールをばらまけばドメイン名がブラックリストに登録されるので、またすぐドメイン名を変えなければならないでしょう。すなわち、スパムメールをばらまくのに多大なコストがかかります。攻撃に多大なコストを強いることこそ最強の防御になります。
もしこの方式がインターネットの世界で受け入れられるなら、ドメインを代表するメールサーバとエンドユーザー用回線とを区別できる逆引きFQDNの命名法をすべてのサイトやプロバイダで合意することによって、不正メール対策はより確実なものになるだろうと私は考えています。
不正中継をしてしまうメールサーバのブラックリスト(ORBL:Open Relay Black List)を提供している
ORDBというサイトが今なお運用されていますが、スパマーが高速回線から大量のスパムメールを直接ばらまくことが低コストでできるようになった現在、もはやORBLはほとんど役に立っていないということにまだ気付いていないのでしょうか。
(2004/06/26 追記) このスパム対策方式を技術資料にして掲載しました。「スパム対策技術」のコーナーをご覧ください。英語版もあります。