\ ポイント最大11倍! /

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

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

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

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

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

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

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

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

正式に 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) の開始が宣言されました。

この 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
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 にあります。

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

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

上記の 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) の開始が宣言されたことについて、いったん前のめり&覗き見のような感じで、現状を簡単にまとめてみました。

日ごろのお買い物等にご利用いただけると当ブログ継続の励みになります

出張先、旅行先のホテル予約はお早めに

あまり知られていない50%OFF商品専用ページ (Amazonのヤスイイね)
シェア=ありがたみ
  • URLをコピーしました!
目次