DMARC

曖昧さ回避 この項目では、電子メールの検証システムについて説明しています。the telephony junction pointについては「en:demarcation point」をご覧ください。
曖昧さ回避 「en:dMarc Broadcasting」とは異なります。

Domain-based Message Authentication, Reporting and Conformance (DMARC)は、電子メール認証プロトコルの一つ。電子メールのドメイン所有者が、保有するドメインを認証を通さずに利用されること(なりすましメール、フィッシングメール、詐欺メールその他の脅威)を防止できることを目的に設計された。

DMARCのDNSエントリが公開されると、メールを受信するサーバは送られてくる電子メールを、ドメイン所有者DNSエントリで公開した指示に従って検証することができるようになる。認証に成功した電子メールは配送され、信頼できるものとなる。検証に失敗した場合は、DMARCレコードの指示に従って、何も指定しない(none)、隔離(quarantine)、もしくは拒否(reject)を行う。

DMARCは既存の2つの電子メール認証メカニズム（SPFとDKIM）を拡張したものである。ドメインの管理者はDNSレコードを利用し、エンドユーザに示されるFrom:フィールドの確認方法、受信者が検証失敗時にどう対処すべきか、ポリシに従って実行されるアクションを報告するメカニズムをどう提供するか等を明記する。

DMARCはIETFが2015年3月に公開したRFC 7489によって定義されている。分類は"Informational"。[1]

概要

[編集]

送信者のドメインはDMARCポリシにより、送信者の電子メールがSPFまたはDKIM、あるいはその両方によって保護されていることを示し、それらの認証方法を通過せず拒否または隔離するときに受信者がどうすべきかを指示することができる。[2]

これらのポリシは当該ドメインの権威DNSサーバにおいてTXTレコードとして公開される。

DMARCは電子メールがスパムあるいは詐欺メールであるかどうかを直接判断するものではない。その代わりに、DMARCはメッセージがDKIMまたはSPFの検証を通過するだけでなく、アラインメントをも通過することを必要とする。DMARCの下では、DKIMまたはSPFを通過してもアラインメントを通過しなければfailとなる。

DMARCを設定することにより、正規の送信者からのメッセージの配信量を改善することができる。[3]

アラインメント(一致)

[編集]

DMARCはメッセージのFrom:フィールド("RFC5322.From"[1]ともいう)に含まれるドメインが、その他の認証されたドメイン名と"アライン"(=一致)していることを確認することによって動作する。SPFかDKIMのアラインメントチェックを通過すると、DMARCアラインメント検査通過となる。

アラインメントは、strictあるいはrelaxedで指定される。strictモードでは、メールアドレスのドメイン名がサブドメインまで一致しなければならない。relaxedモードでは、APEX(ネイキッドドメイン)が一致していれば良い。組織ドメインは公開DNSサフィックスリストを確認することで探し出し、それを次のDNSラベルに加える。例えば、"a.b.c.d.example.com.au"と"example.com.au"は同じ組織ドメインを持つ。なぜなら、レジストラが顧客に".com.au"の名前を提供しているからである。これはドメイン境界に関するIETFのワーキンググループが存在したときのDMARCの仕様ではあるが、今では組織ドメインはPublic Suffix List(PSL)から見つけることができる。[4]

SPFとDKIM同様に、DMARCはドメイン所有者(DNSドメインを変更する権限を有する実体あるいはその集合)の概念を利用する。

SPFは配送サーバのIPアドレスが、SMTPのHELOまたはEHLOコマンドから派生する"HELO"アイデンティティ、もしくはSMTP MAILコマンドから派生する"MAIL FROM"アイデンティティでのドメイン名に基づいて、DNSのTXTで設定されたSPFレコードに存在するか認可のチェックを行う。これに加えて、DMARCはReturn-Path(RDC5321.MailFrom)がヘッダFrom(5322.From)と一致していることを確認する。[1]

