ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.35
  6. 2.メッセージングテクノロジー

Internet Infrastructure Review（IIR）Vol.35
2017年6月20日発行RSS

目次

2.2 迷惑メールの動向

ここでは、IIJのメールサービスで提供している迷惑メールフィルタが検知した迷惑メール量の割合の推移を元に、迷惑メールの変化の動向について報告します。

これまでと同様に迷惑メールの割合は、一週間単位で集計し全体の受信メール量に対して、迷惑メールと判断された受信メールの割合の推移をグラフなどで示します。

図-1 迷惑メール割合の推移

図-1に示す迷惑メール割合の推移のグラフは、前回のIIR (Vol.31)から1年以上の調査結果を含む、2015年から2年以上となる122週間のデータです。具体的には、2015年の第1 週(2014年12月29日からの1週間)から2017年の第17週(2017年4月24日の週)までの期間です。これより前のデータについては、IIR Vol.31及びVol.27を参照してください。

2016年度の迷惑メールの平均割合は38.5%でした。2015年度が24.2%でしたので、昨年度は前年度から14.3%増加したことになります。ここ数年は減少傾向が続いていたのですが、昨年度から増加傾向に転じたようです。図-1のグラフをみても、2016年度は変動の幅は大きいのですが、全体として増えていることが分かります。

図-1のグラフでは、2016年12月中旬から2017年3月まで、急激に迷惑メールが減少しています。Sophos社の記事（※1）でも同様の傾向が示されており、その理由としてNecursというボットネットが活動を低下させているようだ、との報告がありました。その後2017年3月以降、迷惑メールの割合が増加に転じていますので、ボットネットの活動低下は一時的なものだったようです。

2.2.1 送信ドメインの不正利用

迷惑メールの中で悪質なものの1つにフィッシングがあります。これは、迷惑メールの中に示されたURLなどにアクセスしてしまうことで、実在のサイトを模倣した偽のサイトに騙され、IDやパスワードなどの重要な情報を入力させ搾取する手口の1つです。最近では、日本のユーザ向けに日本語で記述されたフィッシングメールや偽のサイトなど、巧妙に作られたものも多く、警察庁のレポート（※2）でも引き続き金銭的な被害が発生していることが報告されています。

こうしたフィッシングメールを受け取らない対策や受け取ったときに騙されないことは重要ですが、こうしたメールの送信者情報に悪用されないための対策も忘れてはいけません。

フィッシング対策協議会のWebサイト（※3）やマイクロソフト社（※4）でも度々注意喚起が行われましたが、2017年1月から3月にかけて、マイクロソフトを騙るフィッシングメールの大量送信が何度か発生しました。いずれも表題(Subject: ヘッダ)は日本語で記述されており、筆者に直接届いたメールだけでも表-1のものがありました。

表-1 マイクロソフトを騙るメールの表題

これらのメールは、当初は送信者情報として以下のドメインを利用しており、メールのHTML部分のリンク先のURLにも同じドメインを利用していました。

microsoft-securityprotection-support.com
support-securityprotection-microsoft.com

これが3月に送られたメールでは、いずれの送信者情報（※5）もメールごとに別のドメインが用いられていましたが、メールのリンク先はほぼ固定のURLが利用されていました。

注目すべき点は、これらの送信ドメインは、送信ドメイン認証技術(SPF、DKIM、DMARCいずれも)の認証結果がすべて 'none'だったことです。直接届いたメール以外も簡単に分析してみましたが、ほぼSPFの認証結果は'none'でした。総務省の統計データ（※6）では、最新の調査結果では'none'の割合は9.26% ですので、3月に大量送信されたメールは、意図的にSPFに対応していないドメインを選んで利用したことが考えられます。

更に、手元に届いたメールの実際の送信元は、大半が海外から送信されていましたが、利用されたドメインの約8割のTLDが'jp'でした。日本語で記述されたメールですので、意図して'jp' ドメインを利用した可能性はありますが、SPFに対応していない 'jp'ドメインがこれ程実在していることも今後の課題だと考えています。

例えメールに利用していないドメインであっても、SPFの設定は必要です。迷惑メール対策推進協議会が発行した「送信ドメイン認証技術導入マニュアル第2版」（※7）では、メールを送信しないドメインの記述例を下記のとおり載せています。この設定例では、必ずSPFが'fail'の結果となります。

Sample 6: メールを送信しないドメイン
管理しているドメインがまったくメール送 信しない場合は、"-all" を利用して、その旨を公開できます。
example.org. IN TXT "v=spf1 -all"

こうした設定例は、2006年2月に発行した「JEAG Recommendation ～送信ドメイン認証について～」でもRecommendation 2.として前述の内容を提言しています。また最近では、SPFの設定例も含めて新たにメールに利用しない"Null MX"レコードの設定方法を示したRFC7505（※8）が発行されました。

送信側のドメインとして、メールを受け取ってもらうための送信ドメイン認証技術の導入も必要ですが、迷惑メール送信に悪用されないための、ドメインを守るための設定も忘れずに必要になると考えています。

  1. （※1）世界的に半数以下に激減するスパムメール(http://sophos-insight.jp/blog/20170315blank)。
  2. （※2）平成28年中におけるサイバー空間をめぐる脅威の情勢などについて(https://www.npa.go.jp/publications/statistics/cybersecurity/data/H28cyber_jousei.pdfPDF)。
  3. （※3）マイクロソフトをかたるフィッシング(https://www.antiphishing.jp/news/alert/microsoft_20170331.htmlblank)。
  4. （※4）マイクロソフトを装った不審メールの配信について(https://www.microsoft.com/ja-jp/office/2016/attention5.aspxblank)。
  5. （※5）送信者情報には、MUA(メーラ)などで表示されるヘッダFrom(RFC5322.From)とメール配送上で利用されるエンヴェロープFrom(RFC5321.From)がありますが、今回両方とも同じドメインが利用されていました。
  6. （※6）送信ドメイン認証結果の集計(SPF)(2016年12月時点)(http://www.soumu.go.jp/main_content/000468608.pdfPDF)。
  7. （※7）送信ドメイン認証技術導入マニュアル第2版(http://www.dekyo.or.jp/soudan/anti_spam/report.html#damblank)。
  8. （※8）RFC7505: A "Null MX" No Service Resource Record for Domains Tha t Accept No Mail(https://www.ietf.org/rfc/rfc7505.txtblank)。
2.メッセージングテクノロジー

ページの終わりです

ページの先頭へ戻る