DMARCbisとは

DMARCとは、RFC7489で定義されている、送信ドメイン認証技術のひとつです。
これが、近々新しい仕様に置き換えられようとしています。
DMARC2と呼ぶ人もいるようですが、たぶん、DMARCbisで、完成したらただのDMARCになるのではと思います。
現在、41版目でかなり近いうちに承認されるのではないかという噂です。

ここでは、何が変わるのかについて簡単にまとめます。

DMARCの設定で、追加、削除されたタグ

np、psd、tのタグが追加されました。

また、pct、ri、rfのタグが削除されました。

それぞれ見ていきましょう。

新しいタグ (np)

存在しないサブドメインに対してどのポリシーを適用するかを記述します。
ここでいう、存在しないとは、_dmarc.sub.example.jpレコードがあるかどうかではなく、sub.example.jpが存在するかどうかです。

例えば、

sub.example.jp 存在するが_dmarcレコードはない
detarame.example.jp そもそも存在しない

のような状態で、

_dmarc.example.jp TXT "v=DMARC1; p=none; sp=quarantine; np=reject"

を定義した場合、

sub.example.jpはspタグのポリシーが適用され、quarantineとなり、
detarame.example.jpはnpタグのポリシーが適用され、rejectとなります。

_dmarc.sub.example.jp TXT "v=DMARC1; p=none"

のように直接指定した場合は、sub.example.jpはnoneとなります。

表にするとこんな感じです。

p	sp	np	サブドメイン	サブドメインの_dmarc	参照ポリシー
あり	なし	なし	存在しない	-	親ドメインのp
あり	なし	なし	存在する	なし	親ドメインのp
あり	なし	なし	存在する	あり	subドメインのp
あり	あり	なし	存在しない	-	親ドメインのsp
あり	あり	なし	存在する	なし	親ドメインのsp
あり	あり	なし	存在する	あり	subドメインのp
あり	なし	あり	存在しない	-	親ドメインのnp
あり	なし	あり	存在する	なし	親ドメインのp
あり	なし	あり	存在する	あり	subドメインのp
あり	あり	あり	存在しない	-	親ドメインのnp
あり	あり	あり	存在する	なし	親ドメインのsp
あり	あり	あり	存在する	あり	subドメインのp

新しいタグ (psd)

Public Suffix Domainを表すタグです。
y、n、uが書けます。

これにより、サブドメインのDMARCのポリシーがどのように決まるかがはっきりします。
まず、現行のDMARCの場合を見てみます。

現行のDMARCの場合

a.b.c.hornetsecurity.comというドメインのDMARCを調べる場合、まず、

_dmarc.a.b.c.hornetsecurity.comを調べます。

レコードが存在していれば、これを使用します。
存在しない場合は、組織ドメインの、

_dmarc.hornetsecurity.comを調べます。

レコードが存在していれば、これを使用します。
この間、_dmarc.b.c.hornetsecurity.comなどの中間のドメインは調べません。

では、_dmarc.hornetsecurity.comが存在していなければ、次は、_dmarc.comを調べるのでしょうか。

答えは、Noです。組織ドメインを調べて存在しなければ、そこで終わりです。

これには実はいくつか問題があります。
たとえば、.bankというTLDがありますが、仮に全世界の銀行業界全体で「DMARCを書いていないドメインはp=quarantineにしたい」と思っても、_dmarc.bankにポリシーを定義することはできません。

さらに、「組織ドメイン」というのがあいまいです。.nhkは組織ドメインなのでしょうか？

通常、組織ドメインを調べるのにPublic Suffix Listというものを参照します。
Public Suffix ListとはPublic Suffix Domainの一覧でその一階層下が組織ドメインと考えられます。
ただし、これは、元々はWebのCookieの境界を示すもので、組織ドメインを取得するにはあいまいな部分があるのは否めません。

このようなあいまいさを新しいDMARCのpsdタグでは解決しています。

新しいDMARCでの動き

まず、新しいDMARCではサブドメインのDMARCレコードが存在しない場合は、組織ドメインに飛ばず、ひとつ上にドメインのDMARCレコードを参照します。それでも存在しない場合は更に上を参照します。
これを、psd=nまたはpsd=yが現れるまで繰り返します。

[y] 自分はPublic Suffix Domainです。ここより上は探索しないでね。
例: jp, co.jp, cloudfront.net
[n] 自分は組織ドメインまたはそのサブドメインです。ここより上は探索しなくていいよ。
[u] 不明 (デフォルト)

一般人はDMARCレコードを書くとき、psd=nを常に付けておけばいいのだと思います。

例えば、

_dmarc. jp p=reject; psd=y
_dmarc. example1.jp p=quarantine; psd=n
_dmarc. a.example1.jp p=none; psd=n
_dmarc. b.example1.jp レコードなし
_dmarc. example2.jp レコードなし

のような場合、

example1.jp → quarantine
a.example1.jp → none
b.example1.jp → quarantine
example2.jp → reject

となります。

現行のDMARCの場合は、PSDまで辿らないので、example2.jpはDMARCなしになります。