DKIMでは、電子メールのメッセージの一部にディジタル署名を施すことができ、そのときFromフィールドを署名範囲に加えなければならない。DKIM署名メールヘッダには、d=(ドメイン)とs=(セレクタ)タグが署名検証用の公開鍵をどのDNSから手に入れるかを明記される。署名が有効であれば、署名者がドメイン所有者であることが証明され、署名以降にFromフィールドが改ざんされていないことを保証する。DKIM署名はメッセージ中に含まれることもある。DMARCが必要とするのは、d=タグで指定されたドメインが、From:ヘッダフィールドで指定された送信者のドメインと連携している、有効な署名である。

DNSレコード

[編集]

DMARCはDNSを用いて、_dmarcサブドメインラベルを付けて公開される。例えば_dmarc.example.comのようになる。これをexample.comのSPFや、selector._domainkey.example.comのDKIMと比較する。

TXTレコードは、SPFやDKIMと同様に、name=valueという形式のタグを含み、それぞれのタグはセミコロンで区切られる。以下はその例である: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"

ここで、vはバージョン、pはポリシ(後述)である。spはサブドメインポリシ、pctはポリシを適用する「悪い」電子メールの割合、ruaは集計レポートを送るURIである。この例では、エンティティはexample.comのDNSドメインをSPFまたはDKIMあるいはその両方でのfail率を監視し、電子メールがexample.comのサブドメインから送信されることを想定していない。注意すべき点は、サブドメインはそれ自身のDMARCレコードを公開できることである。組織ドメインのレコードにフォールバックする前にそれを確認しなければならない。

段階的採用

[編集]

DMARCプロトコルは、メール管理者が、全くDMARCを実装していない状態から厳格な設定を完了する状態まで徐々に移行できるよう、様々な移行段階を提供している。[5][6][7] 段階的な採用という概念は、DMARCの目標が最も強固な設定だと仮定しているが、それはすべてのドメインについて当てはまるわけではない。その意図の有無に関わらず、このメカニズムによって素晴らしい柔軟性が実現される。

ポリシ

[編集]

3つのポリシが存在する:

  • noneはエントリレベルのポリシである。受信者は特別な取り扱いを必要としないが、ドメインがフィードバックレポートを受け取ることを可能にする。
  • quarantine はDMARCチェックでfailとなったメッセージを、受信者が怪しいものとして扱うことを要求する。メッセージにフラグを付ける、メッセージを迷惑メールフォルダに入れるなど、受信者によって実装手段が異なる。
  • reject はDMARCチェックでfailとなったメッセージを完全に拒否することを受信者に要求する。

公開されたポリシは、DMARCチェックをfailしたメッセージの一部にのみ適用することによって、「軽減」することができる。受信者はシンプルなベルヌーイサンプリングアルゴリズムによって事前に設定された割合のメッセージを選択することを求められる。残りのメッセージにはより低いポリシ(p=quarantineならnone、p=rejectならquarantine)を適用する。p=quarantine; pct=0;は、From:フィールドを書き換えないメーリングリストに強制的にFrom:フィールドを書き換えるのに使われる。[8]

サブドメインポリシと、sp=、新しく追加されたno-domainポリシ[9]によって、特定のサブドメインのポリシを微調整することが可能になる。

レポート

[編集]

DMARCは2タイプのレポートを生成することができる。集計レポートはruaに引き続いて指定されるアドレスに送信される。フォレンジックレポートはrufタグに引き続いて指定されるアドレスに送信される。これらのメールアドレスはURI mailtoのフォーマット(例: mailto:[email protected] )で指定する必要がある。複数のアドレスを指定も有効となるが、それぞれが完全なURIフォーマットで指定され、カンマで区切られる必要がある。

対象となる電子メールアドレスは外部ドメインのものでもよい。この場合、対象ドメインはDMARCレコードを設定し、レポートを受け取ることに同意しなければならない。そうしなければレポート機能をDoS攻撃に利用されかねない。例えば、receiver.exampleがFrom: [email protected]からのメッセージを受け取り、そのレポートを送ろうとしている場合を考える。ruf=mailto:[email protected]という記述を見つけると、その裏付けのために、ターゲットが管理している名前空間から以下のDNSレコードを探す。 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

集計レポート

[編集]

