Google & 米Yahoo! の迷惑メール対策強化について~ JPAAWG 緊急ウェビナーで喫緊課題への具体的な疑問が続出 | ScanNetSecurity
2024.07.27(土)

Google & 米Yahoo! の迷惑メール対策強化について~ JPAAWG 緊急ウェビナーで喫緊課題への具体的な疑問が続出

 ガイドラインの適用開始は 2024 年 2 月。この喫緊の課題にどう対応すればよいのか…。紙幅の都合上、一部しか紹介できないが、Q&Aセッションでは「5,000通はFROMアドレス基準か」「拒否はドメイン単位か IPアドレス単位か」「外部サービスでは SPFアライメントは失敗する」等々の 30 を超える質疑応答が行われた。

研修・セミナー・カンファレンス
(イメージ画像)
  • (イメージ画像)
  • Google社の制限

 昨 2023 年 12 月、Google と米国Yahoo! が 10 月に発表した迷惑メール対策強化の新基準について、メールをはじめとするインターネット上の脅威について情報提供や注意喚起を行う JPAAWG が緊急ウェビナーを開催した。

 今回の対策強化は、メールを大量配信する事業者を主に対象としたものであり、両社が制定するガイドラインに沿った運用を行わない場合はメールが届かなくなる恐れがある。

 本ウェビナーでは、JPAAWG 有志が収集した情報に基づき、今回の対策の概要を説明した後、ディスカッションや参加者の疑問に答えるQ&Aを行った。

 ガイドラインの適用開始は 2024 年 2 月。この喫緊の課題にどう対応すればよいのか…。紙幅の都合上、一部しか紹介できないが、Q&Aセッションでは 30 以上の質疑応答が行われた。

 パネリストとして参加した JPAAWG の有志は、北崎 恵凡(ソフトバンク)、平野 善隆(Vade Japan)、高橋 尚也(TwoFive)、加瀬 正樹(TwoFive)の 4 名。(敬称略)

  [目次]
  ・迷惑メール対策強化ガイドラインの解説
  ・「よくある疑問点」についてディスカッション
  ・Q&Aセッション(参加者の疑問から)

  ※本記事の内容はウェビナーが開催された 2023 年 12 月 13 日現在の情報に基づきます。

迷惑メール対策強化ガイドラインの解説

 最初に、加瀬氏が今回導入される迷惑メール判定の新基準を整理して解説。簡潔にまとめると、「なりすましかどうかを簡単に見極められるように送信してください」あるいは「受信者が要らないと意思表示したメールは送信しない措置を取ってください」ということになる。

 ●Google/米Yahoo!メールの新制限のサマリー
 (2023 年 10 月 3 日スパム削減のための新基準を発表)

 ・5000 通以上の大量送信者は以下の条件を求められる
 - DMARC認証が Pass すること
 - 購読解除可能にすること
 - SPAMレート 0.3 %未満であること
 ・2024 年 2 月 1 日から
 ・詳細は今後発表されていく

 これを満たせない場合は、受信拒否や迷惑メール扱い、流量制限など何らかの制限を行う
 (Google/米Yahoo!にメールが届かなくなるおそれ) 

 以下は、Google社の制限の詳細だが、加瀬氏によると、米Yahoo! も同様の条件、措置が取られるとみて問題ないという。

 大量にメールを配信する事業者とそうでない事業者を区別しており、それぞれ条件が異なる。

出典:https://support.google.com/a/answer/81126

 次に、新ガイドラインに関する FAQ で整理されているいくつかの定義について解説された。

 ● 大量送信者とは…

 ・5,000 通に近い数字かそれ以上のメール送信をしている送信者
 ・ヘッダーFrom のドメインを基準に算出する
 ・カウントする期間は 24 時間
 ・送信対象は個人の Gmailアカウントが対象で Google Workspace 宛は含まない
 ・規制に該当するかどうかは Postmaster Tools で確認可能

 

● DMARCについて…

 ・大量送信者が満たすべき DMARCアライメントは SPF か DKIM のいずれかで可
 (ただし、今後強化する可能性がある為、両方を満たすことを目指す方がよい)
 ・大量送信者が満たすべきポリシーは p=none でよい
 ・大量送信者でない場合は DKIM か SPF のいずれかのアライメントが成立すればよい

 

 ● SPAM送信レートについて

 ・カウントされるタイムフレームは、いまのところ日毎に計算
 ・推奨は、常に 0.1 %未満を維持するように心がける
 (0.1 %未満にしておくとスパイクしても 0.3 %未満に収まりやすいため)
 ・状況を把握する場合は Postmaster Tools を使用する

 