新しいタグ (t)

これは、テストモードです。
yまたはnが記述可能で、yの場合は、1段階ゆるいポリシーが適用されます。

rejectの場合はquarantine
quarantineの場合はnone
noneの場合は変化なし

です。

既視感がありますね。そうです、pct=0と同じです。

pctの場合は、0から100までの任意の値を設定できますが、実は、受信側では事実上0と100しか実装されていないらしく、pctを廃止して、わかりやすいtを新たに導入したようです。

p=noneとp=quarantine; pct=0(p=quarantine; t=y)に違いがあるの?

メーリングリストなどでヘッダFromを書き換える機能で動作が変わる。
→ p=noneでは書き換わらない
→ p=quarantine, rejectの場合には書き換わる

廃止されたタグ

pct: tに置き換え
ri: レポートの送信間隔。

誰も実装せず無視して日次で送信。→ 廃止
rf: 失敗レポートのフォーマット
afrf(ARF形式)とiodefが指定できたが、ARFに固定。

ポリシーの呼び方の定義

ポリシーの呼び方が定義されました。

p=none: モニタリングモード
p=quarantineまたはreject: エンフォースメント(Enforcement)

p=noneはレポートを分析するためのモニタリングモードだということでしょう。

ドメイン所有者のDMARC設定手順

SPFをヘッダFromのドメインで公開
DKIMをヘッダFromのドメインで署名するように設定
DMARCレポートを受けられるように準備
p=noneとruaタグを書いたDMARCレコードを公開
レポートを集めて分析
認証に失敗している原因を修正
ポリシーを厳しくするかどうかを決める

レポートを受けて分析する必要があることがはっきり書かれています。
また、厳しいポリシーいきなり設定するのではなく、ちゃんと分析した結果を見て、ポリシーを厳しくするかどうかの判断をする、というような手順になっています。
とくに、配送先にメーリングリストなどがある場合に慎重になるべき、というスタンスが取られています。

慎重になるべきポイント

卒業生向けメール転送サービス、部署名のエイリアス、メーリングリストなどに送る場合

かつ

中継するメールサーバーがヘッダFromアドレスを書き換えない場合

には、

SPFに依存してはならない(MUST NOT)
有効なDKIM署名が必要 (MUST)

となっています。

また、

一般ユーザーが日常的にメールを送るようなドメインで、インターネット上のメーリングリストに送るような場合

には、

p=rejectにするべきではない (SHOULD NOT)
p=rejectにする場合は
- 1ヶ月間p=noneでレポートを分析
- さらに1ヶ月間p=quarantineでレポートを分析、noneの時と比較する
- p=rejectにする場合は、ユーザーに
  - メーリングリストに投稿させないようにするか
  - メーリングリストの参加が妨げられる可能性があることを周知すべき (SHOULD)

となっています。

メール受信者のDMARC判定手順

ヘッダFromからドメインを抽出
DMARCが宣言されているか確認
SPF、DKIMのチェック
アラインメントを確認
DMARCのPASS, FAILを決定
ポリシーを適用する
結果を保存する
Aggregateレポートを送る
失敗レポートを送ってもいい

基本的には、現行のDMARCと変わりませんが、ポリシーの適用について慎重になっています。

DMARC PASSはヘッダFromドメインが正当なものであること
を示すにすぎず、メッセージの価値判断をするものではない

としたうえで、

DMARC PASSでも隔離したり、Rejectしてもよい
p=rejectでDMARCが失敗しても、メールを受け入れてもよい
p=rejectだけを理由にRejectすべきではない (SHOULD NOT)

となっていて、DMARC単体での判断ではなく、あくまでひとつの参考要素として、別のフィルタなどの結果と組み合わせて最終的なアクションを決めることを推奨しています。

また、

p=noneの場合は既存の処理プロセスを変更してはならない (MUST NOT)

というように、p=noneはDMARCを書いていないのと全く変わらない、ということが書かれています。

ARCやFromヘッダ書き換えについて

ここ10年でメーリングリストソフトはすでにbob@example.comをbob=example.com@user.somelist.exampleのように書き換えるような修正をおこなった
理想とはほど遠いがメーリングリスト業者は受け入れている
ARCも解決策のひとつで研究は現在も進行中であるが、この文書の発行時点では、広く普及するには至っていない
将来、広く採用されるようになった場合には、本文書は更新される

と、書かれており、ARCについてはかなり消極的になっています。

しばらくは、転送やメーリングリストは、「Fromヘッダ書き換え」をおこない、転送者の責任でメールを送る、という時代になりそうです。

このあたり、DKIM2が出てくると、転送者の変更履歴が保存されるので、その頃には、判断は受信側にまかされるようになるのでしょう。

おわりに

そろそろRFCになるかもしれない、次世代のDMARCのインターネットドラフトを斜め読みしてまとめてみました。

参考資料

RFC7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)(現行)
Domain-based Message Authentication, Reporting, and Conformance (DMARC)(ドラフト)
次世代のメールプロトコルの斜め読み (自分の発表資料ですが・・・)