DKIM ADSP は廃止されています (HISTORIC です)

2023年09月19日火曜日

【この記事を書いた人】
古賀勇

IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。

「DKIM ADSP は廃止されています (HISTORIC です)」のイメージ

CONTENTS

結論

https://www.rfc-editor.org/rfc/rfc5617.html (HISTORIC) ^(※1)

新しくドメイン名を登録された方へ

DKIM ADSP レコードは、もはや書く必要はありません。
誰も見ていませんし、評価の対象になっていないと考えて差し支えありません。

すでにドメイン名を運用されている方へ

DKIM ADSP レコードが書いてあるかは、次のように調べられます。
```
$ dig _adsp._domainkey.example.jp. txt
```
このレコードを引いた結果、NXDOMAIN なら書いてありません。
もし、dkim=unknown などが返ってきたら消しておきましょう。上記の通り誰も見ていませんので消してもリスクはありません。

3分で分かる背景と理由

メールにまつわる送信ドメイン認証には、歴史的に SPF → DKIM → DMARC → ARC の順に登場しました。

送信ドメイン認証が登場する 2006年以前は、差出人メールアドレスが詐称された、いわゆるなりすましメールを検出する仕組みがありませんでした。誰でもなりすましメールを送り放題だったのです。^(※2) ^(※3)
そこで、IP アドレスを詐称することは容易ではないだろうということで、IP アドレスをベースにした対策が急ピッチで進められました。これが Sender Policy Framework、SPF です。対策が進めやすいため広く普及しています。

しかし IP アドレスをベースにした SPF の認証は、転送メールと相性が悪いことで知られています。これを支える仕組みとして DKIM が登場します。メールそのものに電子署名を付与して、配送経路に依存しない仕組みにしました。
また、DKIM が登場したときには、送信ドメイン認証の課題も認識されていました。その課題のうち、「認証に失敗したメールをどのように扱うべきかを書いておくと役に立つのでは?」という議論も出ていました。

これが DKIM ADSP です。

しかし、DKIM ADSP にも課題がありました。
差出人の From ドメインと DKIM の署名ドメイン(d=)を完全一致で評価するため、サブドメインを用いて詐称メールを送付されてしまったり、すべてのメールに電子署名を付与しないと「認証失敗したものは全て捨てて良い(dkim=discardable)」というポリシーにたどり着くまでにハードルの高いものになっていました。

そこで DMARC が登場しました。
DMARC は、SPF または DKIM の検証結果を見て、ヘッダ From のドメイン名が詐称されていないかを強力に検出することができるようになったうえ、認証に失敗したメールをどのように扱ってほしいかを明示することも必須としました。さらに、メールの受信者が送信側に認証結果をレポートする仕組みまで整え、この普及を推し進めるフレームワークに出来上がっています。

ARC はメーリングリストなどで本文が書き換わっても、DKIM 同様に再署名して、送信ドメイン認証の結果を後続のサーバに伝達できるようなフレームワークにしました。

まとめ

以上の過程から、DMARC の登場によって DKIM ADSP の役目は終えたと考えることができます。^(※4)
だから、DKIM ADSP レコードは書く必要がないのです。(代わりに DMARC を書きましょう、まだ書いていない場合は → https://eng-blog.iij.ad.jp/archives/3273)

DKIM ADSP を書いておいても有害ではありませんが、後々の禍根を残さないよう、今書いてある場合は忘れずに消しておくと良いでしょう。後任の DNS 担当者が「なんだこのレコードは!?」となる前に… ^(※5)

脚注

JPNIC に RFC の分類(https://www.nic.ad.jp/ja/rfc-jp/RFC-Category.html)の日本語解説があります。HISTORIC とは、次のような RFC です。[↑]

既に標準であったものが別の仕様によって使われなくなった場合など、いままで公開されていたRFCの仕様的な役割が終わった際に利用される分類である。主に資料としての参照するために公開されており、 その内容を実際に使うことは推奨されない。
なりすましてメッセージを送付できるという視点では、現実世界の郵便も同じです。電子メールがことさら問題なのは、その送るコストが圧倒的に小さいことです。[↑]
SMTP が策定された 1980年代は「迷惑メール」というものが、ほぼ存在しませんでした。[↑]
DMARC の RFC7489 Appendix A.5 に DKIM ADSP の課題が整理されています: [↑]
https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.5
この記事を書いているときに自社のゾーンを眺めていたら、Internet-Draft 段階のレコードが残っていることに気づきました。次のレコードも不要なものです。見つけたら消してください。DNS とお部屋のクリーニング、大事。[↑]
```
_domainkey              IN      TXT     "t=y; o=~"
_policy._domainkey      IN      TXT     "t=y; o=~"
_ssp._domainkey         IN      TXT     "t=y; dkim=unknown"
```
- DKIM SSP (Sender Signing Practices): https://datatracker.ietf.org/doc/html/draft-ietf-dkim-ssp-01