エンジニアが知っておくべきメール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ by blastengine Advent Calendar 2025

GMOコネクト株式会社

【保存版】IETFメールプロトコル大改訂の全貌（前編）| SMTP 17年ぶり改訂・DKIM2・JMAP標準化

Posted at 2025-12-09

はじめまして？
GMOコネクトで執行役員CTOしている菅野哲（かんのさとる）です。
IETFに参加していてメールプロトコル関連の検討が結構行われているなぁ〜と気になったのでまとめてみました。

それでは、どうぞ！

はじめに

「SMTPがRFC 5321（2008年）以来17年ぶりに改訂される」

このニュースを聞いて、どれだけのエンジニアがピンときたでしょうか？2025年現在、IETFではメールプロトコルの歴史的な大規模アップデートが進行中です。

インターネットメールは1980年代から運用されている歴史あるプロトコルですが、認証強化、プロトコル改訂、次世代アクセス方式など、メール基盤そのもののモダナイゼーションが活発に進められています。

この記事（前編）で分かること

✅ RFC 5321bis/5322bis：40年以上の運用経験を反映したSMTP/IMFの全面改訂
✅ DKIM2：リプレイ攻撃を根本解決する次世代メール署名
✅ DMARCbis：InformationalからStandards Trackへの格上げ
✅ JMAP：IMAPを置き換える次世代メールアクセスプロトコル
✅ MailMaint：OAuth認証、自動設定など実用性の大幅向上

記事の構成

本記事は前後編の2部構成です。

前編（本記事）：メールプロトコルのコア部分（SMTP/DKIM/DMARC/JMAP）と実用性改善
後編：メール暗号化のPQC対応（S/MIME、OpenPGP、PQC実装ガイドライン）

対象読者

メールシステムの運用・開発に携わるエンジニア
IETF標準化動向をキャッチアップしたい方
メールプロトコルの最新トレンドに興味がある方

本記事では、IETF(Internet Engineering Task Force)のDatatracker情報を基に、メールプロトコルに関連する主要なワーキンググループ(WG)で議論されている最新のインターネットドラフト(I-D)と標準化動向を紹介します。

1. EmailCore WG: コアプロトコルの改訂

WGの概要

EmailCore WGは、SMTPやメッセージ形式など、メールの基礎となるプロトコルの改訂を担当しています。

📌 最重要ポイント
RFC 5321/5322は2008年発行。40年以上の運用経験を反映した改訂が最終段階です。

主な標準化活動

draft-ietf-emailcore-rfc5321bis ("Simple Mail Transfer Protocol") は、SMTPの仕様を更新する改訂版です。RFC 5321を含む既存のSMTP関連文書を統合・整理し、拡張メカニズムやベストプラクティスを明確にします。RFC 1846、7504、7505などを置き換える予定です[1]。

draft-ietf-emailcore-rfc5322bis ("Internet Message Format") は、インターネットメッセージ形式(IMF)の更新版です。RFC 5322を改訂し、現状の運用を反映して記述や構造を整理します[2]。

draft-ietf-emailcore-as ("Applicability Statement for IETF Core Email Protocols") は、コアメールプロトコルの適用指針(Applicability Statement)です。SMTP、IMF、IMAPなどの関係と、どの拡張を使うべきかを示します[3]。

draft-ietf-emailcore-iana-cleanup ("Updates to SMTP related IANA registries") は、SMTPに関連するIANA登録情報を整理・更新する文書です。既存の登録に不足や古い情報があるため、登録表を正確にします[4]。

今後の展望

RFC 5321bis/5322bisは既にIESGへ提出されており、標準化作業が最終段階に入っています。これらの改訂により、40年以上にわたるSMTPとメッセージ形式の運用経験が反映され、拡張メカニズムやベストプラクティスが明確化されます。並行して、適用指針（Applicability Statement）やIANAレジストリの整備も進められており、メールプロトコルの基盤が現代の運用実態に適合するよう体系的に更新されています。