集計レポートはふつう、1日1回XML形式で送られる。電子メールのサブジェクトは"Report Domain"、すなわちレポートが生成されたDNSドメイン名と、"Submitter"、すなわちレポートを発行するエンティティである。ペイロードは"!"で区切られた長いファイルネームを連結したものであり、レポートを発行する受信者、Unix形式のタイムスタンプで記されたレポート対象の開始/終了区間、任意の識別子、利用可能な可逆圧縮方式(.zip等) に基づく拡張子等を含む。[10] 例: example.com!example.org!1475712000!1475798400.xml.gz.

XMLはヘッダによって構成され、レコードの後にレポートが参照するポリシとレポートのメタデータが続く。レコードはデータベースに関係として挿入することができ、表形式で見ることができる。XMLスキーマは仕様のAppendix Cで定義されており、[11]元のレコードはdmarc.orgに例示されている。[12]データの性質をうまく説明するべく、以下に関係の例を貼り付けてある。DMARCレコードはXSLを用いることにより直接HTMLに変換することも可能である。

DMARCの集計レコード(表形式)
Source IP Count Disposition SPF DKIM Header from SPF domain (result) DKIM domain (result)  
192.0.2.1 12 none Pass Pass example.org example.org (Pass) example.org (Pass)  
192.0.2.1 1 none Pass Fail example.org example.org (Pass) example.org (Fail)  
192.0.2.28 42 none Fail Pass example.org example.org (Fail) example.org (Pass) forwarder.example (Pass)
192.0.2.82 21 none Fail Fail example.org discusslist.example (Pass) example.org (Fail) discusslist.example (Pass)
...

各行は送信元IPと認証結果によって分類され、それぞれのグループにいくつ振り分けられたか(count)が渡される。 一番左のSPFとDKIMという見出しの列は、アラインメントを考慮したDMARCの結果を示しており、passかfailのいずれかである。 一番右の似たような見出しは、メッセージの送信に与したと主張するドメインと、(カッコに示したものは)識別子のアラインメントによらず、元のプロトコル(SPFかDKIM)に基づいて主張される認証ステータスである。 右側のSPFの列は2列になっている部分があるが、一方はReturn-Path:テストで、もう一方はHELOテストである。DKIMは各メッセージ中の署名ごとに一度のみ現れる。 例の中では、第1行はexample.orgからのメインのメールフロー、第2行はDKIMグリッチ(転送中の小さな変化によって生じる署名の破壊)である。 第3行と第4行は、それぞれ転送者とメーリングリストの典型的な失敗例である。DMARC認証は最後の行でのみ失敗している。example.orgがstrictポリシを指定した場合にメッセージのDispositionに影響を受ける。

dispositionはメッセージに実際に適用されたポリシ(none、quarantine、reject)を反映している。これとともに、表には書かれていないが、DMARCはポリシのオーバーライドを提供する。受信者が要求されたポリシと異なるポリシを適用する理由として、既に仕様によってポリシが与えられていることが挙げられる:

forwarded
同じバウンスのアドレスである限り、基本的にDKIMに違反しない
sampled out
送信者が一部のメッセージだけにしかポリシを適用しないことを選択したから
trusted forwarder
メッセージがローカルで既知のソースから送られて来た
mailing list
受信者がヒューリスティックにメーリングリストから送られてくるメッセージを決定する
local policy
受信者は所望のポリシーを適用することが許されるが、そのことを送信者に知らせたほうが良い
other
上記のいずれも適用されない場合、コメントフィールドに詳しく記すことができる

フォレンジックレポート

[編集]

フォレンジックレポート(異常レポート)はリアルタイムに生成され、foタグに指定された値に基づき、SPFまたはDKIMあるいはその両方でfailとなったそれぞれのメッセージの編集されたコピーを含む。これらのフォーマットはAbuse Reporting Format（英語版）の拡張であり、"message/rfc822"または"text/rfc822-headers"を含む点で通常のバウンスのフォーマットと似ている。

