メールの未来
(fastmail.com)- AIが受信トレイを読み、要約し、タスクまで実行する環境では、送信者検証がメール信頼性の中核条件になる
- SPF、DKIM、DMARCは、サーバー権限、メッセージ完全性、失敗時の処理方針を組み合わせたメール認証の基本構造を成す
- AIフィルタやAI支援ツールがメール体験の標準機能になるにつれ、認証結果はスパム・フィッシング判定や自動処理の重要な入力値になる
- GoogleとYahooが2024年初頭に大量送信者へDMARC設定を要求したことで、認証インフラは安定配信の基本前提となった
- 認証はドメインの身元を確認するが意図までは保証せず、自動化されたメール環境でなりすましのコストと複雑さを高める役割を果たす
メール認証: メールの未来が依存する信頼レイヤー
- メールは長い間スプーフィング問題を抱えており、誰でもメールの「From」フィールドに何でも入れられた
- 以前は注意深いユーザーであれば、微妙に異なるドメイン名、現実味のない緊急性、不自然な言い回しといった手がかりから問題に気づけた
- AIの利用が広く普及するにつれ、ユーザーがメールを扱う方法は変わっており、メッセージが届いたかどうかよりも、その出所を実際に検証できるかどうかが重要になっている
- ほとんどのメールユーザーが意識する必要のなかった標準が、静かにメール体験の土台として定着している
メール認証とは何か
- メール認証は、SPF、DKIM、DMARCという3つの連動する標準で構成される
- SPFは、メッセージを送ったサーバーがそのドメインを代表して送信する権限を持つかを確認する
- DKIMは、各メッセージに暗号署名を付け、受信サーバーが転送中に変更されたかどうかを確認できるようにする
- DMARCはSPFとDKIMを束ね、検査に失敗したメッセージを拒否するか、隔離するか、通過させるかを受信サーバーに指示する
- これら3つの標準により、銀行や勤務先から送られてきたように見えるメッセージが、本当にそのドメインから来たものかどうかを受信トレイが判断できる
- 認証がなければ、スプーフィングされたメッセージと正当なメッセージを区別できず、メールとの関わり方が変わるにつれてこの問題はさらに大きくなる
AIがメールに関わる方法
- メール体験では2種類のAIが標準機能として定着しつつある
- 1つ目は、スパム、フィッシング、注目すべきメッセージを判断するAIフィルタリングである
- こうしたシステムは何年も前から存在するが、現代版ははるかに強力になっている
- 認証結果は、AIフィルタが判断を下す際にますます中核的な入力値になっている
- 2つ目は、受信トレイを要約し、タスク項目を浮かび上がらせ、返信の下書きを作り、ときにはユーザーに代わって行動するAI支援ツールである
- Fastmailは受信トレイにAIを統合しておらず、ユーザーのメールがバックグラウンドでモデル処理されることはない
- MCPサーバーは、ユーザーが明示的に承認した場合に、選択したAIクライアントと接続できるAPIエンドポイントである
- ユーザーが接続しなければ、何も変わらない
- より広いメール環境では、受信トレイ内で自律的に行動するAI支援ツールがますます一般的になっている
- 人が不審なメールを読む場合、送信者ドメインに余計な文字があるとか、依頼内容が不自然だといった点に気づける
- AI支援ツールは対応が必要な項目を探し、内容と緊急性を読み取って、それに応じて行動できる
- 説得力のあるスプーフィングメッセージであれば、メールが受信トレイに届く前に認証がそれを防がなければならない
認証はインフラになりつつある
- GoogleとYahooは2024年初頭、大量送信者が安定してメールを配信するにはDMARCを正しく設定することを求め始めた
- この変化により、認証は送信者が後回しにできる項目から、受信トレイに届くための基本前提条件へと変わった
- メール認証は、WebでHTTPSがたどった道と同じ方向へ進んでいる
- HTTPSはベストプラクティスから期待事項へ、さらにインフラとして定着した
- ブラウザのアドレスバーにある鍵アイコンが正確に何を意味するのかを知らなくても、Webサイトに鍵がなければ無視できない警告サインになる
- 新しい標準はこの認証基盤の上に構築されている
- BIMIは、検証済み送信者が対応する受信トレイにロゴを直接表示できるようにする
- コンテンツだけではAI生成フィッシングを見抜くのがより難しくなっている時代において、小さいながらも視覚的な信頼シグナルとなる
- DKIM設計は、実験的なARC仕様から得られた教訓をもとに再検討されている
- 複雑なメールフローで変更を追跡し、帰属を明らかにすることで、フィルタリングシステムが悪意あるコンテンツの発信源を判断できるようにする
- 誤った主体の評判が損なわれるのを防ぐのに役立つ
認証だけでは十分ではない
- 認証はドメインの身元を確認するが、意図までは確認しない
- もっともらしい類似ドメインと正しく設定されたDMARCレコードを持つ詐欺師は、送信者認証チェックを通過できる
- 認証はなりすましのコストと複雑さを大きく高め、メールの未来がより自動化されるほどこの点は重要になる
- 未来の受信トレイは、今日ほとんどのユーザーが使っているものより速く、賢く、多機能になる
- 認証は、その未来を単に便利なだけでなく信頼できるものにする要素である
- 標準は何年もかけて成熟してきており、メールがさらに自動化される中で、この基盤の上に構築し続けることが必要である
メールはなくならない
- 誰にとってもメールは必要であり、銀行は明細書を送り、医師は予約情報を送り、ほかのサイトはパスワード再設定を送る
- 誰もがメールを持っている
- 技術の寿命を示す最良の指標は、それがすでにどれほど長く存在してきたかであり、メールは長い間存在してきた
- Fastmailは未来のメールを支える標準開発の最前線におり、すべての人にとってより良いメールを作るため、メールとともに進化し続ける
1件のコメント
Hacker Newsの意見
これが実際にどれほど役立つのかは判断しづらいが、メールがより安全になって、組織、特に銀行・政府・保険会社がクローズドなセキュアメッセージボックスのような代替手段を作らなくなる方向なら歓迎する
「セキュアメッセージセンターにログインしてください」と言っておきながら、そこでは体裁もひどいメッセージを短期間だけ閲覧でき、その後は永久削除されるような仕組みだ
自分の受信トレイはある程度検索可能な人生の記録なのに、こうした代替手段はそれを壊してしまう
たとえば保険会社はHIPAAに従わなければならず、健康関連情報はHIPAA準拠の別システムにしか送れない
そのためにはそのシステムとBAAという契約を結ぶ必要があるが、メールでは現実的に不可能だ
保険会社が世界中のすべてのメールホストと契約することもできないし、メール送信後に最終的にどこへ届くのかも分からないからだ
健康情報を含むメールとそうでないメールを正確に切り分けるのも非常に難しく、人名やIPアドレスですら文脈次第で該当しうる
だから結局、すべてをメッセージセンターに送ることをデフォルトにしており、メールのセキュリティがどれだけ向上してもこの点は変わりにくい
ソーシャルネットワークで友だち追加するように、送信者を事前承認する方式であるべきだ
医療クリニックが法廷で不利になりうるメッセージを削除するのも見たことがある
だからそういうものを送る相手には、本物のメールで送ってくれと言っている
しかも別途メールも送ってくるので、時々それを別のメッセージだと思ってまたログインしてしまう
「このメッセージをPDFでダウンロード」というボタンもあるが、実際にはWebブラウザのラッパーに移動するだけだ
来週ごろ届くとのことだった
いろいろコンプライアンス上の理由はあるのだろうが、まったく筋が通らないと感じる
記事を読み進めて最後まで来て驚いた。全体が何かの発表や新しいもののための序論のように感じられたのに、何も出てこなかった
自分が鈍いのかもしれないが、それで核心の結論が何だったのか分からなかった
会社が明るい未来を語り始めるたびに、たいてい自分のユーザー体験が近いうちに悪化するという意味だった
実際には「これからはDMARCを通過しなければならない」という話だが、それはもう2年前から事実だった
認証が偽装ドメインを防ぐ助けになるという話も正しいが、最大の問題は偽装ドメインではないと思う
攻撃者は、PayPalやStripeのような決済プラットフォームにメールを送らせる方法を見つける
生成されるメールにどんな情報が入るかを把握したうえで、会社名を「問題がありますのでこの番号に電話してください」のように設定する
すると実際にPayPalから届いた、すべての認証を通過する正規メールの件名や本文にその会社名が入り、緊急性があるように見える
こうしたメールは実在の企業から送信され、認証もすべて通過するので、DMARCでは防げないし、最近の攻撃者はまさにこういうやり方をしているのを見ている
Fastmailがこの問題に対処する何かを出してくれることを本気で期待していた
要約するとこの程度だ。どうやってそこに到達するのかは分からないが、メールはより速く、より賢くなるという話だ
正直、なぜこの記事が投稿されて支持を集めているのか気になる
Fastmailは好きだ。数年前にProtonから移ったが、暗号化メールのトレードオフはそれだけの価値がないと判断したからだ
Protonを完全に信頼していたとしても、ほとんどのメールは結局AWS、Outlook、Gmailを行き来することになる
Fastmailのサービスには非常に満足している。価格も妥当で、大きな受信トレイでも非常に速く、不要な機能や肥大化を追加しない
もともとはOS標準のメールアプリを使うつもりだったが、FastmailのアプリとWebサイトが良かったので結局それだけ使っている
30年間Webメールを使って身についた筋肉記憶が、この「アプリ」のせいで無意味になった
どこかのWeb開発者がデスクトップアプリ開発者の真似をしたかったのだろう
ミスではなく、前のページに戻るキーボードショートカットを意図的に入れないという選択だったそうだ
カスタマーサポート担当者は、これを「機能要望」として追加しておくと言っていた
私たちは実質的にメールの判断をAIに外注しつつ、SPF/DKIMを強化して補おうとしている
錠前をより頑丈にしながら、マスターキーはもっと多く配っているようなものだ
Fastmailがメールについて絶対的な権威を持っているかのように語ることはできない
Fastmailはメールそのものではなく、メールに依存するサービスだからだ
受信トレイを移して望むプロバイダーへルーティングできるようになるまでは、こうした認証スキームは大規模では実際の価値を持ちにくいように見える
電話番号を移せるのなら、理論上はメールアドレスも移せるべきだ
ここで挙げられている認証システムは、そうした移動性を可能にするほど十分に役立っていない
どのプロバイダーを使うにせよ、メールのドメイン名ではなく人そのものを認証する有効な方法が必要だ
つまり、ホスティングプロバイダー自体に代わって署名できる標準が発展する必要がある
2026年になってもメールの署名と暗号化が標準でないのはおかしい。
だが大手メール事業者のビジネスモデルが、私たちがそれを使わないことに依存している限り、おそらくこのままだろう
受信トレイを実用的なものにするにはあらゆる機械学習処理が動く必要があり、そのためにはメールが暗号化されていては困る
そうでなければ、MicrosoftがOutlookデータを1000のパートナーと共有するのはもっと難しかったはずだ
暗号化メールはもっともらしく聞こえるが、実際の脅威を考えると、現状と比べて保護できるものはそれほど多くなく、失う機能は多い。
基本的な前提として、メールはすでに自分のコンピューターからメールサーバーまで、自分のメールサーバーから受信者のメールサーバーまで、受信者のメールサーバーから受信者のコンピューターまで暗号化されている。
自分と受信者以外で見られる主体は途中のメールサーバーだけで、暗号化メールで得られる最善の結果も、この過程で重要な役割を持つ一部の主体を外す程度にすぎない。
とりわけメールヘッダーは引き続き公開されるため、最善の場合でも非常に私的な通信にはならない。
一方で暗号化メールは、サーバー側フィルタのような処理を壊してしまう。スパム処理も同様で、とくにスパムフォルダーにすら届かない大量のスパムを考えると、実用的な解決策がない。
ユーザーはWebメールにログインしてすぐメールを読めることを期待しており、Webメールは支配的なメールクライアントだ。
これを解決しようとしてサーバーに鍵を渡せば、サーバーが再びメールを読める主体となり、現状と何も変わらなくなる。
さらに大きな問題は鍵配布だ。メールを送るには受信者の鍵を見つけなければならないが、大規模で最も実用的な方法はメールサーバーにそのユーザーの公開鍵を問い合わせることだ。
ところがそのサーバーは、そのユーザー宛てのすべてのメッセージを傍受できる唯一の主体でもあるため、自分の鍵を返して復号し、再度ユーザー向けに暗号化しても、発覚しにくい。
PGPキーサーバーのような代替策も機能しない。PGP暗号化に関心のあるユーザーが100万人にも満たなかった時代でさえ、PGPキーサーバーのエコシステムは数年前に崩壊しており、数十億人のメールユーザー規模とは比べものにならない。
暗号化メールはメール事業者のビジネスモデルのせいというより、メールのアーキテクチャ自体がすでに十分まともなセキュリティを提供していて、追加の暗号化の利点を生かすのが非常に難しいため、実現性の低い夢に近いと思う
優れたユーザー体験と優れた暗号化を備えたシステムであるべきだ
記事では、メール転送でDKIMが壊れないようにしようとした失敗したARC提案にも触れている。
https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
GoogleがARCから別の方式へ移るよう説得できるのか興味深い。
最近のGmailはメールサーバーの評判を非常に重視しており、気に入らないメールサーバーを一貫して不利に扱える
「2つ目はAI支援だ。受信トレイを要約し、アクション項目を提示し、返信を下書きし、場合によってはユーザーの代わりに行動するツール群」
この部分がいちばん邪悪だ。結局はボットがボットと会話し、人間が外れる構図になる。
メールの問題はすべてGPGで解決できるが、そうなるとFastmailのようなメールサービスのビジネスは成り立たなくなる。
ユーザーのメールを読んで分析できず、広告も打てず、ユーザープロファイルを広告会社に売ることもできず、ユーザーデータでAIを学習させることもできないからだ。
私が見たいメールの未来はそちらだ。残念ながら誰もGPGを使わず、人に教えるのもかなり難しい
通信が本物だと証明する唯一の方法は、対面で事前に鍵交換する方式になるだろう。
GPGはその一つの道にすぎず、誰かが組織レベルで簡単にできる方法を出してくるはずだ
分析ではメッセージ内容よりメタデータのほうが価値が高い。GPGはそれをどう解決するのか？
この記事がJMAPについてのものだと期待していた
本文暗号化ではないが、標準的なメール環境にもまだ改善の余地があることを示している
趣味プロジェクトでは、あらゆるルールを守って正しいヘッダーを入れてもメールを送れないのがもどかしい。
jeremyevansの自前メールホスティングの記事は面白く読んだが、受信についてだけで送信は扱っていない。
https://code.jeremyevans.net/2021-07-29-running-my-own-email...