Tweet

「迷惑メール防止法」と呼ばれる「特定電子メールの送信の適正化等に関する法律」が2002年に施行されてから10年以上が経った今でも、毎日のように迷惑メールが送信されています。調査会社やセキュリティサービス会社各社の発表するレポートを参照しても、レポートや調査年により多少の差はあるものの、メール全体のトラフィックのうち、およそ60％～70％は迷惑メールが占めているという結果^(*1)です。
迷惑メール防止法のみならず、一般利用者にインターネット回線を提供する事業者(ISP)が、外部サーバーのTCP25番ポートに接続することを禁止する「Outbound Port25 Blocking」を導入したり^(*2)、メールサービス提供事業者が迷惑メールを自動的に除外するフィルタリングサービスを提供したりするなど、業界全体としても一定の対策が講じられています。
しかし、迷惑メールは一向に減る気配がありません。私の携帯電話のキャリアメールにも、毎日多くの迷惑メールが届いています。キャリアの迷惑メールフィルターも優秀で、高確率で除外してくれていますが、残ったものは一体どのようなものなのでしょうか。迷惑メールを防止するための技術とともに、少し調査してみました。
なお、迷惑メール関連の技術は、情報セキュリティの国家資格「情報セキュリティスペシャリスト」の試験で出題されることの多い技術です。資格取得を目指す方は、是非おさえておきましょう。

*1 参考：Kaspersky Lab - Spam report: February 2014
http://securelist.com/analysis/monthly-spam-reports/58559/spam-report-february-2014/
*2 通常、メールの送信のためには外部サーバーのTCP 25番ポートへ接続する。ISPでこれをブロックすることで、ISPと契約している利用者が迷惑メール送信を行うことを防止する取り組み。

迷惑メールを防止するための技術

まず、キャリアメールやWebメールサービスなどで実装されている、迷惑メールを防止するための技術にはどのようなものがあるのか、確認しておきましょう。

メールの送信元を認証する技術

迷惑メールが送信されることを直接的に防止する技術ではないものの、送信元メールアドレスを認証する技術が存在します。迷惑メールはその性質上、身元をはっきりさせた事業者が送信することはほとんどなく、送り主や返信先(Fromヘッダーに書かれているメールアドレスやReturn-Pathヘッダーに書かれているメールアドレス)を偽装していることが多くあります。つまり、送信元メールアドレスは信頼できる優良企業のドメイン(intellilink.co.jpとか！) となっているのに、実際に送ってきているのは悪質な業者、ということがよくあるわけです。そこで、送信元を偽装できないようにすることで、一定の効果があると考えられ、「送信ドメイン認証」と呼ばれる技術が生まれました。送信ドメイン認証には、以下の2つがあります。

(1) 送信者のIPアドレスでメールの送信元を認証するもの：Sender ID / Sender Policy Framework (SPF)

(2) 電子署名でメールの送信元を認証するもの：Domain Keys Identified Mail (DKIM) / Domain Keys

(1)の認証は、携帯電話キャリア標準のEメールサービス(以下、キャリアメール)では「送信ドメイン認証」や「なりすまし規制」などの名称で提供されています。キャリアメールの設定を一番厳しいものとした場合には、Sender ID/SPFに対応していないメールサーバーから送信されたメールは、全て迷惑メールという扱いとなり、届かなくなるようです。
より強力な認証を行う (2)のDKIMについては、Sender ID/SPFに比べて費用対効果が良くないという判断なのか、採用されていないようです。

メールの特徴から迷惑メールを識別する技術

メールのタイトルや本文など、メールの内容を確認することで、迷惑メールかどうか判定する技術です。実際には自然言語処理と呼ばれる技術で、迷惑メールによく含まれるキーワードを抽出するなどして行われています。「主人がオオアリクイに殺されて1年が過ぎました^(*3)」など、迷惑メールのタイトルに独特なものが多いのは、このような技術による影響と言われています。

*3：2006年頃に送信された迷惑メール。その目を引くタイトルが話題となった。

実際に送られてきたメールはどうなっているのか

さて、このような技術的な対策がなされている中、実際に届いてしまうメールはどのようになっているのでしょうか。

実際の迷惑メール

このメールは、Gmailに転送した際に迷惑メールフィルターに引っかかってしまっているものの、キャリアメールのチェックはくぐり抜けてスマートフォンに届いたものです。
どのようにくぐり抜けたのか、考察してみます。

Sender ID / SPFへの対応