フォレンジックレポートは他に以下のものを含む:

  • 送信元IPアドレス
  • Fromメールアドレス
  • 受信者のメールアドレス
  • メールのサブジェクト行
  • SPFとDKIMの認証結果
  • 受信時刻
  • 電子メールのメッセージヘッダ(送信元ホスト、電子メールID、DKIM署名、その他カスタムヘッダ情報)[13]

互換性

[編集]

フォワーダ

[編集]

電子メールの転送にはいくつかの異なるタイプが存在し、その一部はSPFに違反する。[14]これは電子メールの転送がDMARC認証の結果に影響する理由の一つである。[15]

メーリングリスト

[編集]

メーリングリストは、オリジナルの作成者のドメインによるDKIM署名が正しいのに検証失敗する際のよくある原因である。例えばサブジェクトヘッダに接頭辞を加えることによって生じる。多くの回避策があり[16][17]、メーリングリストソフトウェアパッケージはこの解決に取り組んでいる。[18]

すべてのメッセージの変更を無効化

[編集]

この回避策はメーリングリストの標準ワークフローであり続けており、いくつかの巨大メーリングリストオペレータに採用されているものの、メーリングリストがフッタとサブジェクトのプレフィックスを付けられなくなるという弊害もある。[19]メールソフトが署名付きヘッダを並び替えたり変更したりしないように慎重に設定する必要がある。間違った設定を行ったメールサーバは、リストIDをメーリングリストに送られるメッセージのDKIMに挿入してしまい、リストオペレータが受信を拒否したり、From:を書き換えることをできなくしたりせざるを得なくなる。

From:書き換え

[編集]

最もよく使われる回避策は、From:ヘッダフィールドを書き換えることである。オリジナルの作成者のアドレスはReply-Toフィールドに加えられる[20]。書き換えは、単に.INVALIDを追加するものから[注釈 1]、不透明なIDが利用されている部分に一時的なユーザIDを割り当て、ユーザの実際のメールアドレスをリストに把握されないためにドメイン名を追加するものまで多岐にわたる。 加えて、作成者とリスト(あるいはリストオペレータ)の両方を表示するよう、表示名を変更することもできる[21]。これらの例は、それぞれ、以下のような結果になる: 

From: John Doe <[email protected]> From: John Doe <[email protected]> From: John Doe via MailingList <[email protected]> Reply-To: John Doe <[email protected]>

最終行のRepli-To:はreply-to-author機能が使えるように設定しておかなければならない。これはreply-to-list機能がFrom:ヘッダフィールド内の変更によって実現される場合を想定したものである。このようにして、これらのフィールドの元々の意味が入れ替わる。

作成者を変更することは通常は正当ではなく、そのデータの意味と見た目の想定された関係や、その自動的な利用を損なうことになる。メーリングリストを仕事の調整のために用い、From:フィールドを添付ファイルの作成者として割り当てるツールを配備するコミュニティが存在している。[22]

その他の回避策

[編集]

ラップされたメッセージを解釈できるメールクライアントを使う場合、メッセージのラッピングは上手く動作する。ただ、いくつかの国で法的にそうせざるを得ない場合や、日常的にSPF認証に失敗することがすべての認証をより脆弱なものとしている場合を除けば、何も変更しないのが最も明白な解決法だと思われる。[23]

Senderフィールド

[編集]

From;ヘッダフィールドをDKIM連携を通過するために変更することによって、RFC 5322の3.6.2節「'From'フィールドにはメッセージの作成者、すなわち、メッセージの作成した責任を持つ人またはシステムあるいはその集合のメールボックス(群)を指定する」に準拠しない状態になり得る。メールボックスは作成者のメールアドレスを指す。Sender:ヘッダはメールが別の集団を代表して送られてきたことを示すことができるが、DMARCはFromドメインのポリシのみをチェックし、Senderドメインのポリシは無視する[注釈 2]。

ADSP（英語版）とDMARC[24] はともに、多くのユーザエージェントがSenderフィールドを受信者に表示しないという非技術的な理由により、Senderフィールドを利用することを拒否している。

歴史

[編集]

DMARCのドラフト仕様は2012年1月30日から維持されている。[25]

