 | この項目では、電子メールの検証システムについて説明しています。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:ヘッダフィールドで指定された送信者のドメインと連携している、有効な署名である。
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:dmarcreports@example.com;"
ここで、vはバージョン、pはポリシ(後述)である。spはサブドメインポリシ、pctはポリシを適用する「悪い」電子メールの割合、ruaは集計レポートを送るURIである。この例では、エンティティはexample.comのDNSドメインをSPFまたはDKIMあるいはその両方でのfail率を監視し、電子メールがexample.comのサブドメインから送信されることを想定していない。注意すべき点は、サブドメインはそれ自身のDMARCレコードを公開できることである。組織ドメインのレコードにフォールバックする前にそれを確認しなければならない。
DMARCプロトコルは、メール管理者が、全くDMARCを実装していない状態から厳格な設定を完了する状態まで徐々に移行できるよう、様々な移行段階を提供している。[5][6][7]段階的な採用という概念は、DMARCの目標が最も強固な設定だと仮定しているが、それはすべてのドメインについて当てはまるわけではない。その意図の有無に関わらず、このメカニズムによって素晴らしい柔軟性が実現される。
3つのポリシが存在する:
公開されたポリシは、DMARCチェックをfailしたメッセージの一部にのみ適用することによって、「軽減」することができる。受信者はシンプルなベルヌーイサンプリングアルゴリズムによって事前に設定された割合のメッセージを選択することを求められる。残りのメッセージにはより低いポリシ(p=quarantineならnone、p=rejectならquarantine)を適用する。p=quarantine; pct=0;は、From:フィールドを書き換えないメーリングリストに強制的にFrom:フィールドを書き換えるのに使われる。[8]
サブドメインポリシと、sp=、新しく追加されたno-domainポリシ[9]によって、特定のサブドメインのポリシを微調整することが可能になる。
DMARCは2タイプのレポートを生成することができる。集計レポートはruaに引き続いて指定されるアドレスに送信される。フォレンジックレポートはrufタグに引き続いて指定されるアドレスに送信される。これらのメールアドレスはURImailtoのフォーマット(例: mailto:worker@example.net )で指定する必要がある。複数のアドレスを指定も有効となるが、それぞれが完全なURIフォーマットで指定され、カンマで区切られる必要がある。
対象となる電子メールアドレスは外部ドメインのものでもよい。この場合、対象ドメインはDMARCレコードを設定し、レポートを受け取ることに同意しなければならない。そうしなければレポート機能をDoS攻撃に利用されかねない。例えば、receiver.exampleがFrom: someone@sender.exampleからのメッセージを受け取り、そのレポートを送ろうとしている場合を考える。ruf=mailto:some-id@thirdparty.exampleという記述を見つけると、その裏付けのために、ターゲットが管理している名前空間から以下の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に変換することも可能である。
| 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はポリシのオーバーライドを提供する。受信者が要求されたポリシと異なるポリシを適用する理由として、既に仕様によってポリシが与えられていることが挙げられる:
フォレンジックレポート(異常レポート)はリアルタイムに生成され、foタグに指定された値に基づき、SPFまたはDKIMあるいはその両方でfailとなったそれぞれのメッセージの編集されたコピーを含む。これらのフォーマットはAbuse Reporting Format（英語版）の拡張であり、"message/rfc822"または"text/rfc822-headers"を含む点で通常のバウンスのフォーマットと似ている。
フォレンジックレポートは他に以下のものを含む:
電子メールの転送にはいくつかの異なるタイプが存在し、その一部はSPFに違反する。[14]これは電子メールの転送がDMARC認証の結果に影響する理由の一つである。[15]
メーリングリストは、オリジナルの作成者のドメインによるDKIM署名が正しいのに検証失敗する際のよくある原因である。例えばサブジェクトヘッダに接頭辞を加えることによって生じる。多くの回避策があり[16][17]、メーリングリストソフトウェアパッケージはこの解決に取り組んでいる。[18]
この回避策はメーリングリストの標準ワークフローであり続けており、いくつかの巨大メーリングリストオペレータに採用されているものの、メーリングリストがフッタとサブジェクトのプレフィックスを付けられなくなるという弊害もある。[19]メールソフトが署名付きヘッダを並び替えたり変更したりしないように慎重に設定する必要がある。間違った設定を行ったメールサーバは、リストIDをメーリングリストに送られるメッセージのDKIMに挿入してしまい、リストオペレータが受信を拒否したり、From:を書き換えることをできなくしたりせざるを得なくなる。
From:書き換え最もよく使われる回避策は、From:ヘッダフィールドを書き換えることである。オリジナルの作成者のアドレスはReply-Toフィールドに加えられる[20]。書き換えは、単に.INVALIDを追加するものから[注釈 1]、不透明なIDが利用されている部分に一時的なユーザIDを割り当て、ユーザの実際のメールアドレスをリストに把握されないためにドメイン名を追加するものまで多岐にわたる。加えて、作成者とリスト(あるいはリストオペレータ)の両方を表示するよう、表示名を変更することもできる[21]。これらの例は、それぞれ、以下のような結果になる:
From:JohnDoe<user@example.com.INVALID>From:JohnDoe<243576@mailinglist.example.org>From:JohnDoeviaMailingList<list@mailinglist.example.org>Reply-To:JohnDoe<user@example.com>
最終行のRepli-To:はreply-to-author機能が使えるように設定しておかなければならない。これはreply-to-list機能がFrom:ヘッダフィールド内の変更によって実現される場合を想定したものである。このようにして、これらのフィールドの元々の意味が入れ替わる。
作成者を変更することは通常は正当ではなく、そのデータの意味と見た目の想定された関係や、その自動的な利用を損なうことになる。メーリングリストを仕事の調整のために用い、From:フィールドを添付ファイルの作成者として割り当てるツールを配備するコミュニティが存在している。[22]
ラップされたメッセージを解釈できるメールクライアントを使う場合、メッセージのラッピングは上手く動作する。ただ、いくつかの国で法的にそうせざるを得ない場合や、日常的にSPF認証に失敗することがすべての認証をより脆弱なものとしている場合を除けば、何も変更しないのが最も明白な解決法だと思われる。[23]
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を実装していることが調査によって判明した。
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 thegit commit's from field