← RFC Reference

RFC 6377: DKIM とメーリングリスト

このページが存在する理由

DKIM（RFC 6376）は、暗号ハッシュを使用してメールヘッダーと本文に署名します。署名後の変更は署名を無効にします。メーリングリストは、設計上、転送中にメッセージを変更します。これにより、基本的な緊張が生じます。

• DKIMは、メッセージが署名通りに到着することを望んでいます。
• メーリングリストは、フッターを追加し、「[リスト名]」を件名の先頭に付け、List-*ヘッダーを追加し、Fromアドレスを書き直し、メッセージをダイジェストでラップします。

DMARCが登場し（DKIMまたはSPF整合が必要）、この緊張は配信可能性の危機となりました。p=reject DMARCポリシーを持つドメインからメーリングリストに送信されたメッセージは、すべてのリストサブスクライバーに対してバウンスし始めました。RFC 6377が公開され、問題を文書化し、軽減戦略を推奨しました。

仕組み

メーリングリストがメッセージに対して実行すること

一般的なメーリングリストマネージャー（Mailman、Sympa、LISTSERV、Google Groups）は、以下のいずれかの組み合わせを実行する可能性があります。

署名検証フロー

; ステップ1：作成者がDKIM署名済みメッセージをリストに送信
From: alice@example.com
To: dev-list@lists.example.org
Subject: Proposed API change
DKIM-Signature: d=example.com; h=from:to:subject; ...

; ステップ2：リストソフトウェアがメッセージを変更
From: alice@example.com            ← 変更されない（または書き直される）
To: dev-list@lists.example.org
Subject: [dev] Proposed API change  ← 変更：接頭辞を追加
List-Id: <dev-list.lists.example.org>  ← 追加
DKIM-Signature: d=example.com; h=from:to:subject; ...

; 元の本文＋追加されたフッター
The body text here...

--
To unsubscribe, visit https://lists.example.org/unsub  ← 追加

; ステップ3：受信者のサーバーがDKIMを検証
; 結果：失敗（件名と本文は署名後に変更されました）

リスト運営者向けの推奨実践

RFC 6377は、メーリングリストが変更を最小限にしてDKIM署名を保持することを推奨しています。

1. 件名ヘッダーを変更しないでください。[list-name]の接頭辞を付けることは避けてください。代わりにList-Idヘッダーを使用してください。メールクライアントはそれでフィルタリングできます。
2. 本文フッターを追加しないでください。フッターコンテンツが必要な場合はMIMEカプセル化を使用するか、既存の本文に追加するのではなく、フッターを別のMIMEパートとして追加してください。
3. 新しいDKIM署名を追加してください。リストは、独自のDKIMキー（d=lists.example.org）で変更されたメッセージに署名する必要があります。これは元の署名を修復しませんが、リストドメインからの有効な署名を提供します。
4. DMARC用のFrom書き換えを検討してください。元の送信者のドメインがp=rejectを公開している場合、Fromヘッダーをリストドメインに書き直し、元の送信者をReply-Toに入れます。これは「From munging」として広く実装されています。

送信者向けの推奨実践

1. 緩和された正規化を使用してください。c=simple/simpleではなくc=relaxed/relaxedで署名してください。緩和された正規化は、一部のリストソフトウェアが導入する軽微な空白の変更を許容します。
2. 本質的なヘッダーのみに署名してください。h=タグは、あなたが気にするヘッダー（From、Subject、Date、To、Message-ID）をカバーするべきですが、リストが一般的に追加するヘッダー（List-Id、List-Unsubscribe）はカバーしないようにしてください。
3. l=本文長タグに注意して使用してください。l=タグは署名される本文の量を制限するため、追加されたフッターは署名を破壊しません。ただし、これにはセキュリティに関する影響があります。攻撃者は、署名された部分の下に悪意のあるコンテンツを追加する可能性があります。

重要な技術的詳細

DMARC複雑性

RFC 6377はDMAC（RFC 7489）より前ですが、それが説明する問題はDMARCがデプロイされると非常に厳しくなりました。DMARC p=rejectの場合：

