DMARCアーキテクチャ：IDの配置

はじめに

このドキュメントでは、一般的なDomain-based Message Authentication, Reporting and Conformance(DMARC)アーキテクチャの概念と、DMARCに関連するSender Policy Framework(SPF)およびDomainKeys Identified Mail(DKIM)のアライメント要件について説明します。 

  

用語

このセクションでは、このドキュメントで使用される主な用語について説明し、その定義を示します。 

• EHLO/HELO:RFC 5321で定義されているように、SMTPセッションの初期化中にSMTPクライアントのアイデンティティを提供するコマンド。
• From header:「From:」フィールドには、メッセージの作成者を指定します。通常は、RFC 5322で定義されている表示名（メールクライアントによってエンドユーザに表示される名前）と、ローカル部分とドメイン名を含む電子メールアドレス(たとえば、「John Doe」 <johndoe@example.com>)が含まれます。
• MAIL FROM：これは、SMTPセッションの開始時にMAILコマンドから取得され、RFC5321で定義されている送信者の識別情報を提供します。これは、エンベロープ送信者、リターンパス、またはバウンスアドレスとも呼ばれます。

  

DMARC：識別子の配置 

DMARCは、DKIMおよびSPFの認証内容をFromヘッダーにリストされている内容に結び付けます。これはアライメントによって行われます。  調整では、SPFとDKIMによって認証されたドメインIDが、エンドユーザに表示される電子メールアドレスのドメインと一致する必要があります。

まず、IDとは何か、DMARCを基準としてIDが重要である理由について説明します。

  

識別子

識別子は、認証されるドメイン名を識別します。

DMARCに関連する識別子：

• SPF:
  
  SPFは、SMTPカンバセーションのMAIL FROM部分またはEHLO/HELO部分、あるいはその両方に含まれるドメインを認証します。これらは異なるドメインである場合があり、通常はエンドユーザには表示されません。

• DKIM:
  
  DKIMは、d=タグ内の署名に付加されている署名ドメインを認証します。 

  

これらの（SPFとDKIM）IDは、Fromヘッダーで取得されたドメインIDに対して認証されます。From headerドメインが使用される理由は、このドメインがメッセージの発信者にとって最も一般的なMail User Agent(MUA)フィールドであり、メッセージの送信元（送信者）を識別するためにエンドユーザが使用するフィールドであるためです。これによってFromヘッダーも悪用の主な標的になります。 

  

注意:DMARCで悪用を保護できるのは、有効なFromヘッダーに対してのみです。

  

DMARCは次で動作できません：

• RFC 5322ヘッダーの形式が正しくない、存在しない、または繰り返される
• 非準拠ヘッダー（検証されないため）
• ヘッダーに複数のドメインIDがある場合(*)

  

したがって、DMARCに加えて、非準拠の不正なヘッダーを持つメッセージを識別し、これらをDMARC非対応ヘッダーとしてマークして表示する方法を実装するプロセスが存在する必要があります。

  

(*) DMARCは、ヘッダーから単一のドメインIDを抽出する必要があります。ヘッダーに複数の電子メールアドレスがある場合、このヘッダーはほとんどのDMARC実装でスキップされます。複数のドメインIDを持つ処理ヘッダーは、DMARC仕様では範囲外として記述されています。 

  

Cisco ESAが複数のドメインIDを検出できる場合、メールログに適切なメッセージが残されます。

(Machine esa.lab.local) (SERVICE)> grep -i "verification skipped" mail_logs

Tue Oct 16 14:13:52 2018 Info: MID 2003 DMARC: Verification skipped (Sending domain could not be determined)

  

識別子の配置

IDの調整は、SPFまたはDKIM、あるいはその両方によって認証されるドメインとFromヘッダーの間の関係を定義します。調整は、SPFまたはDKIMの検証が成功した後に追加で満たす必要がある照合プロセスです。DMARC認証プロセスでは、SPFまたはDKIMで使用されるID（ドメインID）の少なくとも1つが、Fromヘッダーアドレスのドメイン部分と調整されている必要があります。

  

DMARCでは、次の2つの位置合わせモードが導入されています。

• strictモードでは、ドメイン名の完全一致（整列）が必要です
• リラックスモードでは、同じドメインのサブドメインが許可されます

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

  

DKIMの調整

DKIMドメイン識別子は、DKIMシグニチャのd=タグを確認することによって取得され、From headerドメインと比較されて、DKIMシグニチャを正常に検証します。

  

たとえば、ドメインd=blog.cisco.comに代わってメッセージに署名すると、ドメインblog.cisco.comが署名者として識別されます。 DMARCはこのドメインを使用し、Fromヘッダーのドメイン部分(たとえば、noreply@cisco.com)と比較します。ストリクトモードでは、これらのID間のアラインメントは失敗しますが、リラックスモードを使用すると成功します。

  

注:1つの電子メールに複数のDKIM署名を含めることができます。いずれかのDKIM署名が調整され、検証された場合、その電子メールはDMARCの「合格」と見なされます。

  

SPFの調整

  

SPF(spfv1)メカニズムは、次の場所から配信されるドメインIDを認証します。

• MAIL FROM IDENTITY（MAIL FROMコマンド）
• HELO/EHLO ID（HELO/EHLOコマンド）

  

デフォルトでは、MAIL FROMドメインIDの認証が試行されます。HELOドメインIDは、バウンスメッセージなどの空のMAIL FROM IDを持つメッセージに対してのみDMARCによって認証されます。

  

この一般的な例としては、Fromヘッダー(noreply@blog.cisco.com)に含まれるメッセージと異なるMAIL FROMアドレス(noreply@cisco.com)を使用してメッセージが送信される場合があります。noreply@blog.cisco.comのMAIL FROM domain identity部分は、relacedモードではnoreply@cisco.comのFrom headerドメインに対応しますが、strictモードでは対応しません。 

  

線形モードタグ

DMARCアライメントモードは、adkimおよびaspfアライメントモードタグを使用してDMARCポリシーレコード上に定義できます。 これらのタグは、DKIMまたはSPF識別子のアラインメントに必要なモードを示します。 

モードはrelaxedまたはstrictに設定できます。タグが存在しない場合はrelaxedがデフォルトになります。これは、tag-valueの下で次のように設定できます。

• r: リラックスモード
• s： ストリクトモード

参考

• RFC5321 – シンプルメール転送プロトコル
• RFC5322 – インターネットメッセージ形式
• RFC6376 - DomainKeys Identified Mail(DKIM)シグニチャ
• RFC7208：電子メールでのドメインの使用を承認するためのSender Policy Framework(SPF)
• RFC7489 – ドメインベースのメッセージ認証、レポート、および準拠(DMARC)