2. DKIM WG: 次世代メール署名へ

WGの概要

DKIM(Domain Keys Identified Mail)は、メール送信者のドメイン認証を実現する電子署名技術です。DKIM WGでは、現行DKIMの課題を解決する次世代版「DKIM2」の策定が進められています。

発行済みRFC

RFC番号	タイトル	一言メモ
RFC 6376	DomainKeys Identified Mail (DKIM) Signatures	DKIMの基本仕様（RFC 4871とRFC 5672を統合）
RFC 8301	Cryptographic Algorithm and Key Usage Update to DKIM	SHA-1を非推奨化
RFC 8463	A New Cryptographic Signature Method for DKIM	Ed25519-SHA256署名を追加
RFC 6651	Extensions to DKIM for Failure Reporting	検証失敗レポート機能
RFC 6541	DKIM Authorized Third-Party Signatures (Experimental)	サードパーティ署名認可
RFC 5617	DKIM Author Domain Signing Practices (ADSP)	署名ポリシー公開
RFC 7960	Interoperability Issues between DMARC and Indirect Email Flows	DMARC相互運用性

主な標準化活動

draft-ietf-dkim-dkim2-motivation ("DKIM2 - signing the source and destination of every email") は、DKIM2を開発する動機を説明する文書です。Authenticated Received Chain(ARC)の運用経験から、送信元と送信先を署名することでリプレイ攻撃やバックメールを抑止する新しい責任追跡機構が必要であると述べています[5]。

draft-gondwana-dkim2-header ("DKIM2 Header Definitions") は、DKIM2のヘッダ定義を提案する個人ドラフトです。署名対象ヘッダやパラメータの詳細が検討されています。

今後の展望

既存DKIMの欠点であるリプレイ攻撃への脆弱性やARCとの整合性の問題を解決するため、ヘッダ設計と運用上の課題が集中的に議論されています。

3. DMARC WG: プロトコル更新とレポート仕様の整備

WGの概要

DMARC(Domain-based Message Authentication, Reporting & Conformance)は、SPFとDKIMの認証結果を統合し、送信ドメイン管理者がポリシーを指定できる仕組みです。

発行済みRFC

RFC番号	タイトル	ステータス
RFC 7489	Domain-based Message Authentication, Reporting, and Conformance (DMARC)	Informational
RFC 9091	Experimental DMARC Extension for Public Suffix Domains	Experimental

主な標準化活動

draft-ietf-dmarc-dmarcbis ("Domain-based Message Authentication, Reporting, and Conformance (DMARC)") は、DMARCプロトコルの更新版です。送信ドメイン管理者がFrom:ドメインの使用を検証し、検証に失敗したメールの扱い(隔離や拒否)を指示し、報告を要求できる仕組みを説明します。既存のRFC 7489とRFC 9091を置き換える予定です[6]。

draft-ietf-dmarc-failure-reporting ("Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting") は、DMARC失敗報告(Failure Reports)の仕様を詳述します。検証に失敗したメッセージのヘッダや評価結果をXML形式で報告する仕組みを定義し、RFC 7489 Section 7.3を廃止します[7]。

draft-ietf-dmarc-aggregate-reporting ("Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting") は、DMARC集計レポート(Aggregate Reports)の仕様を分離した文書です。受信側が認証結果をXML形式で送信ドメインへ報告する方式を規定しています[8]。

今後の展望

DMARCプロトコルの更新(dmarcbis)と、失敗報告・集計レポートのドラフトが標準化作業中です。SPF/DKIM/DMARCを組み合わせた運用が整備され、送信ドメインによるポリシー制御とフィードバック機構が強化されます。

4. JMAP WG: JSONベースのメールアクセス

WGの概要

JMAP(JSON Meta Application Protocol)は、IMAPに代わるモダンなメールアクセスプロトコルです。JSONを使った効率的なメール同期を実現します。

発行済みRFC

RFC番号	タイトル	概要
RFC 8620	The JSON Meta Application Protocol (JMAP)	JMAPコアプロトコル
RFC 8621	The JSON Meta Application Protocol (JMAP) for Mail	JMAPメールデータモデル
RFC 9007	Handling Message Disposition Notification with JMAP	JMAP経由MDN処理
RFC 9404	JMAP Blob Management Extension	Blob管理拡張
RFC 9670	JMAP for Sharing	データ共有フレームワーク

主な標準化活動

draft-degennaro-jmap-mail-sharing ("JMAP Mail Sharing") は、JMAPでメールボックスを他ユーザーと共有する仕組みを定義します。RFC 9670で定義されたJMAP Sharingフレームワークを拡張し、メールボックスの共有権限（mayReadItems、mayAddItems、mayRemoveItems、maySetSeen、maySetKeywords、maySubmit、mayCreateChild、mayRename、mayDelete、mayShare）を細かく制御できます。共有メールボックスに対するアクセス制御はIMAP ACL（RFC 4314）とのマッピングも考慮されています。

draft-ietf-jmap-sieve ("The JSON Meta Application Protocol (JMAP) for Sieve Scripts") は、JMAPからSieveフィルタを管理する方法を規定します。メールの自動振り分けルールをJMAP経由で設定・管理できるようになります。

draft-ietf-jmap-mdn ("Handling Message Disposition Notification with JMAP") は、JMAP経由でMDN(Message Disposition Notification、開封確認)を扱う仕様を定めます。

draft-ietf-jmap-emailpush ("JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications") は、特定のフィルタに一致する新規メール到着時にプッシュ通知を送る仕組みを定義します。通知オブジェクトにメールのプロパティを含めることで、クライアントが追加のネットワークリクエストなしにユーザー通知を表示できます。モバイル環境での電力効率やネットワーク制約を考慮した設計になっています。

draft-ietf-jmap-filenode ("JMAP File Storage extension") は、JMAPのBlobをファイルシステムとして扱う方法と、リモートファイルシステムに類似したメタデータを提供する拡張です。ファイルノード（ディレクトリ構造）を管理し、WebDAVのようなファイル共有機能をJMAPで実現します。

今後の展望

JMAP WGは、IMAPの複雑さを解消し、モダンなWeb/モバイル環境に最適化されたメールプロトコルとして、機能拡張を進めています。RFC 8620（JMAP Core）とRFC 8621（JMAP for Mail）が基盤として確立され、RFC 9670（JMAP Sharing）により共有機能の標準フレームワークが整備されました。

現在は、メールボックス共有（draft-degennaro-jmap-mail-sharing）により、企業環境での共同作業機能を強化しています。プッシュ通知（draft-ietf-jmap-emailpush）の標準化により、モバイルアプリケーションでのリアルタイム性と電力効率が向上します。

ファイルストレージ拡張（draft-ietf-jmap-filenode）により、JMAPはメールだけでなく、カレンダーや連絡先、ファイル管理を含む包括的なグループウェアプロトコルへと進化しています。これらの拡張により、セキュリティ・プライバシー運用（ユーザー権限管理、情報流通制御）が標準化され、メールシステムのモダナイゼーションを推進します。

5. MailMaint WG: メールの保守と機能拡張

WGの概要

MailMaint(Email Maintenance)WGは、既存のメールプロトコルの保守、小規模な機能追加、ベストプラクティスの文書化を担当します。専用WGを立ち上げるほど大規模ではないが、標準化の価値がある提案を扱います。

主な標準化活動

ユーザビリティ向上

draft-gallagher-email-unobtrusive-signatures ("Unobtrusive End-to-End Email Signatures") は、レガシーMUAで署名を完全に非表示にする新しいPGP/MIME署名構造を提案します。multipart/mixed外側層でメッセージを単純にカプセル化し、レガシークライアントでは添付ファイルとして表示されません。署名検証失敗時のエラー表示を回避し、署名採用の障壁を取り除きます[9]。

draft-ietf-mailmaint-wrong-recipient ("Adding a Wrong Recipient URL for Handling Misdirected Emails") は、誤送信メール問題に対処します。RFC 8058の List-Unsubscribe-Post メカニズムを参考に、Wrong-Recipient ヘッダとHTTPS POSTによる通知を定義します。共通名や短いアドレスを持つユーザーが、他人宛ての取引メールを受信した際に、送信者への通知を可能にします[10]。

draft-ietf-mailmaint-expires ("Updated Use of the Expires Message Header Field") は、RFC 2822のExpiresヘッダの使用範囲を拡張します。時限オファー、イベント告知、SNS通知、定期的な案内メールなど、有効期限を持つメッセージに適用可能です。MTAはこのヘッダによるメッセージ破棄を禁止し、自動削除はメールボックス所有者の設定時のみ推奨されます[11]。

IMAP拡張

draft-ietf-mailmaint-imap-extensions-suggestions ("IMAP Extensions Suggestions") は、汎用IMAPクライアント・サーバー実装が優先的に実装すべき拡張機能セットを提示します。OBJECTID（永続識別子）、SPECIAL-USE（特殊用途メールボックス）、REPLACE（アトミックメッセージ置換）、UIDONLY（UID専用モード）などが含まれます。これらの拡張により、オフライン同期効率、メールボックスリネーム処理、リソース使用量管理が改善されます[12]。

draft-ietf-mailmaint-imap-objectid-partial ("IMAP OBJECTID Partial Implementation extension") は、RFC 8474 OBJECTID拡張の部分実装をサーバーが明示する仕組みを提供します。EMAILID、THREADID、MAILBOXIDのうち、サポートする識別子の種類を個別に宣言可能にし、段階的な実装展開を支援します[13]。

draft-ietf-mailmaint-messageflag-mailboxattribute ("Registration of further IMAP/JMAP keywords and mailbox name attributes") は、Fastmail・Appleなどで実用中のIMAP/JMAPキーワードとメールボックス属性をIANAレジストリに登録します。$notify（通知表示）、$muted（スレッドミュート）、$followed（スレッドフォロー）、MailFlagBit0-2（フラグ色指定）などのキーワードにより、実装間の名前衝突を回避し、相互運用性を向上させます[14]。

draft-ietf-mailmaint-imap-uidbatches ("IMAP UIDBATCHES Extension") は、メールボックスのメッセージを均等サイズのバッチに分割するUID範囲を取得するコマンドを提供します。クライアントはFETCH/SEARCH/STOREコマンドを特定バッチに対して実行でき、リソース使用量とレスポンスサイズを制御可能になります。大規模メールボックス（100,000メッセージ以上）の効率的な処理を実現します[15]。

自動設定とアカウント管理

draft-ietf-mailmaint-autoconfig ("Mail Autoconfig") は、メールアドレスとパスワードのみでメール・カレンダー・連絡先の設定を自動取得するプロトコルを定義します。ユーザーは複雑な技術パラメータ（サーバーホスト名、ポート番号、認証プロトコル）を手動入力する必要がなくなります。draft-ietf-mailmaint-oauth-publicと連携し、OAuth認証も自動設定可能です[16]。

draft-ietf-mailmaint-pacc ("Automatic Configuration of Email, Calendar, and Contact Server Settings") は、サービスプロバイダが標準化された設定情報を公開し、ユーザーエージェントが.well-known URIから取得する仕組みを規定します。JSON形式の設定ファイルをDNS TXT レコードで検証し、JMAP/IMAP/SMTP/POP/CalDAV/CardDAV/ManageSieve/WebDAVの各プロトコルに対応します。TLS証明書検証、OAuth メタデータ取得など、セキュアな自動設定フローを定義します[17]。