● List-Unsubscribe について

 ・実装が必要なのは商用の宣伝メッセージのみ
 ・パスワードリセットや予約確認、フォームの送信確認などのトランザクションメールは除外
 (本文には宣伝メッセージを混ぜない)
 ・RFC8058 に準拠したヘッダーを実装する必要があり、
 本文中の解除リンクだけでは要件を満たしているとみなさない
 (ランディングページでの解除なども RFC を満たしていないので要件に合致しない)
 ・DKIM署名対象にすることが必要

  

「よくある疑問点」についてディスカッション

● 5,000 通をどう捉えればよいか?

北崎:今回 Google が提示している「5,000」というのは、具体的な閾値の値ではないと考える。そこにとらわれ過ぎないで、あるべき姿を追い求めるほうが良い。

平野:大量送信をする人=5,000 通くらいの意味合い。今後、この目安の数値が少なくなっていくことも考えられるので、5,000 通送っていないから緩めの対策でいいと考えるのではなく、最初から 5,000 通以上の対策を満たすつもりで取り組んだほうがよい。

高橋:5,000 という数字は Google が発表しているものだが、先日の M3AAWG では、「異なる基準を設けると混乱するため足並みを揃える」と言っていたので、同じような制限になるのではないかと推測する。

● TLS はバージョンを気にしなくてよいか?

平野:Google の TLS の説明では、「バージョンが 1.0 から 1.3 まであります」くらいの説明しかしていないので、バージョンは問われていないようにもみえる。しかし、現実的には RFC では 1.2 以上にするよう記載があり、大手企業では 1.2 以下は受け付けないところもあるので、遅かれ早かれバージョンの対応は必要と考える。

高橋:セキュリティ的な理想論でいえば、「脆弱性のあるものは使わない」ということで、「届かなくなる」からではなくて「脆弱性がある」から使わないという判断をしていったほうが良いと思う。

● DMARC は必ず対応か? DKIM は必ず対応か?

平野:SPF は日本でも普及しているが、ヘッダーFROM とエンベロープFROM が合っているかどうか、アライメントの問題も併せて確認する必要がある。そこが合っているとしても、大量送信者に該当する場合は DKIM対応も必要になる。5,000 という通数(閾値)が下げられるかもしれないという話を考慮に入れると、SPF も DKIM も両方やっておかなければならないだろう。

平野:DMARC は、ガイドラインには「p=none でもよい」と書かれているが、そもそも SPF と DKIM がアライメントで両方必要だということになると、もはや DMARC の「p=reject」よりも厳しいので、DMARC よりも先に SPF と DKIM で縛りをかけてきたかなという感がある。

平野:「p=none」であっても、少なくとも Google 宛に対してはそれ以外のルールで「p=reject」とされてしまうので、考え方としては、今のところは「p=none」で大丈夫だが、DKIM や SPF を対策していけば、機が熟したタイミングで、いつでも「p=reject」で運用できるので、「p=none」を書かせるのはその準備もあるのではないかと思う。

高橋:今後、「p=none」から上げないことによるリスクは出てくるかもしれない。Google など受信側の受け取るポリシーが厳しくなっても大丈夫なように準備を進めていったほうがよい。

● ARC は必ず対応か?

加瀬:ARC は、中継サーバーやメーリングリストが主に対応していくことで、企業側で対応する範疇ではないと考える。

平野:メーリングリストや zip暗号化など、中継するところが、ARC をつけて送信者として送る必要があり、ARC の対象は基本的には転送者だが、送信者も「i=0」の署名をつけておく方が良いかと思う。

参加者の疑問に答えるQ&A

 ● 5,000 通はヘッダーFROMアドレス基準?

「5,000 通は、ヘッダーFROMアドレス基準ではないのですか?」

加瀬:公式資料上はヘッダーFROMドメイン。一部で、「Google Workspace の質問をしてアドレスだという回答が来た」という話も聞いたことはありますが、公式見解で言うとドメインだと認識しています。

