第2世代メールについての公開的な考察

Note: この記事は単に自分の考えを整理したもの。深く考え抜いたものではなく、良いアイデアだと思う必要もない。期待値をできるだけ下げて読んでほしい。

メールの問題点

• 多くの古い技術が今も使われているが、メールは使うたびに私をいら立たせる。
• ユーザーの立場から見ると、メールはかなりうまく機能している。時々スパムで大量のメールが送られてくることはあるが、メールは古くて信頼でき、理解しやすく、検索も比較的しやすい。
• しかし、メールのバックエンドはひどい。

メールバックエンドの問題点

• 多くのメール機能には明確な仕様がない。たとえば、返信を送るときにメッセージの上に返信を書くのか下に書くのかが明確ではない。
• メールにどんなHTMLを入れられるのかも明確ではない。Microsoft OutlookがMicrosoft WordのHTMLレンダラーを乱用している場合もある。
• メールを暗号化する方法も明確ではない。OpenPGPというものを発明したが、ほとんど使われず、大きな欠陥がある。
• メールの真正性を常に確認できるわけではなかった。そこでSPFが発明されたが、SPFもすべての問題を解決しなかった。そこでDKIMが発明されたが、DKIMもすべての問題を解決しなかった。そこでDMARCが発明されたが、DKIM自体に大きな欠陥があるためDMARCも回避される。
• BIMIという別のレイヤーも追加されたが、これもDMARCに依存し、DMARCはDKIMに依存しており、DKIMには欠陥がある。
• DMARCがある場合でも、68.2%のレコードは p=none に設定されている。これはDMARCが基本的に何もしていないことを意味する。
• 上記すべてと攻撃的なスパム対策ポリシーのために、セルフホストのメールは非常に難しい。
• 最後に、IPレピュテーション管理の問題がある。あるIPアドレスは他のアドレスよりも「クリーン」と見なされる。特にSendGridやAWS SESのような共有システムではそうだ。これは大量メール用アカウントの登録を複雑にし、正当なメールがスパムに分類されることも多い。

第2世代メールについての仮説

• 新しいDNSレコード MX2 を作成する。ほとんどのメールサービスは MX2 と MX レコードを持つようになり、古いサービスは MX だけを持つ。
• 20年前の古いメールクライアントがメッセージを送ろうとすると、MX レコードを探してメッセージを送る。現代的なクライアントは MX2 を見てメッセージを送る。
• MX2 を実装したメールサービスは公開日を掲示し、その日以降は MX レコードに送られたすべてのメッセージをスパムとして自動分類する。

第2世代メールの優先事項

1. メール向けの標準化されたHTML仕様と適合性テストスイートを提供する。
2. メールスレッドの好み、またはその他のメール関連の設定のためのヘッダーを提供する。
3. HTML表示とともに、テキスト専用の非HTMLコピーも提供する。
4. すべての MX2 レコードは公開鍵を含む必要がある。
5. メールの真正性と完全性を確認するためにハッシュを生成し、それを暗号化してヘッダーに追加する。
6. SPF、DKIM、DMARCを廃止し、MX2 レコード1つに標準化してセルフホストのメールスタックを簡素化する。
7. IPアドレスではなくドメインに対してメールを認証する。
8. MX2 を実装するクライアントは、OpenPGPを置き換えられる新しい暗号化スキームを選択できる。

追加の考え

• 大容量ファイルを共有できる方法が必要だ。
• GoogleとMicrosoftが参加しなければ、MX2 は決して実現しないだろう。
• SMTPをHTTPと標準化されたREST API、そしてJSONボディで置き換えることも検討できる。
• HTMLを使うこと自体が論争の的になりうる。メールはもともとHTML向けに設計されていない。
• 新しい標準を厳格に施行できる機会がある。

GN⁺の意見