キャリアメールでは、Sender ID / SPFのチェックをする設定にしているため、少なくとも送信元が偽装されたものではないはずです。まずはメールヘッダーを見てみましょう。

（個人のメールアドレス、送信者のものと思われるドメインやIPアドレスは伏せています）

Delivered-To: ******@gmail.com
Received: by 10.52.227.194 with SMTP id sc2csp158976vdc;
        Sat, 30 Aug 2014 07:12:30 -0700 (PDT)
X-Received: by 10.68.228.37 with SMTP id sf5mr24498228pbc.154.1409407949854;
        Sat, 30 Aug 2014 07:12:29 -0700 (PDT)
Return-Path: 
Received: from ezweb.ne.jp (mail107.ezweb.ne.jp. [111.86.156.42])
        by mx.google.com with SMTP id re2si5310411pdb.109.2014.08.30.07.12.28
        for <******@gmail.com>;
        Sat, 30 Aug 2014 07:12:29 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning foo@foo_domain does not designate 111.86.156.42 as permitted sender) client-ip=111.86.156.42;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning foo@foo_domain does not designate 111.86.156.42 as permitted sender) smtp.mail=foo@foo_domain
******@gmail.com>

Return-Path: <foo@foo_domain>

Received: from lsean.ezweb.ne.jp ([172.26.112.111])
	by nm27imta02.ezweb.ne.jp
	id <[email protected]>;
	Sat, 30 Aug 2014 23:12:27 +0900

Authentication-Results: ezweb.ne.jp;
	spf=pass smtp.mailfrom=foo@foo_domain;
	sender-id=pass header.from=baz@baz_domain
Received: from bar_hostname (unknown [xx.xx.74.42])

	by lsean.ezweb.ne.jp (EZweb Mail) with ESMTP id D6CAED1
	for <******@ezweb.ne.jp>; Sat, 30 Aug 2014 23:12:27 +0900 (JST)

Received: by bar_hostname (Postfix, from userid 1002)

	id ************; Sat, 30 Aug 2014 23:12:14 +0900 (JST)