2013年10月、GNU Mailman 2.1.16がリリースされ、p=rejectのDMARCポリシを設定したドメインからの送信者を処理できるオプションが追加された。[18]この変更は、(純粋なトランザクションメールドメインとは対照的に)人間のユーザによってドメインに適用される限定的なポリシについて予想される相互運用性の問題を予期しようとしたものであった。

2014年4月、YahooはDMARCポリシをp=rejectに変更し、それによって一部のメーリングリストで誤作動が起きた。[26][27]数日後、AOLもDMARCポリシをp=rejectに変更した。[28]これらの動きは大きな混乱を招き、メールボックスプロバイダは自身のセキュリティ上の不備のコストをサードパーティに押し付けたことで非難された。[29]2020年に、公式DMARCwikiのFAQでは、メーリングリストがstrictDMARCポリシのドメインからのメッセージを処理するためのいくつかの提案を掲載しており[30]、その中ではメーリングリストが"From"ヘッダを自身のドメインのアドレスに変更するというものが最も多く実装されている。

2014年8月に、DMARCの問題に対処するためのIETFのワーキンググループが結成され、相互運用性の懸念と標準仕様と文書の改訂続行の取り組みを始めた。[31]その間に、既存のDMARCの仕様は多くの人々に合意を得て実装されたeditorial状態となっていた。2015年3月、Independent Submission Streamに"Informational"(非標準)カテゴリでRFC 7489として公開された。[32]

2017年3月、en:Federal Trade CommissionがビジネスにおけるDMARCの利用に関する調査を公開した。[33]569のビジネスの3分の1がDMARCの設定を実装しており、10%未満がサーバに未認証のメッセージを拒否させるようDMARCを設定しているが、大多数はSPFを実装していることが調査によって判明した。

貢献者

[編集]

DMARCの仕様策定に貢献した組織: [34][35]

関連項目

[編集]

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ INVALID is a top level domain reserved by RFC 2606 for this kind of usage.
  2. ^ Use of the Sender field by remailers is mentioned (in the context of DKIM, not DMARC) in sections B.1.4 and B.2.3 of RFC 4871.

出典

