[ 到達性と送信者のルール ]

サブスクライブ解除の処理と必要なヘッダーのDKIMカバレッジ

有効なDKIM署名が両方の購読解除フィールドをカバーしていることを確認し、ダウンストリーム処理で署名された操作が保持されていることを確認します。

EmailAuth研究チームによる · 3 分で読めます

【ポイント】

  • 有効なDKIM署名が両方の購読解除フィールドをカバーしていることを確認し、ダウンストリーム処理で署名された操作が保持されていることを確認します。
  • 同じ有効なDKIM署名が両方の購読解除フィールドをカバーする必要があります。ある署名のパスと別の署名の範囲を組み合わせないでください。
このページでは

メッセージには有効な DKIM署名 一方、購読解除フィールドは署名されていません。これは意味のあるギャップです。メッセージを検証する受信者は、必ずしも通知されたオプトアウト アクションを検証しているわけではありません。一般的なものだけでなく、署名の範囲を検査する DKIM パスラベル。

操作を保護する署名を見つける

RFC 8058では、少なくとも 1 つの有効なDKIM署名が必要です List-Unsubscribe およびList-Unsubscribe-Post 。両方のフィールドが、有効な署名の h= タグ内に存在する必要があります。必要な署名が欠落していると、受信者が仕様に基づいてワンクリック購読解除を提供しない理由になります。 RFC 8058セクション 4.

メッセージには複数の署名が含まれる場合があります。一方の有効性ともう一方のヘッダー カバレッジを組み合わせて、そのペアで十分であるとみなさないでください。必須フィールドをカバーする単一の有効な署名を特定し、その署名者を保持します。 セレクタ そして検証結果。これは、どの署名が影響しているかを確認することとは別のものです。 DMARC アライメント.

関連する署名ステップの前にヘッダーを配置します。

メッセージ構築パイプラインをマップします: アプリケーション テンプレート、リスト処理、ゲートウェイ変換、署名者、および最終的な送信ルート。サービスが署名後に購読解除フィールドを追加した場合、以前の署名がそれらをカバーせずに有効なままになる可能性があります。修正するには、適切な署名の前にフィールドを配置するか、後の有効な署名でフィールドをカバーするようにします。

最後に出力されたメッセージを読みます。 RFC 6376 、繰り返されるフィールド名の処理方法を含む、h= リストとヘッダーの選択ルールが定義されています。メッセージ内の任意の場所で「list-unsubscribe」を文字列検索することは、カバレッジ テストではありません。フィールドと変換が重複している場合は、実際の署名入力を注意深く検査する必要があります。 RFC 6376セクション 3.5 および 5.4.

署名付き変更と署名なし変更を区別する

管理されたテスト メッセージの有効な署名が両方の購読解除フィールドをカバーしていると想像してください。署名付き URI を別の値に変更すると、署名付き入力も変更されます。通常のDKIM検証では、元の署名では変更された入力が検証されなくなります。対照的に、両方のフィールドを省略した署名は、署名されていない値が変更された後も有効なままになります。これは、汎用パスがすべてのフィールドを認証できない理由を説明します。

これらはプロトコルベースの期待値であり、実行される暗号化フィクスチャではありません。実際の認可された突然変異テストには、正確な元のバイト、選択された署名、および正しい検証キーが必要です。挿入されたテスト キーは、パブリックDNS来歴や受信結果の履歴ではなく、そのテストの暗号化関係のみを示します。オリジナルを保存し、別のコピーを変更します。

署名されたパス全体を確認する

カバレッジを修正した後、目的のルートを通じて承認されたテスト メッセージを再送信し、受信側で検証します。リンクの書き換え、ゲートウェイの編集、または後のリスト プロセッサによって、対象となるフィールドが変更される可能性があります。所有者が検証が分岐する最初の段階を特定できるように、可能な場合は変換前サンプルと最終サンプルを保存します。

h=.これによりRFC 8058要件を満たさずに署名を保存しやすくなります。ゲートウェイでアクションを変換する必要がある場合は、最終的な署名境界を調整し、変換された URI が正しい受信者とリストにマッピングされていることを確認します。

