メール配信性に関する詳細分析
- 1971年10月、MIT卒業生のRay Tomlinsonがネットワークを通じて最初のメールを送信した。
- 昨年は約121兆通のメールが、約43億人の間で送受信された。
- メールは地球上で最も重要な書面コミュニケーション手段であり、近い将来もそうあり続けるだろう。
概要
- 2023年10月3日、GoogleとYahooは、スパム、フィッシング、マルウェアの試みを防ぐための新しいメールセキュリティ標準を発表した。
- メールサービスプロバイダーがこれらのポリシーを施行するにあたり、メール配信性に関するガイドラインの順守が必須となっている。
- 最大の変化は、SPF、DKIM、DMARCといったメール認証標準の実装である。
- Gmailでは、認証されていないメールはブロックされる。
影響を受ける人々
- 主に大量送信者が影響を受け、SPF、DMARC、DKIMを自分たちのドメインで有効化する必要がある。
- 大量送信者でなくても、ガイドラインに従わなければ影響を受ける可能性がある。
タイムライン
- Googleは2024年2月から、大量送信者にメール認証を求めている。
- Yahooも2024年第1四半期から同じ要件を適用している。
ガイドライン
- 送信者認証: SPF、DKIM、DMARCのようなメール認証プロトコルを実装する。
- 大量送信者の要件: スパムフィルタリングやレピュテーション低下を避けるため、不要な大量メール送信を避ける。
- 簡単な配信停止: 配信停止オプションを簡単に実装する。
- エンゲージメント: 誤解を招く件名、過度なパーソナライズ、スパムフィルターを誘発する販促コンテンツを避ける。
送信者認証
- SPF、DKIM、DMARCは、組織のメールを保護するのに役立つ3つの認証標準である。
- これらの標準を適切に設定することで、攻撃から保護し、配信性を高め、メールがスパムフォルダではなく受信トレイに届くようにできる。
影響
- Googleはアルゴリズムとユーザー報告データを継続的に更新し、メールフィルタリングとユーザー体験を改善している。
- 新しいセキュリティガイドラインが、メール配信性とエンゲージメントに与える影響を明らかにしている。
ツール
- メール衛生の設定、確認、維持管理に役立つ無料のオンラインリソース一覧を提供している。
実装
- これらのガイドラインを実装することは、リソースが限られた小規模組織にとって課題になり得る。
- メール認証を実装するために、サービスプロバイダーのリソースやサポートを参照する。
ボーナス
- ハッカーがメールセキュリティの脆弱性を悪用するいくつかの方法を紹介している。
GN⁺の意見
- この記事は、メールセキュリティに関する最新標準を順守する重要性を強調している。これは、メールによるコミュニケーションの信頼性を高め、スパムやフィッシングのような脅威からユーザーを保護することに寄与する。
- メールサービスプロバイダーが新しいセキュリティ標準を施行する中、組織はこうした変化に適応し、順守するための取り組みを進める必要がある。これは、特にプライバシー保護とデータセキュリティに敏感な時代において、いっそう重要である。
- この記事は、メールマーケティングに関わる事業を運営する企業にとって特に有用かもしれない。メールマーケティングは今なお多くの企業にとって重要なマーケティングチャネルであるため、メール配信性を維持することは成功するキャンペーンに不可欠である。
- メール認証標準の実装は技術的な課題になり得る。特に、SPF、DKIM、DMARCのようなプロトコルに初めて触れる組織にとっては難しい可能性がある。これらの標準を導入する際には、技術的支援とリソースが必要になる場合があり、時間とコストを要することがある。
- この記事は、メールセキュリティを強化したい組織に有用なガイドラインとツールを提供することで、メールシステムの脆弱性を補い、ユーザー体験を向上させるのに役立つ可能性がある。
1件のコメント
Hacker Newsの意見
「Gmail」「Outlook」「Yahoo」のようなメールプロバイダが持つ影響力を見ると、企業を狙った別の攻撃として、標的型の到達失敗が可能なのではないかと以前から気になっていた
被害者、特に企業・メーリングリスト・NGOに、攻撃者が所有するアドレス宛てへ大量のメールを送らせ、攻撃者は Gmail/Yahoo/Outlook 上でそのメールをスパムとして報告する
すると AIスパムフィルタ がそれを新たなスパム活動として学習し、その後は実際の顧客向けメールまでスパム扱いしたり、到着前に削除したりする可能性がある
1年ほど経てば、その会社は四半期ごとに損失を出し、広告部門はメールエンゲージメント低下の理由がわからず、技術部門は混乱に陥るかもしれない
大企業なら持ちこたえるか、メールを完全に諦めることもできるだろうが、小さな会社や NGO・政治系メーリングリストは、寄付減少のような打撃を受ける可能性がある
正直、攻撃経路としては可能性が低いとは思うが、ずっと頭に残っていた考えだ
スパマーは正当なテンプレートをメール内に見えない形で埋め込み、実際の詐欺文面は数行だけ見えるようにしていた
フィルタにメールの大部分を正常と判断させて通過させようとする手口で、最終的にユーザーが十分にスパム報告をすると、テンプレート自体 がブロック要因になる
そうなるとスパマーは、まだフィルタを通過できる次の被害者のメールテンプレートへ移り、最初の被害者は自分のメールがどこにも届かなくなる後始末を背負わされる
株主価値最大化を掲げる大企業でひどい体験をしたので、昔のメール履歴を掘り返して、その会社からのあらゆるコミュニケーションをスパムとして報告した
一滴にすぎないかもしれないが、スパムの世界ではそれほど多くの票は必要ないかもしれない
メール配送はやがて、より露骨な 有料通過モデル へ進化していく気がするし、すでに水面下で合意があるのかもしれない
そのドメインが通報されても、トランザクションメールはメインドメインから送り続けられる
もちろん、2つのメールサーバが別々の IP にあることが前提だ
サイト側で配信停止はできるが、メールクライアント側ではスパム扱いしないでほしいということだ
小さな組織にとってはかなり現実的なリスクかもしれない
大きな組織がどう緩和しているのかはよくわからない
攻撃者が送ったメールが SPF/DKIM に失敗するなら、Gmail がそもそもその偽メールを配送しないように DMARC ポリシーを設定できる
そうすれば、その種の攻撃は成立しない
この変更は必要だったし、あまりにも遅すぎた
大量のメールを送るドメイン所有者に対してメッセージ署名をきちんと求めれば、受信者は IP アドレスのレピュテーションではなく、ドメインレピュテーション に基づいて良いメールと悪いメールをより明確に区別できる
ますます多くのドメインが、トランザクション系・マーケティング系サービスの共有 IP 空間を通じてメールを送る状況では、レピュテーションを送信ドメインに安定して結び付けられる能力は、悪用を減らすのに非常に有用だ
Google は 1 日 5,000 通以上送る場合にのみ新要件が必須だと言っているが、それは嘘だ
私は多くても1日数通、通常の Gmail アカウントでは1日1通も送っておらず、要件の一部しか実装していなかったのに、Google が私のメッセージを拒否し始めた
結局、やや重複している要件まですべて実装するために時間を無駄にする羽目になった
全体としては前向きな変更だと同意するが、メールがスパムフォルダに入る理由が受信側の設定ミスにあると、本当にやりきれない
たとえば転送の過程で SPF が壊れることがある
悪意ある送信者がメールごとに異なる IPv6 アドレスから送れるなら、新しく見える IPv6 アドレスは基本的にすべて信頼しないようにすべきかもしれない
不便さはあるが、この変更がメールエコシステムを整理してくれることを望む
スパムは悪意あるコンテンツと区別できない
その「ニュースレター」に登録した覚えはなく、メールアドレスが収集され、あなたを悩ませようとする悪意ある主体に渡っただけだ
何かをクリックすれば、その会社があなたの情報を持ち、あなたの利益をまったく考慮しないWebサイトへ誘導される
最善でも受信トレイのゴミの発生源を1つ取り除けるだけで、最悪の場合はコンピュータにマルウェアを入れる何かをクリックしてしまう
だから 配信停止リンクはクリックせず、スパム報告ボタンを押し、スパム報告を無視する大手メールサービスの利用をやめるべきだ
Gmail は、他の大企業があなたにスパムを送りつけることを許しながら、ドメイン全体を自分でブロックする選択肢すら与えない
プライバシーとセキュリティを真剣に扱うメールプロバイダに移るまで、悪意あるコンテンツは受信トレイに入り続けるだろう
どのメールサービスプロバイダを使っているのか気になる
ワンクリック配信停止 のテストを通過できない大企業がこれほど多いのは驚きだ
Cloudflare や Akamai が接続を遮断したり、ページの読み込みに 5 秒以上かかったり、ログインやメールアドレスの再入力を求めたりする
それでいて顧客がスパム報告ボタンを押すことに驚くべきではない
だからスパム報告を押す
いちばん腹立たしいのは、メール送信者が広告ブロックリストで遮断されるドメインで クリック追跡 をしていることだ
そういうリンクをコピーして貼り付けるための別のブラウザインスタンスを用意しているが、そうするとまたログインしなければならない
リンクをクリックするより、配信停止メールを送るほうを好むし、Gmail ならこれを自動化できる
数日以内にまたメールが来たらスパムとして表示する
TripAdvisor は AI 生成の旅行日程を作れるのなら、それをメールで送らない方法も見つけるべきだ
顧客は配信停止でもスパム報告でも、より楽なほうを選ぶ
4 月の変更で壊れるもののひとつは、メールサービス間の 転送 だ
たとえば以前の大学のアドレス foo@school.edu から個人の Gmail アカウント bar@gmail.com に転送しているなら、もう動かなくなるだろう
主要プロバイダーが押し進めているところを見ると比較的まれな利用例なのだろうが、影響を受ける人にはかなり厄介な変更だ
メールを転送するとき、転送側がメッセージ内容を変更しない限り DKIM 署名とは依然として一致するので、通るはずだ
SPF は常に、エンベロープの送信者アドレスを触らない転送者を壊してきたし、それは正しく適切なことだ
それでもメール転送は可能だが、転送側が return path を書き換えなければならない
SPF、DKIM、DMARC が完璧に設定されていないのに、誰かがメールを通せていたことに驚く
私は数年間、きちんと設定した セルフホストの個人メールサーバー を運用してきたが、それでも通過させるのに時々苦労してきたし、それでも少しずつ良くなっている気がする
とくに Microsoft のサーバーは、何の問題もない DKIM 設定 を理由もなくランダムに失敗扱いすることが多い
送信量が少ないと、よく知られた送信者ではないというだけで捨てられる危険がある
大手 3 社がこうしたガイドラインを公開して透明化したのだから、動作がもっと一貫することを願う
スパマーも参入障壁が低いので同じことができる
重要ではあるが、現実世界の 到達性 とは関係が非常に薄い
DMARC でいちばん厄介なのは、とくに Microsoft で頻繁に失敗する点だ
そして受信者がメールを転送するあらゆるユースケースでも問題が起き、その際に SPF アラインメント が壊れる
ベストプラクティスに従いたくて、最近 p=quarantine を p=none に変更した
DKIM と SPF を正しく設定していても、正当なメールが DMARC を通過できないのではないかと怖かったからだ
p=reject を本当は使いたいが、受信者がメール転送で DMARC が壊れる同じ例外状況を処理できるように受信メールサーバーを修正するまでは使えない
DKIM 署名されたメッセージを転送しても DMARC はまったく壊れない
最悪なのは、メールを受け取っておきながら黙ってスパム扱いし、意図された受信者が決して見られない場所に入れてしまうことだ
Google の Gmail がこれをいちばんひどくやる
企業メールはもはやメールではなく、Facebook のような 壁に囲まれた庭 でありサイロだ
そうでなければコールドメールのスパムに溺れていただろう
真面目な話、自前サーバーの運用と管理をあきらめて、すべての会社で Gmail を使っている
これがここまで難しくなったのは悲劇だ
きちんと設定された Gmail Workspace の上に乗っていないと、正当なメールでさえ通る可能性がないように感じる
私の理解では、スパマーにメッセージが正常メールかスパムか判定されたという シグナル を与えたくないのだと思う
スパマーが実際にそうした情報をどれほど賢く活用しているのか知りたい
ほとんどのスパムは、失敗フィードバックを考慮せずにひたすら打ち続ける試みのように見える
私のメールサーバーでは、ジャンクに分類されたメッセージを通常のエラーメッセージとともに引き続き一時拒否している
少なくとも誤分類された正当な送信者には遅延 DSN が届き、最終的にメッセージが受信されなかったというフィードバックを受け取れる
多くのメールサーバーやサービスは、誤分類された正当なユーザーに有用なシグナルを与えることよりも、スパマーにシグナルを与えないことを重視しているようだ
もしかすると自分たちの分類が非常に優れていて、誤分類しないと思っているのかもしれない
Gmail のスパムフィルターとプロモーションフィルターは、ユーザー視点では 99% 以上 信頼でき、誤検知も本当に少ない
B2B では、あなたのメールアドレスを知っているマーケターなら好きなだけメッセージを送る権利があるも同然だ
壁がなければ完全に使い物にならなくなっていただろう
私用のVMがあるRBLに載ってしまったが、/24 アドレス空間全体がブラックリスト入りしていたのが原因だ
誰かがスパムを送ったらしく、今では週にメールを3通ほど送るだけの自分のマシンまでブロックされている
スパマーがその範囲内の任意のアドレスを使った可能性もあるし、誰かがリレーを許可するよう誤設定されたSMTPサーバーを立てた可能性もある
顧客IP範囲で送信SMTPサーバーを運用するのは、どうせ問題になりやすい
そうした範囲は、スパマーが評判を気にせず使うため、すべて疑わしく見られがちだ
ブロックリスト運営者は悪用報告の検証があまりうまくないか、ネットワーク運用者に対処させるために巻き添え被害を起こしているように見える
ブロックリストに載るのは困るが、インターネット全体には正味でプラスの効果があるのかもしれない
メールサーバーやサービスはIPベースのブロックリストを誤って使っていると思う
複数あるシグナルの1つとして使い、初めて見る送信者には重みを大きくすることはできる
しかし、SPF/DKIM/DMARCで認証され、これまで継続的にやり取りしていたIPが突然ブロックリスト入りしたなら、以前の良好な評判のほうがそのブロックより強くあるべきだ
既知の相手とは通信を継続できるべきで、相手側がそれをスパムとしてマークして初めて、その後の配送を拒否したり迷惑メール扱いにしたりできるべきだ
現状では、多くのメールサーバーやサービスがシステム負荷を下げるため、SMTP処理の早い段階でIPブロックリストを適用しているように見える
システム負荷には良くても、分析性能には悪い
全体として、大手フリーメールサービスでさえ、正常メールかスパムかの判定に既存の評判を活用する能力はあまり高くないように見える
最近、自分が作ったオンラインWebサービスをメールベースの登録方式に変えたが、メーリングリストへの参加のように、特定のアドレスへメールを送って登録する仕組みだ
狙いは、ユーザーが自分のサービスにメールを送れば、自分がそのユーザーの既知の相手一覧に入ることだ
そうなれば、自分のメールサーバーが送るSPF/DKIM/DMARC整合済みの確認返信は、当然受け入れられるはずだ
これ以上に明確なオプトインがどれほど必要なのかと思う
いくつかの大手フリーメールで試したところ、Yahooは元のメッセージを参照する確認返信ですら迷惑メールフォルダに入れた
大手メールサービスと競争できないと思っている人に言うと、基準は思っているほど高くない
評判を回復するのは、うまくやっても悪夢に近い
メインドメインを守るために別ドメインを買ってそちらからメールを送れ、という提案も見たが、あまりやりたくはない
本文ではエンベロープ(RFC5321) と ヘッダー(RFC5322) を混同して使っているようだ
「メールのエンベロープヘッダーのFrom:フィールドにあるドメイン名が検査され、SPFやDKIMで認証された別のドメインとアラインされる」とあるが、エンベロープにヘッダーはなく、ヘッダーはメールのコンテンツ/本文内にある
「すべてのメールセキュリティ指針を通過する組織のメールエンベロープ例」というスクリーンショットも、エンベロープ情報ではなくメールヘッダーだ
この話題については、dmarc.orgの優れたプレゼン資料がある
https://dmarc.org/presentations/Email-Authentication-Basics-...