[編集]
  1. ^ a b c Murray Kucherawy; Elizabeth Zwicky (18 March 2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC) (英語). IETF. doi:10.17487/RFC7489. RFC 7489。
  2. ^ Terry Zink. “How we moved microsoft.com to a p=quarantine DMARC record”. MSDN blog. 2016年9月27日閲覧。 “If that sounds like a lot of work, that’s because it was”
  3. ^ “Bulk Senders Guidelines – Gmail Help”. support.google.com. 2015年4月24日閲覧。
  4. ^ John Levine (2 November 2017). "Use of the public suffix list". Mailman developers (Mailing list).
  5. ^ Tutorial: Recommended DMARC rollout, https://support.google.com/a/answer/10032473?hl=en 
  6. ^ “Implementation Guidance: Email Domain Protection”. cyber.gc.ca. 2021年8月12日閲覧。
  7. ^ User Guide for Cisco Domain Protection, (2021-05-25), https://www.cisco.com/c/dam/en/us/td/docs/security/phishing_protection-and-domain_protection/dp_user_guide.pdf 
  8. ^ Jonathan Kamens (9 October 2018). ""p=none" vs. "p=quarantine; pct=0"" (Mailing list).
  9. ^ Scott Kitterman (26 July 2021). Tim Wicinski (ed.). Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains (英語). IETF. doi:10.17487/RFC9091. RFC 9091。
  10. ^ “What is the rationale for choosing ZIP for the aggregate reports?”. DMARC.org (2012年). 2019年4月3日閲覧。 “Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft”
  11. ^ Murray S. Kucherawy; Elizabeth Zwicky, eds. (March 2015). "DMARC XML Schema". Domain-based Message Authentication, Reporting, and Conformance (DMARC) (英語). IETF. sec. C. doi:10.17487/RFC7489. RFC 7489. 2019年3月3日閲覧。
  12. ^ “I need to implement aggregate reports, what do they look like?”. DMARC.org. 2016年5月26日閲覧。
  13. ^ The Ultimate Guide to DMARC Reporting in 2022, (2019-08-23), https://glockapps.com/tutorials/dmarc-monitoring-reporting/ 
  14. ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (September 2016). "Alias". Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (英語). IETF. sec. 3.2.1. doi:10.17487/RFC7960. RFC 7960. 2017年3月14日閲覧。
  15. ^ “How does email forwarding affect DMARC authentication results?”, progist.net, (2023-01-06), https://blog.progist.net/how-does-email-forwarding-affect-dmarc-authentication-results/ 
  16. ^ Anti-Spam Research Group, Mitigating DMARC damage to third party mail, https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail 
  17. ^ dmarc.org wiki
  18. ^ a b Mark Sapiro (16 October 2013). “Mailman and DMARC”. list.org. 13 August 2015閲覧。
  19. ^ Upcoming changes for lists.debian.org, https://lists.debian.org/debian-devel-announce/2015/08/msg00003.html 
  20. ^ Al Iverson (2014年4月9日). “Spam Resource: Run an email discussion list? Here's how to deal with DMARC”. spamresource.com. 18 April 2014閲覧。
  21. ^ “How Threadable solved the DMARC problem”. Threadable Blog. 2016年5月21日閲覧。
  22. ^ Theodore Ts'o (18 December 2016). "Realistic responses to DMARC". IETF-Discussion (Mailing list). 2017年3月14日閲覧。The fact that the from field is not rewritten is IMPORTANT because rewriting the from field would break the 'git am' command, since it uses the From: field to fill in the git commit's from field
  23. ^ John Levine (31 May 2014). “Mitigating DMARC damage to third party mail”. wiki. ASRG. 2014年6月1日閲覧。
  24. ^ “Domain-based Message Authentication, Reporting and Conformance (DMARC) [draft 01]”. IETF (15 July 2013). 2016年5月24日閲覧。
  25. ^ "History", dmarc.org
  26. ^ Lucian Constantin (8 April 2014). “Yahoo email anti-spoofing policy breaks mailing lists”. PC World. 15 April 2014閲覧。
  27. ^ Laura Atkins (April 12, 2014), Yahoo Statement on DMARC policy, wordtothewise.com, https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ 
  28. ^ Vishwanath Subramanian (22 April 2014). “AOL Mail updates DMARC policy to 'reject'”. AOL. 13 August 2015時点のオリジナルよりアーカイブ。13 August 2015閲覧。
  29. ^ John Levine (13 August 2016). "DMARC and ietf.org". IETF (Mailing list). 2016年10月10日閲覧。
  30. ^ “FAQ in DMARC wiki”. 2020年7月15日閲覧。
  31. ^ "WG Action: Formed Domain-based Message Authentication, Reporting & Conformance (dmarc)". IETF-Announce (Mailing list). 11 August 2014. 2016年10月10日閲覧。
  32. ^ DMARC FAQ, https://dmarc.org/ 
  33. ^ Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication, Federal Trade Commission, (3 March 2017), https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf 
  34. ^ Kucherawy, Murray; Zwicky, Elizabeth. "Acknowledgements". Domain-based Message Authentication, Reporting, and Conformance (DMARC) (英語). sec. E. I-D draft-kucherawy-dmarc-base-01。
  35. ^ DMARC Contributors (PDF)
  36. ^ Vitaldevara, Krish (10 December 2012). “Outlook.com increases security with support for DMARC and EV certificates”. Outlook Blog. Microsoft. 12 December 2012閲覧。
  37. ^ Martin, Franck (20 September 2012). “DMARC: a new tool to detect genuine emails”. LinkedIn Engineering Blog. Linkedin. 17 August 2013閲覧。
  38. ^ Josh Aberant (21 February 2013). “Introducing DMARC for Twitter.com emails”. twitter.com. 10 April 2014閲覧。
  39. ^ a b c d e f g h “History – dmarc.org”. dmarc.org. 2020年9月23日閲覧。

外部リンク

[編集]
「https://ja.wikipedia.org/w/index.php?title=DMARC&oldid=102410292」から取得