動作確認を完了してください

署名カバレッジにより、アドバタイズされたフィールドが認証されます。エンドポイントが要求された抑制を実行することを証明するものではありません。制御されたサブスクリプションを使用して、POST とダウンストリーム次回送信除外を個別にテストします。逆に、エンドポイントが動作していても、署名カバレッジの欠落は修復されません。

クロージャ レコードは、有効なカバー署名、正確な最終メッセージ、エンドポイント スコープ、および観察された抑制結果を識別する必要があります。プロバイダー UI の表示は、正しい署名の約束された結果ではなく、別個の観察として保持してください。

署名固有のクロージャ記録を保持する

最終メッセージ、署名者、セレクター、対象となる 2 つのフィールド、およびその特定の署名の検証結果を記録します。エンドポイントと抑制の結果を別々に記録します。後のゲートウェイがフィールドを変更する場合は、必要なカバレッジを削除するのではなく、署名境界を修復します。

[ 取り除く ]

有効なDKIM署名が両方の購読解除フィールドをカバーしていることを確認し、ダウンストリーム処理で署名された操作が保持されていることを確認します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

最終的なカバー署名を確認する

パイプラインの順序によって、何が保護されるかが決まります。

次のステップ

  1. h= と妥当性を一緒に検査します。
  2. 下流の突然変異を追跡します。
  3. 意図したルートで再テストします。

CISO / SecOps

アクションの整合性を維持する

無署名のオプトアウト対象は、無関係な適用範囲を無効にすることなく変更できます。

次のステップ

  1. 重複したヘッダーを確認します。
  2. プロダクションキーを保護します。
  3. 分離された突然変異フィクスチャを使用します。

創業者 / 非技術系

合格バッジ以上の証拠を要求する

有効な署名では、重要なフィールドが省略される場合があります。

次のステップ

  1. 報道の証拠を求めてください。
  2. ゲートウェイの所有権を割り当てます。
  3. 署名と抑制の受け入れを分離する。

[ よくある質問 ]

よくある質問

DKIMパスは、購読解除ヘッダーがカバーされていることを証明しますか?

いいえ。有効な署名の h= リストを調べてください。

ある署名の適用範囲を別の署名の有効性と組み合わせることができますか?

いいえ。有効な署名自体が両方の必須フィールドをカバーしている必要があります。

ヘッダーは署名後に追加する必要がありますか?

後で有効な署名がそれらをカバーしない限り、そうではありません。

なぜ URL の突然変異をテストするのでしょうか?

これは、署名がアドバタイズされた購読解除ターゲットを実際に保護しているかどうかを示します。

突然変異の例は何を予測しますか?

カバーされる URI を変更すると、署名付き入力が変更されます。省略されたフィールドを変更すると、それ以外の場合は有効な署名がそのまま残される可能性があります。これらは予想であり、記録された検証結果ではありません。

注入されたテスト キーはパブリックDNS認証を証明しますか?

いいえ。テストキーの検証では、テストされた暗号化関係のみが確立され、 DNS出所や受信者の履歴結果は確立されません。

h= からフィールドを削除するとRFC 8058準拠を解決できますか?

いいえ。署名が有効なままであっても、必要な補償範囲が削除されます。

署名報道は弾圧が機能することを証明するのか?

いいえ。エンドポイントの動作とダウンストリームの除外を個別にテストします。

[ 情報源 ]

情報源

  1. RFC 8058ワンクリック購読解除

    セクション §3.1 · §3.2 · §4 · §5 · §6

  2. RFC 6376 DKIM

    セクション §3.5 · §5.4 · §6.1

  3. RFC 9989 DMARC

    セクション §4.4 · §5.3.5

[ 用語集 ]

用語集

ヘッダーカバレッジ
DKIM署名の署名付き入力に含まれる特定のメッセージ フィールド。
h= tag
署名付きヘッダー フィールド名をリストするDKIM署名タグ。
署名境界線
保護されたメッセージ コンテンツが検証可能な状態を維持する必要があるパイプライン ポイント。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース