DMARCbis、WG Last-Call 開始で RFC 発行の手前の手前くらい

2024年3月2日2024年3月3日

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

タブレットが気になる

高解像 (FHD+) な8インチタブレットを比較

クレカ積立10月買付分まで10万円×5%還元

【10万Pチャレンジャー求む】プラチナプリファード初年度フル活用

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。

その送信ドメイン認証技術の1つである DMARC の新バージョンに相当する RFC の策定状況に関する話題です。

先日、IETF の dmarc WG において、次期 DMARC (DMARCbis) の Working Group Last Call (WGLC) の開始が宣言され、策定のフェーズが１つ進捗しました。

正式に RFC として発行されるまでには、まだ段階を経る必要性があるのですが、本記事では、いったん前のめり＆覗き見のような感じで、現状を簡単にまとめておきます。

本記事が参照する I-D 文書 (Internet-Draft 文書) の内容は、正式に RFC 発行されるまでの間に行われるレビューにより修正される場合があります。また、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) の開始が宣言されました。

DMARCbis策定に関する基本情報

DMARCbis の I-D や dmarc WG に関する情報は、以下から確認できます。

DMARCbis の最新の I-D: IETF Datatracker

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 author’s domai…
dmarc WG: あわせて読みたい
Domain-based Message Authentication, Reporting & Conformance (dmarc)

ちなみに、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 にあります。

概要をメモしておきます。

RFC までに修正される可能性があります。

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 レポート、それぞれです。

IETF Datatracker

DMARC Aggregate Reporting DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for oth…

上記の DMARC Aggregate Reporting は、今回の DMARCbis と同タイミングで Working Group Last Call になっています。

IETF Datatracker

Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email message…

上記の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に修正されそうです(参考１、参考２)。

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 が発行されたようです。