要約

  • 11月1日のDKIM2作業部会草案第09版は、10月27日の第08版になかったDomain Policy Recordを追加した。
  • 親ドメインが自分の_domainkeyにstrictを掲げると、子ドメインの署名では親を使うFromを「Authentic」にできなくなる。印がなければ草案は子の署名を認める。
  • この方針は掲載したドメインだけに効く。DNSの上下に伝わらず、一時的な取得失敗はTEMPERRORとなる。

別棟に渡した鍵が、本館の名札にも届く

企業が送信業者にmail.example.comを委ねる。業者はその子ドメインでメールに署名する。DKIM2第09版では、その署名が親のexample.comを表示するFromにも「Authentic」の判定をもたらし得る。起草者は既存のDKIM1の慣行を保ち、委託を急に壊さないためだと説明する。第08版には新しい親側の方針記録も、上向きの照合を止める判定もなかった。

親は第3.8節の記録で線を引ける。_domainkey.example.comに置くTXTはv=DKIM1で始まり、任意のf=欄にstrictを入れられる。すると子ドメインは、example.comを使うFromを本物とする権限を持たない。strictがない場合も、記録そのものがない場合も、草案は子を許す。これは提案中のDKIM2のFrom判定であり、既存のDKIM1配送結果を書き換える話ではない。

第7節は照合を二度行う。まずFromのドメインと署名のd=を比べる。合わなければ順序を逆にする。後者なら子の署名ドメインから親のFromへ遡れる。親のstrictが遮るのはこの経路だ。親自身による署名には遡りは要らない。しかも方針はそのドメインだけのもの。親の設定が子へ自動で降りることも、子の設定が親を支配することもない。

取得時の失敗も意味を持つ。有効な方針記録が複数あればPERMERROR、一時的なDNS障害ならTEMPERROR。検証者はそれを黙って許可に変えられない。IETFの記録では第09版はまだ作業部会Internet-Draftで、I-D Exists。新しい親側の錠前が実運用で相互接続した記録は確認できない。