• メールシステムの複雑さとセキュリティ問題を解決しようとする試みは非常に興味深い。特に、メールの真正性と完全性を保証する新しい方法を提案している点は有用だろう。
• しかし、新しい標準を導入するのは非常に難しい。特にGoogleやMicrosoftのような主要プレイヤーの参加が不可欠だ。
• HTMLの利用をめぐる論争は依然として存在する。セキュリティ問題を解決するために、別のマークアップ言語を検討する必要がある。
• 新しい標準を厳格に施行するのは理想的だが、現実には難しいかもしれない。標準のドリフトや実装ミスを防ぐための追加メカニズムが必要だ。
• メールシステムの中央集権化は新しい標準の導入には役立つかもしれないが、同時に特定企業への依存を強める可能性もある。

[cometkim]

少なくともレンダリング改善に関しては、Google と Microsoft はすでに投資していますね……どちらも AMP Email プロジェクトに参加し、支援していましたから。

[coremaker]

JSON のようなデータ標準を作るのは良いことですが、
レンダリング仕様もあわせて議論しなければならないため、簡単ではなさそうです。

HTML が選ばれた理由も、
HTML+CSS のレンダリング仕様にただ乗りするためではなかったのでしょうか？

[ldmsys]

すでに上の方々が極端な事例としてShop Mailを挙げてくださいましたね。個人的には、すでにうまく回っているプロトコルを公然とdeprecatedに分類し、（互換性のない何らかの新しい）プロトコル標準だけに対応するようにすること自体に、かなり懐疑的です。

[unsure4000]

4. すべての MX2 レコードは公開鍵を含まなければならない。
   これが少し腑に落ちないのは、サービス提供者がこの公開鍵をユーザーが提出した公開鍵ではなく、自分たちが作成した公開鍵にするのではないかと思える点なんですよね...

[iolothebard]

そこで私たちはメールを挿した…（えっ？ それじゃない…）

[xguru]

メールシステムは便利で良いのですが、本当に段階的なプロトコル改善が必要だと感じます。
この先何十年後もこの方式で使い続けるのはちょっと…

[GN⁺]

Hacker Newsの意見

Hacker Newsコメントまとめ要約

• メールシステムの複雑さと相互運用性

  • インターネットメールサービスの運用経験に基づくと、メールシステムは複雑だが広く採用されており、相互運用性にも優れている。
  • 新しいシステムの導入は、既存システムに対する莫大なR&D投資と競争しなければならないという難しさがある。
  • 新しいメールシステムを提案するなら、IETFやM3AAWGのような場で提案するのがよい。

• メールの曖昧さと問題点

  • メールヘッダーに重複または矛盾する値があることで混乱が生じることがある。
  • ASCIIのみを使うべきヘッダーに8ビット値が含まれる場合の問題など、さまざまな問題が存在する。
  • メールスレッド管理の方式も標準化されておらず、問題を引き起こす。

• メールの中央集権化の問題

  • メールの中央集権化は望ましくない。企業は人類にとって最善ではなく、自社に有利な方向へ行動する可能性が高い。
  • セルフホストのメールは難しくなく、信頼できるプロバイダーを通じて容易にホスティングできる。

• HTMLメールの問題点

  • HTMLメールはフィッシングや詐欺などの問題を引き起こしうる。
  • メールを再設計するならHTMLを排除し、Markdownのような形式を使うのがよいだろうという意見。

• メールの非同期性を維持する必要性

  • メールは非同期であるべきであり、これは24時間勤務を防ぐ最後の技術的防衛線である。
  • 人々がより良いシステムを採用しない理由はこれにある。

• メールサーバー運用の難しさ

  • メールサーバーの運用はますます難しくなっている。大手プロバイダーの要件を満たさなければならないためだ。
  • 小規模サーバーは大手プロバイダーやスパム送信者によって淘汰されつつある。

• 正当なメールの定義

  • 正当なメールの定義は主観的だ。スパムはインターネットを蝕んでおり、これを防ぐためにコストを課す方法が必要だ。

• メールシステム改善の必要性

  • メールシステムを再設計するとしても、現在のメールシステムを維持しながら改善するのが望ましい。
  • 現代的な暗号化システムの導入と送信者認証システムの導入が必要である。

• スパム対策チェックリスト

  • スパム対策のためにいくつかの実装上の修正が必要である。
  • メールフォワーダーとSMTPサーバーは可能な限り早く転送し、スパムフィルタリングはSMTPレベルで拒否するのがよい。

スパム対策アイデアチェックリスト