平野:目的はマーケティングメールをたくさん送っているかそうでないかを区別することで、マーケティングメールはだいたいひとつのメールアドレスから送るので、あまり(サブドメインを)切っていないというのが正解じゃないかと思います。もしアドレス単位ということになると、攻撃者は FROMアドレスを変えればいいだけなので、すぐに破られるようなことをやらないのではないかと思います。

● 拒否はドメイン単位か?IPアドレス単位か?

「カウントはドメイン単位ですが、拒否もドメイン単位でしょうか。あるいは IPアドレス単位で拒否になることはないですよね?」

平野:5,000 通の話だとして、それによって、SPF と DKIM の両方が必要か、片方だけでいいかという条件が変わってくるので、心配ならば両方やっておくのがよいかと思います。

高橋:拒否には SPAMレートも影響してくるという気もしますが、明確な指針が出されていないので、現時点で確定的な回答はできないかと思います。

加瀬:拒否はドメイン単位か IPアドレス単位か…については、転送を考えるとドメイン単位にならざるを得ないのではないかと思います。

● スパムレートを下げる DMARCポリシー設定について

「SPAMレートを下げる手段のひとつとして DMARC の p=quarantine は有効ではない、p=reject は有効だと考えています。どのようにお考えですか?」

加瀬:Postmaster Tools で苦情をもらうという観点で言うと、「p=reject」にするとそういったメールが届かないので苦情にはカウントされないという考え方ですかね。受信箱に届いたものを要らないと言われてしまうのを避ける意味では、「p=quarantine」以上は効果があると思います。

平野:面白い観点ですが、「p=quarantine」だと SPAMフォルダに行くので、SPAMフォルダにあるものをスパムとして報告をしないと考えると、Google の UI的には変わらないとは思います。もちろん、考え方としては今回の対策が普及していけば、「p=reject」にすると、そもそも見えないので、なりすましのほうが多いドメインの場合には、自分が悪者にならなくて済むのではないかと思います。

高橋:補足として、M3AAWG では、いったん受信箱に入ったメールでも、ユーザーがそれを手動で SPAMフォルダに移動をすると SPAMレートを上げる計算に入るという言い方がされていました。

「p=quarantine」とは観点が少し違いますが、いったんトレイに入ったとしても、ユーザーがアクションするとスパムとしてカウントされるという点は注意が必要です。

●「p=none」が NG になる時代が来る?

「DMARC が p=none ではダメな世界はいつごろ到来するのでしょうか。」

平野:いい時代ですね。今回の Google の動きというのは第一歩だと思うので、DKIM、SPF の普及にかなり貢献すると思います。それが普及さえすれば、安心して「p=reject」はできるはずなので、そう遠くはないのでは…。

高橋:「p=reject」の前段階として、どうしても「p=none」で運用をせざるを得ないので、完全に「p=none」が NG になる世界にはならないのではないかと思います。

●外部サービスでは SPFアライメントは失敗する?

「外部のメール配信サービスを使うと SPF のアライメントは失敗するという認識でよいでしょうか」

加瀬:サービス仕様によって、一致しない場合もあるし、一致する場合もあると思います。

外部サービスでは、一般的には当該サービスのドメインをエンベロープに指定するのでアライメント不一致となりますが、一致をさせるために企業側のドメインを指定する機能を持っている場合もあります。

平野:SPF にインクルードするものを記載させるようなサービスは、エンベロープをヘッダーFROM と同じもので送っているので、そういうサービスは大丈夫だと思います。

● List-Unsubscribe で設定する URL はメール本文にも必須?

「List-Unsubscribe では、mailtoプロトコルではなくて、https の URL に対して POST通信をされたら解約処理を通すようにしようと考えているのですが、List-Unsubscribe で設定する URL はメール本文にも必ず含んでいないといけないのではないでしょうか。」

平野:それは自由だったはずです。M3AAWG の質疑応答でも話題になっていましたが、DKIM署名はしないといけないのですが、署名のドメインと一致している必要はないとのことなので、本文にはあるとかないとかは関係なくていいと思います。

● 同一ドメインからのメールで商用メルマガとトランザクションメールが混在

「List-Unsubscribe について。FROM のドメインを見ているということですが、同一ドメインからのメールで商用(広告)のメルマガとトランザクションメールが混在することがあります。その場合、Google側は個々のメールを見て判断する可能性はあるのでしょうか。」

平野:Gmail の中ではトランザクションメールにマーケティング要素を混ぜるなということなので、混ぜた時点でどう扱われるかは Google次第ということになると思います。

