メインコンテンツまでスキップ

3. Terminology and Definitions (用語と定義)

本セクションでは、文書の残りの部分で使用される用語を定義します。

本文書のキーワード「しなければならない (MUST)」、「してはならない (MUST NOT)」、「必須である (REQUIRED)」、「すべきである (SHALL)」、「すべきでない (SHALL NOT)」、「すべきである (SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される (RECOMMENDED)」、「してもよい (MAY)」、および「任意である (OPTIONAL)」は、[KEYWORDS] に記載されているとおりに解釈されるものとします。

読者は [EMAIL-ARCH] の内容に精通することが推奨されます。特に、その文書は、さまざまなコンテキストで同じまたは別々に表示される可能性のあるメッセージングインフラストラクチャのさまざまな役割を定義しています。たとえば、ドメイン所有者は、DMARCが基づいているメッセージングセキュリティメカニズムを介して、別の役割を持つ第三者にドメイン所有者としてメールを送信する能力を委任できます。本文書は、そのような役割間の区別には対処していません。読者は続行する前にその資料に精通することが推奨されます。

以下の用語も使用されます：

Authenticated Identifiers (認証された識別子)：認証技術を使用して検証されるドメインレベルの識別子は、「認証された識別子」と呼ばれます。サポートされているメカニズムの詳細については、セクション4.1を参照してください。

Author Domain (作成者ドメイン)：RFC5322.Fromフィールドから抽出された、見かけ上の作成者のドメイン名。

Domain Owner (ドメイン所有者)：DNSドメインを所有するエンティティまたは組織。ここでの「所有する」という用語は、参照されているエンティティまたは組織がそのDNSドメインの登録を保持していることを示します。ドメイン所有者は、複雑でグローバルに分散した組織から、技術的でないクライアントの代わりに働くサービスプロバイダー、個人ドメインの維持を担当する個人まで、さまざまです。本仕様では、この用語を [EMAIL-ARCH] で定義されている管理管理ドメインに類似したものとして使用しています。また、それらが直接の管理ドメインの外にある場合、報告受信者などの委任先を指すこともできます。

Identifier Alignment (識別子の整合)：RFC5322.Fromアドレスのドメインが、SPFまたはDKIM（または両方）によって検証されたドメインと一致する場合、識別子の整合があります。

Mail Receiver (メール受信者)：メールを受信して処理するエンティティまたは組織。メール受信者は、1つ以上のインターネットに面したメール転送エージェント (MTAs) を運用します。

Organizational Domain (組織ドメイン)：ドメイン名レジストラに登録されたドメイン。より正確な方法がない場合、ヒューリスティックが使用されます。登録されたドメイン名が常に単にトップレベルDNSドメインに1つのコンポーネントを加えたもの（例：「com」がトップレベルドメインである「example.com」）であるとは限らないためです。組織ドメインは、セクション3.2にあるアルゴリズムを適用することによって決定されます。

Report Receiver (報告受信者)：本文書で説明されている報告メカニズムを実装している別のオペレーターから報告を受信するオペレーター。そのようなオペレーターは、自身のメッセージに関する報告、または別のオペレーターに関連するメッセージについての報告を受信している可能性があります。この用語は、これらの報告を受信して処理するシステムコンポーネントと、それらを運用する組織に総称的に適用されます。

3.1. Identifier Alignment (識別子の整合)​

メール認証技術は、個々のメッセージのさまざまな（そして異なる）側面を認証します。たとえば、[DKIM] はメッセージに署名を付けたドメインを認証しますが、[SPF] は [SMTP] のRFC5321.MailFrom (MAIL FROM) 部分に表示されるドメイン、またはRFC5321.EHLO/HELOドメイン、またはその両方を認証できます。これらは異なるドメインである可能性があり、通常エンドユーザーには表示されません。

DMARCは、RFC5322.Fromドメインが認証された識別子と一致する（整合する）ことを要求することによって、RFC5322.Fromドメインの使用を認証します。RFC5322.FromドメインがDMARCメカニズムの中心的なアイデンティティとして選択されたのは、それが必須のメッセージヘッダーフィールドであり、したがって準拠メッセージに存在することが保証されており、ほとんどのメールユーザーエージェント (MUAs) がRFC5322.Fromフィールドをメッセージの発信者として表現し、このヘッダーフィールドのコンテンツの一部またはすべてをエンドユーザーにレンダリングするためです。

したがって、このフィールドは、エンドユーザーがメッセージのソースを識別するために使用するものであり、したがって悪用の主要なターゲットです。メールサービスプロバイダーなどの多くの注目度の高いメールソースは、メールが生成される前に送信エージェントが認証されている必要があります。したがって、これらのメールボックスの場合、本文書で説明されているメカニズムは、エンドユーザーがこれらのさまざまな保護が提供されていることを知っている場合、メッセージが実際にそのメールボックスに関連付けられているエージェントによって発信されたという強力な証拠を受信者のエンドユーザーに提供します。

このコンテキストでのドメイン名は、[DNS-CASE] に従って大文字と小文字を区別しない方法で比較されます。

[MAIL] に従って有効でないメッセージ、特に不正な形式、存在しない、または繰り返されたRFC5322.Fromフィールドを持つメッセージでは、識別子の整合が発生できないことに注意することが重要です。その場合、メッセージに適用されるDMARCポリシーを決定する信頼できる方法がないためです。したがって、DMARC操作は、入力が有効なRFC5322メッセージオブジェクトであることを前提としており、そのような非準拠のケースの処理は、本仕様の範囲外です。これについての詳細な議論は、セクション6.6.1にあります。

DMARCが入力として受け取る各基礎認証技術は、成功すると出力として認証されたドメインを生成します。DMARCの観点から、各技術は「厳格 (strict)」モードまたは「緩やか (relaxed)」モードで操作できます。ドメイン所有者は、メール受信者が、それらのメカニズムが検証するドメインと完全に一致するRFC5322.Fromドメインを持つメッセージにのみDMARC処理を適用することを望む場合、通常厳格モードを選択します。緩やかモードは、オペレーターが検証されたドメインのサブドメインを持つメッセージフローにも影響を与えたい場合に使用できます。

3.1.1. DKIM-Authenticated Identifiers (DKIM認証された識別子)​

DMARCは、DKIM認証の結果に基づく識別子の整合を、厳格または緩やかにすることを許可します。（これらはDKIMの「simple」および「relaxed」正規化モードとは関係ないことに注意してください。）

緩やかモードでは、[DKIM]で認証された署名ドメイン（署名の「d=」タグの値から取得）とRFC5322.Fromドメインの両方の組織ドメインが、識別子が整合していると見なされるためには等しくなければなりません。厳格モードでは、両方の完全修飾ドメイン名 (FQDNs) 間の完全な一致のみが識別子の整合を生成すると見なされます。

説明のために、緩やかモードでは、検証されたDKIM署名が「d=」ドメイン「example.com」で正常に検証され、RFC5322.Fromアドレスが「[email protected]」である場合、DKIM「d=」ドメインとRFC5322.Fromドメインは「整合している」と見なされます。厳格モードでは、「d=」ドメインがアドレスのFQDNと完全に一致しないため、このテストは失敗します。

ただし、「d=com」の値を持つDKIM署名は、「com」がすべての公開サフィックスリストに表示されるべきであり（付録A.6.1を参照）、したがって組織ドメインになることはできないため、「整合している」結果を許可することはありません。

識別子の整合が必要なのは、メッセージがメーリングリストで使用されるドメインや悪意のある行為者のドメインを含む、任意のドメインからの有効な署名を持つことができるためです。したがって、単に有効な署名を持っているだけでは、作成者ドメインの真正性を推測するのに十分ではありません。

単一のメールには複数のDKIM署名を含めることができ、任意のDKIM署名が整合して検証されればDMARC「合格 (pass)」と見なされることに注意してください。

3.1.2. SPF-Authenticated Identifiers (SPF認証された識別子)​

DMARCは、SPF認証の結果に基づく識別子の整合を、厳格または緩やかにすることを許可します。

緩やかモードでは、[SPF]で認証されたドメインとRFC5322.Fromドメインは同じ組織ドメインを持っている必要があります。厳格モードでは、完全なDNSドメインの一致のみが識別子の整合を生成すると見なされます。

RFC5321.HELO アイデンティティは、[SPF] に従った「純粋なSPF」実装がその識別子をチェックするにもかかわらず、DMARCのコンテキストでは通常使用されません（それ以外の場合nullの逆パスを「偽装」する必要がある場合を除く）。

たとえば、メッセージがRFC5321.MailFromドメイン「cbg.bounces.example.com」でSPFチェックに合格し、RFC5322.Fromフィールドのアドレス部分に「[email protected]」が含まれている場合、認証されたRFC5321.MailFromドメイン識別子とRFC5322.Fromドメインは、緩やかモードでは「整合している」と見なされますが、厳格モードではそうではありません。

3.1.3. Alignment and Extension Technologies (整合と拡張技術)​

将来DMARCが他の認証メカニズムの使用を含むように拡張される場合、拡張は、RFC5322.Fromドメインとの整合を検証できるようにドメイン識別子の抽出を許可する必要があります。

3.2. Organizational Domain (組織ドメイン)​

組織ドメインは、以下のアルゴリズムを使用して決定されます：

  1. 「公開サフィックス」リスト、つまり登録用に予約されたDNSドメイン名のリストを取得します。一部の国のトップレベルドメイン (TLDs) は特定の登録要件を設けています。たとえば、イギリスは企業登録を「.co.uk」の下に配置します。「.com」などの他のTLDは、トップレベルDNSドメインのIANAレジストリに表示されます。公開サフィックスリストは、これらすべての和集合です。付録A.6.1には、公開サフィックスリストの取得に関するいくつかの議論が含まれています。

  2. 対象のDNSドメイン名を「n」個の順序付けられたラベルのセットに分割します。これらのラベルに右から左へ番号を付けます。たとえば、「example.com」の場合、「com」はラベル1、「example」はラベル2になります。

  3. 公開サフィックスリストで、対象DNSドメインで見つかったラベルの最大数に一致する名前を検索します。その数を「x」とします。

  4. 公開サフィックスリストから一致した名前を使用し、対象ドメインから「x+1」番目のラベルをそれに接頭辞として付けて、新しいDNSドメイン名を構築します。この新しい名前が組織ドメインです。

したがって、「com」はIANAに登録されたTLDであるため、「a.b.c.d.example.com」の対象ドメインは、「example.com」の組織ドメインを持ちます。

サフィックスを決定するプロセスは現在ヒューリスティックなものです。どのリストも正確または最新であることが保証されていません。

に最終更新