; 作成者のドメインは厳密なDMARCを公開
_dmarc.example.com TXT "v=DMARC1; p=reject; ..."

; メッセージはメーリングリストを通過し、DKIMが破壊される
; 受信者のサーバーがDMARCをチェック：
;   - SPF：失敗（エンベロープセンダーはリストで、example.comではない）
;   - DKIM：失敗（リスト変更により署名が破壊された）
;   - DMARC：失敗→拒否
; 結果：すべてのリストサブスクライバーに対してメッセージがバウンス

これはARC（RFC 8617）が開発された理由です。メーリングリストのような仲介者間で認証結果を保存するためです。

モダンソリューションとしてのARC

Authenticated Received Chain（ARC）プロトコルにより、メーリングリストなどの仲介者は、メッセージを変更する前に元の認証結果を記録できます。受信者のサーバーは、ARC チェーンを使用して、リストが元の署名を破壊した後でも、元のDKIM/SPFパスを回復できます。

From書き換え戦略

メーリングリストの最も一般的なDMARC軽減は、From書き換えです。

; 元のメッセージ
From: Alice Smith <alice@strict-dmarc.com>

; リストFrom書き換え後
From: Alice Smith via Dev List <dev-list@lists.example.org>
Reply-To: Alice Smith <alice@strict-dmarc.com>

これにより、表示テキストとReply-Toで元の送信者のアイデンティティを保持しながら、Fromドメインをリストの署名と一致させます。

一般的な間違い

• c=simple/simple正規化を使用します。単純な正規化は、軽微な空白の変更でも失敗します。メッセージがメーリングリストまたは他の仲介者を通過する可能性がある場合は、常にc=relaxed/relaxedを使用してください。
• あまりにも多くのヘッダーに署名します。DKIM h=タグにList-IdやList-Unsubscribeなどのヘッダーを含めると、リストがそれらのヘッダーを追加するときに失敗することが保証されます。あなたが生成するヘッダーのみに署名してください。
• リストを考慮せずにp=reject DMARCを公開します。ユーザーがメーリングリストに送信する場合、厳密なDMARC拒否ポリシーにより、リストメッセージはすべてのサブスクライバーに対してバウンスします。p=quarantineを検討するか、ユーザーが影響を理解していることを確認してください。
• リスト運営者が独自のDKIM署名を追加していません。メッセージを変更した後、リストは独自のキーで署名する必要があります。これがないと、メッセージは有効なDKIM署名なしで到着します。
• 単独でl=本文長に依存します。追加されたフッター過去の署名を保持できますが、l=は署名された境界の下のコンテンツインジェクションを許可するため、多くのベストプラクティスガイドによって非推奨になりました。
• ARCを実装していません。モダンリストソフトウェアはARCを実装して元の認証チェーンを保存する必要があります。ARCがないと、受信者はメッセージが元々認証されたことを知る方法がありません。

配信可能性への影響

• リストメール上の破損したDKIMはバウンスを引き起こします。DMARC p=rejectの場合、破損したDKIMは拒否されたメッセージを意味します。リストサブスクライバーはメールの受け取りを停止し、リスト運営者はバウンスに氾濫します。
• From書き換えは配信可能性を保持しますが、送信者のアイデンティティを変更します。受信者は、元の送信者ではなく、From内のリストアドレスを表示します。これはユーザーを混乱させる可能性がありますが、配信を確保するための最も信頼できる方法です。
• ARCはリストメールの配信を改善します。主要プロバイダー（Gmail、Microsoft、Yahoo）はARCチェーンを尊重します。評判の良いリストからの有効なARCシールは、破損した元のDKIM署名をオーバーライドできます。
• リスト評判の問題です。受信サーバーはリストのドメイン評判を評価します。良好な送信実践、適切なDKIM署名、ARC実装を備えた、よく管理されたリストは、不正なリストより優れた配信率が表示されます。
• リストトラフィックからのバウンス率を監視してください。メーリングリストに送信されたメッセージのバウンス数の急増が表示される場合は、リストがDKIM署名を破壊する方法でメッセージを変更しているか、ARCを実装しているかを確認してください。

Related RFCs