国際化と相互運用性

draft-ietf-mailmaint-interoperable-addresses ("Interoperable Email Addresses for SMTPUTF8") は、SMTPUTF8環境で人間が扱いやすいメールアドレス構造を定義します。単一スクリプトルール（localpartとdomainで同一文字体系を使用）、紛らわしい文字の使用制限、ハイフン配置規則などにより、フィッシング攻撃リスクを低減し、カット＆ペースト操作の信頼性を向上させます[18]。

draft-ietf-mailmaint-smtputf8-syntax ("SMTPUTF8 address syntax") は、ソフトウェア開発者向けにSMTPUTF8メールアドレス構文を規定します。危険な文字列を除外し、グローバルに実行可能な規則を定義します。interoperable-addressesとペアの文書で、一方はMTA向けの柔軟な規則、他方は人間向けの相互運用性重視の規則を提供します[19]。

認証とセキュリティ

draft-ietf-mailmaint-oauth-public ("OAuth Profile for Open Public Clients") は、JMAP/IMAP/SMTP/POP/CalDAV/CardDAVのネイティブクライアントとサーバー間のOAuthプロトコルプロファイルを定義します。事前関係なしでのスケーラブルな認証を実現し、パスワード認証からの移行を推進します。RFC 7591動的クライアント登録、RFC 8414 OAuthメタデータ、DPoP（RFC 9449）をサポートし、各プロトコル用のスコープをIANAレジストリに登録します[20]。

draft-happel-mailmaint-pdparchive ("Personal Data Protection Archive") は、Personal Data Portability（個人データ持ち運び権）用のアーカイブ形式を提案します。GDPRなどのプライバシー規制に対応し、ユーザーが自身のメールデータを標準形式で取得・移行できる仕組みを提供します[21]。

今後の展望

MailMaint WGは、メールシステムの実用的な改善を幅広くカバーしています。エンドツーエンド署名のユーザビリティ改善、誤送信対策、IMAP効率化、自動設定の標準化、国際化アドレスの相互運用性、OAuth認証への移行など、メールエコシステムの多様なニーズに対応する標準化活動が進行中です。

特に注目すべきは、OAuth認証プロファイルと自動設定の組み合わせにより、エンドユーザーの設定負担を大幅に軽減しながら、セキュアな認証への移行を実現する取り組みです。また、IMAP拡張群（UIDBATCHES、OBJECTID Partial、キーワード登録）により、大規模メールボックスの効率的な処理と実装間の相互運用性が向上しています。

まとめ：メールプロトコルのモダナイゼーション

5つのWGを一覧で比較

WG名	主な焦点	注目技術	標準化段階
EmailCore	SMTPコア改訂	RFC 5321bis/5322bis	IESG提出済（最終段階）
DKIM	次世代メール署名	DKIM2	設計段階
DMARC	認証ポリシー	dmarcbis（Standards Track化）	標準化作業中
JMAP	次世代プロトコル	メールボックス共有、プッシュ通知	機能拡張段階
MailMaint	実用性改善	OAuth認証、自動設定、IMAP拡張	多数のドラフト進行中

メールプロトコルの進化の方向性

コアプロトコルの全面改訂: EmailCore WGによるSMTP/IMFの30年ぶり大改訂が最終段階
認証メカニズムの強化: DKIM2による根本的なリプレイ攻撃対策、DMARCのStandards Track化
次世代プロトコルへの移行: JMAPによるモダンなメールアクセス、モバイル最適化
実用性の大幅向上: OAuth認証、自動設定、国際化対応など、ユーザビリティとセキュリティの両立

最重要ポイント：メールプロトコルは「枯れた技術」ではなく、40年以上の運用知見を反映した大規模アップデートの真っ最中です。特に、RFC 5321bis/5322bisのIESG提出、DKIM2の策定、JMAPの機能拡張という「プロトコル自体のモダナイゼーション」が、今最も熱い領域です。