DMARCbis、WG Last-Call 開始で RFC 発行の手前の手前くらい
電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。
その送信ドメイン認証技術の1つである DMARC の新バージョンに相当する RFC の策定状況に関する話題です。
先日、IETF の dmarc WG において、次期 DMARC (DMARCbis) の Working Group Last Call (WGLC) の開始が宣言され、策定のフェーズが1つ進捗しました。
正式に RFC として発行されるまでには、まだ段階を経る必要性があるのですが、本記事では、いったん前のめり&覗き見のような感じで、現状を簡単にまとめておきます。
SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証のまとめ記事はこちらです。
DMARCbis の WG Last-Call 開始
2024年2月29日 (UTC) 、IETF の dmarc WG にて、Chair の Barry Leiba 氏により次期 DMARC (DMARCbis) の Working Group Last Call (WGLC) の開始が宣言されました。
この WGLC の期間は 3月末までであり、その間に dmarc WG 内で最終確認が行われます。
なお、この期間中には IETF 119 が開催されます (16 Mar 2024 – 22 Mar 2024、IETF 119 Brisbane)。
WGLC の後は、さらに Internet Engineering Steering Group (IESG) のレビューを経てから、RFC 発行の手続きに入ります。
DMARCbis策定に関する基本情報
DMARCbis の I-D や dmarc WG に関する情報は、以下から確認できます。
- DMARCbis の最新の I-D
- Domain-based Message Authentication, Reporting, and Conformance (DMARC) This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email’s Author Domai…
- dmarc WG
-
ちなみに、dmarc WG の Barry Leiba 氏 (Chair)、John R. Levine氏 (DMARCbis の Authorsの1人) は、M3AAWG の Expert Advisors もされているようです。
- RFC 策定における Working Group Last Call (WGLC)
-
WG が文書を公開する準備ができたと判断した際には、Chair により Last-Call が行われることになっているようです。
When a WG decides that a document is ready for publication it may be submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for publication is done by the WG Chair issuing a working group Last- Call.
出典:RFC 2418 – IETF Working Group Guidelines and Procedures
これ以上遅れないように
DMARCbis の策定作業が長引いているので、(自分が賛成できないという理由で) 終わった議論を再開しないように、と釘が刺されています。
Please do keep in mind that we have discussed this at great length and over a long time period. Therefore, please do NOT ask to re-open settled issues because you still disagree with the result. Significant issues raised at this point need to be accompanied by a clear, understandable explanation of why this is a NEW argument.
出典:[dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30
なかなか収束しないやり取りがあった様子です。
ちなみに、この DMARCbis の I-D は 30版目 (draft-ietf-dmarc-dmarcbis-30) です。
DMARCbis (30版) の概要
既存のDMARC (RFC 7489) からの変更点のサマリは、7. Changes from RFC 7489 にあります。
概要をメモしておきます。
7.1. IETF Category
文書の Category が変わり、Informational (RFC 7489) から Internet Standards Track (DMARCbis) になります。
7.2. Changes to Terminology and Definitions
用語や定義の内容が更新されます。
7.3. Policy Discovery and Organizational Domain Determination
DMARC ポリシーの探索や、組織ドメインの決定を行うための手法が変わります。
Public Suffix List (PSL) に依存していた手法が、”DNS Tree Walk” と呼ばれる手法に置き換わります。
7.4. Reporting
DMARC レポートに関する内容は別のドキュメントに移管されます。
2種類の DMARC レポート、それぞれです。
上記の DMARC Aggregate Reporting は、今回の DMARCbis と同タイミングで Working Group Last Call になっています。
上記のDMARC Failure Reporting は、2023-09-14 が最終更新です (状況がどこに書かれているか分かりませんでした)。
7.5. Tags
追加されたタグは以下です。
np - Policy for non-existent domains (Imported from [RFC9091])
psd - Flag indicating whether a domain is a Public Suffix Domain
t - Replacement for some pct tag functionality. See Appendix A.7 for further discussion
削除されたタグは以下です。
pct - Tag requesting application of DMARC policy to only a percentage of messages
rf - Tag specifying requested format of failure reports
ri - Tag specifying requested interval between aggregate reports
pct タグが削除され、t タグに置き換えられます。
また、前述の DNS Tree Walk に関連し、psd タグも登場します。
7.6. Expansion of Domain Owner Actions Section
既存の DMARC (RFC 7489) では最低限の記述だった Domain Owner Actionsの内容が拡充されます (5.5. Domain Owner Actions)。
以下のようにステップごとの見出しに沿って詳しい説明になります。
5.5.1. Publish an SPF Policy for an Aligned Domain
5.5.2. Configure Sending System for DKIM Signing Using an Aligned Domain
5.5.3. Setup a Mailbox to Receive Aggregate Reports
5.5.4. Publish a DMARC Policy for the Author Domain and Organizational Domain
5.5.5. Collect and Analyze Reports
5.5.6. Decide Whether to Update DMARC Policy
domains for general-purpose email の p=reject は SHOULD NOT か
なお、7.6 の最後にある “In particular, this document makes explicit that domains for general-purpose email MUST NOT deploy a DMARC policy of p=reject.” の記載については、MUST NOT の部分が SHOULD NOT に変わりそうです (現段階で)。
これは、DMARC の実運用においては、それなりに注目を集めそうな記載です。汎用的なメールを扱うドメイン (domains for general-purpose email とあり、その定義をきちんと記述するのは難しいのですが、多少不正確という前提で私の理解を記載しておくと、一般利用者がそのドメインを From アドレスとしてメール送信し、送信したメールは転送やML配送されることもある、つまり電子メールが利用者によって普段使いに利用されているドメイン) では、p=reject を採用すべきでないという意味です。8.6. Interoperability Considerationsと合わせて理解するのが良いと思います。
これまでに得られていたはずの rough consensus に基づき、上記の記載は MUST NOT から SHOULD NOTに修正されそうです(参考1、参考2)。
7.7. Report Generator Recommendations
DMARC ポリシーに複数のレポート送信先アドレスが指定されていた場合の扱いについての変更です。
7.8. General Editing and Formatting
基本的には、既存のDMARC (RFC 7489) の内容を引き継いでおり、軽微な編集、セクションの並べ替え等の修正が加えられている旨の説明です。
上記よりさらにもう一段階前のまとめ
さらに以前に、議論の経過が以下のようにまとめられています。
(参考) 日程感
今後の日程感は分からないのですが、参考までに HTTPbis が当時の Proposed Standard として発行された際の経過を載せておきます。
HTTP 2.0の標準化に向けたスケジュール提案によると、WGLCに続いて10月1日からはIETFラストコールが開始され、11月9日~14日のIETF 91で必要に応じてIETFラストコールの問題に対応する。
12日4日にはIESG TelechatでProposed StandardとしてHTTP 2.0を検討し、2015年1月にIESGコメントに対応してRFC Editorに提案。同年2月にRFCとして発表することを目指す。
出典:HTTP 2.0、ワーキンググループラストコールを開始:2015年2月のRFC化に向けて – @IT
2014年時点では上記の状況で、その後、2015年5月に RFC 7540 が発行されたようです。
まとめ
本記事では、先日、IETF の dmarc WG において、次期 DMARC (DMARCbis) の Working Group Last Call (WGLC) の開始が宣言されたことについて、いったん前のめり&覗き見のような感じで、現状を簡単にまとめてみました。
- 送信ドメイン認証全般に関する記事
- 個々の送信ドメイン認証に関する記事
- 送信ドメイン認証のTIPS
-
Authentication-Results ヘッダまとめ ※機会があれば作成予定…
- 送信ドメイン認証の動向