● List-Unsubscribe による配信停止の範囲について

「配信元ドメイン単位の配信停止ではなく、配信元メールアドレス単位での配信停止がメインになるかと思います。今回、大量配信者かどうかの判断は配信元ドメイン単位で行われるという認識ですが、ワンクリック配信停止についてはメールアドレス単位で実行できれば問題ないでしょうか。」

平野:そうだと思います。マーケティングメールは受け取らないけれども「お買い上げありがとうございました」メールも受け取らないというわけではないと M3AAWG の中でも話されていたので、それは別物のはずです。

● List-Unsubscribe が RFC に準拠しているかどうやって判断するのか

「List-Unsubscribe が RFC に準拠しているかどうか、実際にアクセスしないと判断できないと思うのですが、さすがに Google が勝手にアクセスはしないと思います。どうやって準拠しているか判定するのでしょうか。」

平野:想像ですが、勝手にアクセスすると Unsubscribe されてしまうので、本当に購読解除されているかどうかは、次に似たようなメールが来るかどうかで判断しているのではないでしょうか。

加瀬:(購読解除したにもかかわらず)2回目に来たら、エンドユーザーが迷惑メール通報をするかもしれないですね。

● List-Unsubscribe による配信停止の範囲について

「今回、大量配信者かどうかの判断は配信元ドメイン単位で行われる認識ですが、ワンクリック配信停止についてはメールアドレス単位で実行すれば問題ないでしょうか。」

平野:そうだと思います。マーケティングメールと「お買い上げありがとうございました」メールとかそういう話だと思いますけれども、マーケティングメールについては受け取らないけれども「お買い上げありがとうございました」メールも受け取らないというわけではないので、というような話は M3AAWG の中でもされていたので、それは別物のはずです。

【参考情報】

M3AAWG送信者のベストコモンプラクティス
https://www.m3aawg.org/sites/default/files/m3aawg_senders_bcp_ver3-2015-02-japanese.pdf

M3AAWG Best Common Practice と日本国内メール配信事業者の取り組み
https://www.iajapan.org/anti_spam/event/2018/conf_18th/pdf/A4-2.pdf

M3AAWG Sending Domains Best Common Practices
https://www.m3aawg.org/sites/default/files/m3aawg-sendingdomains10102019nk-2.pdf

M3AAWG Email Authentication Recommended Best Practices
https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf

《高橋 睦美》

編集部おすすめの記事

特集

JPAAWG(Japan Anti-Abuse Working Group / ジェイピーアーグ)

メールセキュリティ

TwoFive メッセージングのセキュリティ課題に挑むリーディングカンパニー

研修・セミナー・カンファレンス アクセスランキング

  1. ハッカーの OSINT 活用法 ~ 日本ハッカー協会 杉浦氏講演

    ハッカーの OSINT 活用法 ~ 日本ハッカー協会 杉浦氏講演

  2. FFRI 鵜飼裕司の Black Hat USA 2018 注目 Briefings(1)日本はグローバルセキュリティ業界のインナーサークルにいない

    FFRI 鵜飼裕司の Black Hat USA 2018 注目 Briefings(1)日本はグローバルセキュリティ業界のインナーサークルにいない

  3. 総務省 SBOM 対応ノスゝメ

    総務省 SBOM 対応ノスゝメ

  4. 企業のネットワーク管理者必見!Internet Week 2017 セキュリティセッション紹介 第1回「インシデント対応ハンズオン2017」について語る

  5. 自動車サイバーセキュリティコンテスト「Automotive CTF Japan」新たに開催

  6. 安価で導入しやすい AWS や Azure の WAF、その一方でユーザーが抱える運用課題とは? ~ サイバーセキュリティクラウド

アクセスランキングをもっと見る

「経理」「営業」「企画」「プログラミング」「デザイン」と並ぶ、事業で成功するためのビジネスセンスが「セキュリティ」
「経理」「営業」「企画」「プログラミング」「デザイン」と並ぶ、事業で成功するためのビジネスセンスが「セキュリティ」

ページ右上「ユーザー登録」から会員登録すれば会員限定記事を閲覧できます。毎週月曜の朝、先週一週間のセキュリティ動向を総括しふりかえるメルマガをお届け。(写真:ScanNetSecurity 名誉編集長 りく)

×