Received: from localhost (unknown [10.xxx.xxx.xx])

	by localhost (Postfix) with ESMTP id ************;
	for <******@ezweb.ne.jp>; Sat, 30 Aug 2014 23:12:04 +0900 (JST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="=_f78bd4d12718dbcf4932d2c41460dc59"
To: <******@ezweb.ne.jp>

From: <baz@baz_domain>

Subject: =?Shift_JIS?B?gXWCooFBk/yC6oK/guGCvoLfgr6C5oKngWCBdg==?=
Message-Id: <xxxxxxxxxxxxxxxx>
Date: Sat, 30 Aug 2014 23:12:04 +0900 (JST)
X-SPF-AUTH: Pass (lsean.ezweb.ne.jp: domain of foo_domain designates xx.xx.74.42 as permitted sender) client-ip=xx.xx.74.42; envelope-from=<foo@foo_domain>; helo=bar_hostname; domain=foo_domain; txt=v=spf1 ; auth=v1;
X-Brightmail-Tracker: AAAAAA==
******@ezweb.ne.jp>******@ezweb.ne.jp>******@ezweb.ne.jp>[email protected]>

こういった調査ができるように、キャリアメールをGmailへ自動転送するよう設定しています。灰色背景としている部分は、Gmailへの自動転送時に付加されたヘッダーなので、ここでは無視します。赤太字部分がメール中継の流れやSender ID / SPFに関係する部分です。

メールはどこから送信されているか

Receivedヘッダーを確認することで、メールの送信元IPアドレスを確認できます。
一番下にある（一番古い）Receivedヘッダーは、10.xxx.xxx.xxというIPアドレスからメールが送信されたことを示していますが、これはLANで使用されているプライベートIPアドレスなので、その次を確認します。すると、Received: from bar_hostname (unknown [xx.xx.74.42])とあり、xx.xx.74.42から送信されたことが確認できます。
なお、このIPアドレスはwhoisで確認する限り、一般的なISP経由で割り当てられたものではなく、マルチホーム接続などの用途で割り当てられたもののようです。Outbound Port25 Blockingの影響を受けていない可能性があります。

Sender ID / SPFによる２つのドメインのチェック

Return-Path、および、Fromヘッダーに注目すると、異なるドメインが設定されています。Return-Path（返信先）は、foo_domainとなっているのに対し、From（送信者アドレス）baz_domainとなっています。Authentication-Results ヘッダーを見ると、以下の通り、Sender IDおよびSPFのチェックにて、どちらもチェックOKとされていることが確認できます。

Authentication-Results: ezweb.ne.jp;
	spf=pass smtp.mailfrom=foo@foo_domain;
	sender-id=pass header.from=baz@baz_domain

Sender ID / SPFでは、DNSのTXTレコードにそのドメインのメールを送信可能なIPアドレスが指定されている必要があります。実際にDNSサーバーの応答を確認してみましょう。LinuxなどでDNSサーバーの問合せ結果を確認するためのdigコマンドを使用します。

・「dig txt foo_domain」の実行結果

;; ANSWER SECTION:
foo_domain.	1200	IN	TXT	"v=spf1 ip4:xx.xx.72.0/22 ip4:***.***.***.*** ip4:***.***.***.*** ip4:***.***.***.0/24 ip4:***.***.***.0/24 ~all"

・「dig txt baz_domain」の実行結果

;; ANSWER SECTION:
baz_domain. 1200 IN	TXT	"v=spf1 ip4:xx.xx.72.0/22 ip4:***.:***.:***.0/24 ip4::***.:***.:***.:*** ip4::***.:***.:***.:*** ip4::***.:***.:***.0/24 ~all"

今回確認したfoo_domainとbaz_domainでは、いずれも、xx.xx.72.0/22からの送信を許可しています。つまり、xx.xx.72.0～xx.xx.75.255までのIPアドレスによるメール送信を許可する設定になっています。

内容チェックへの対応

Sender ID / SPFなどのドメイン認証技術は、迷惑メールを自らのドメインを使用して送信してくる業者を止めることはできません。前述の通り、正しく設定することでフィルタリングから逃れているようです。
では、文章のチェックへの対応はどうでしょうか。
迷惑メールの検知アルゴリズムの詳細は不明ですが、このメールにはいくつか特徴があったため、そこから推察してみます。

マルチパート

このメールは、文字の色や大きさ、他のURLへのリンクを含めることができるHTMLメールとなっています。HTMLメールを送信する場合、HTMLメールを表示できない(または、しない設定にしている)メールクライアントを考慮し、「マルチパート」という複数の内容を含む構造にした上で、HTMLと併せてプレーンテキストも含めておくことが一般的に行われます。一つのメールの中に、テキストだけの情報と、HTMLの情報をどちらも詰めて送付するわけです。
しかし、このメールには、プレーンテキストのメール本文が全く含まれていませんでした。

赤字部分：プレーンテキスト、青字部分：HTML

（～省略～：ヘッダー部分）
X-SPF-AUTH: Pass (lsean.ezweb.ne.jp: domain of foo_domain designates xx.xx.74.42 as permitted sender) client-ip=xx.xx.74.42; envelope-from=<foo@foo_domain>; helo=bar_hostname; domain=foo_domain; txt=v=spf1 ; auth=v1;
X-Brightmail-Tracker: AAAAAA==

--=_f78bd4d12718dbcf4932d2c41460dc59
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=Shift_JIS


--=_f78bd4d12718dbcf4932d2c41460dc59
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=Shift_JIS

PGh0bWw+DQo8Y（～省略～：Base64エンコードされたHTMLメール本文）
--=_f78bd4d12718dbcf4932d2c41460dc59--

もし、プレーンテキスト部分のみを評価していた場合、迷惑メールかどうか判断できない、ということになってしまいます。実際に、迷惑メールの判定において、プレーンテキスト部分のみをチェックするシステムがあるのかどうかは分かりませんが、送信者が意図的にこの構造を取っている事が考えられます。

キーワードの隠蔽

また、このメールはドットが不自然に使われている箇所があります。

このメールにかぎらず、迷惑メールでは、不自然にドットを挟んだ文章というものをよく見かけます。
キャリアメールやGmailなどの事業者が、自動的に文章を解析し、特定のキーワードが含まれていることなどから、迷惑メールと判定する場合があることは前述の通りです。ドットを挟むことで、本来の意味とは異なる単位で単語が認識されてしまうことが考えられます。迷惑メールではこのようなドットを挟んでいるものと考えられます。

情報を得るための工夫

更に、このメールをよく見ていると、受信者から情報を得るための工夫がいくつかあります。

リンクの表示

リンクの表示を、フィーチャーフォンにて添付ファイル付きのメールを受信した際の表示に似せています。あまり疑わずにアクセスしてしまう人もいるのではないでしょうか

アクセスの記録

・HTML本文(一部省略)

<html>
<body>


<a href="http://【baz_domain】/j5e/axn22.php?tv=【何かのIDのような英数字の羅列1】">01912626.3gp</a>(1.90MB)<br>
<a href="http://【baz_domain】/j5e/axn22.php?tv=【何かのIDのような英数字の羅列1】">01948216.3gp</a>(2.50MB)<br>
<a href="http://【baz_domain】/j5e/axn22.php?tv=【何かのIDのような英数字の羅列1】">01916131.3gp</a>(2.30MB)<br>

<br>
 (～省略～：brタグの繰り返し)
<hr>
<a href="http://【baz_domain】/j5e/kjr.php?tv=【何かのIDのような英数字の羅列2】">■配.信.停.止■</a><br>
</body>
</html>

もし、間違ってアクセスしてしまった場合、迷惑メール業者側へ通知されるような仕組みも存在します。
配信停止を含め、それぞれのリンクには、送信先により個別に振られているIDと思われる値が含められています。恐らく、このリンク先へアクセスすることで、送信先メールアドレスとアクセス有無が分かるようになっているのでしょう。

どう付き合っていくべきか

迷惑メールを送信する技術は、短期間で劇的に進化したわけではありませんが、長い時間をかけてまさに巧妙化していると言って良いのではないかと思います。その一方で、前述の通り、電子メールをより安全にするための取り組みも存在しています。更に、法規制も改訂が進められ、一部の悪質なケースでは実際に迷惑メールの送信によって逮捕者も出ています。しかし、未だ実効性が十分とは言えない状況です。
スパムフィルタリングなどの技術的な対策がされていても、ここで確認したメールのように、対策をすり抜けて届いてしまい、安全とは言えないメールも残ってしまうため、利用者のリテラシーが求められます。
メールに記載されたURLに不用意にアクセスしない、安易に添付ファイルを開かない、差出人名やリンク先が偽装されている可能性を考慮する、など、会社や職場と同じように、プライベートで使用しているサービスにおいても、注意する必要があります。

すぐに出来る迷惑メール対策

最後に、簡単にできる迷惑メール対策をご紹介します。

技術的な対策

迷惑メールフィルターの設定

携帯電話キャリア各社が提供するフィルタリングサービスを利用するだけでも、設定により大部分の迷惑メールを除外することが出来ます。前述のSPFによるフィルタリング設定も可能です。設定方法は各社の設定ページをご確認ください。

NTTドコモ　『迷惑メールでお困りの方へ』
https://www.nttdocomo.co.jp/info/spam_mail/
au　『迷惑メール対策』
http://www.au.kddi.com/support/mobile/trouble/forestalling/mail/
SoftBank　『迷惑メールでお困りのとき』
http://www.softbank.jp/mobile/support/antispam/

アンチウイルスソフトでの対応

プロバイダー発行のメールを昔から使用している場合など、PCでメールを受信する機会がある方もいらっしゃると思います。アンチウイルスソフトには、迷惑メール対策機能も付いているものが多いため、これらを活用しましょう

メールアドレスそのものを複雑にする

やはり、推測しやすい簡単なメールアドレスほど多数の迷惑メールが送信されます。簡単に出来る対策ではありませんが、特にキャリアメールやGmail・Yahoo!メールなどの著名なメールサービスでは狙われやすくなるため、@（アットマーク）よりも前の部分を複雑にしたメールアドレスを使用することも、迷惑メール対策という意味では効果が期待できます。

心構え

メールに警戒する

存在しない債権をかたった架空請求や、不当な運営が行われた出会い系サイトへの誘導など、メールを起点にした攻撃は多く存在します。明らかに怪しいメールから、よく読まないと危険性に気付けないものまで、様々なものを読んだ経験のある方も多いのではないでしょうか。メールを基に何らかの被害を受ける可能性がある、という事を意識しておくことが重要です。

参考文献

• NTT PC Communications　『用語解説辞典』
  【アウトバウンドポート25ブロッキング】
• IPA　『情報セキュリティ』
  なりすましメール撲滅に向けたSPF（Sender Policy Framework）導入の手引き
• 財団法人インターネット教会　『有害情報対策ポータルサイト　迷惑メール対策編』
  SPF（Sender Policy Framework）
• DKIM (Domainkeys Identified Mail)
• ï¼ IT　『Security&Trust』
  電子署名方式の最新技術「DKIM」とは

Writer Profile

加納 永康

Tweet

• セキュリティサービス