メール

安全なメールサーバーのためのDKIM正規化と署名の安定性

どうすればいいのか、2つの文章で説明しよう。 DKIMの正規化 ヘッダーとボディーを標準化することで、わずかな輸送の変更にも署名が有効であり続けるようにした。このようにして署名暗号チェックを危険にさらすことなく、実際のメール・チャネルで高い配達率を達成する。.

中心点

すぐにでも始められるように、以下の主要な点をまとめておこう。 正規化 そしてシグネチャーの安定性。.

リラックス フォーマットの詳細が同じになり、有効なチェックの可能性が高まる。.
シンプル は厳格で、わずかな変化でより早く壊れる。.
ヘッダー 通常、リラックスした態度で接し、体もリラックスさせる必要がある。.
転送, ゲートウェイとオートレスポンダーのリップルフォーマット。.
ＤＭＡＲＣ SPFが失敗した場合、一貫性のあるDKIMチェックから利益を得ることができる。.

私がこれらのポイントを一貫して実行しているのは、小さなフォーマットの変更が頻繁に起こるからである。 妥当性 署名の特にメーリングリストやゲートウェイでは モード 配信またはスパムフォルダ経由スペースと改行の取り扱いを緩和することで、以下のチェックがより確実になります。署名. .同時に、操作の余地がないように、関連するヘッダーに目を光らせている。こうすることで セキュリティ そして日常使用への適合性。.

DKIMの正規化とはどういう意味ですか？

正規化とは、署名の前にヘッダーとボディーを統一した形にするために私が使っているルールのことである。審査ターゲットのサーバーでは、同じバイト列が表示されます。ゲートウェイはヘッダーを挿入し、アーカイブシステムは改行に触れ、スキャナーはエンコーディングを変更する。 リラックス. .シンプル・モードはほとんど逸脱を許容しないが、リラックス・モードはスペースとブレークを標準化する。署名は、外観上の変更にもかかわらず有効である。DKIM署名の中で、私はc=header/bodyとしてモードを定義する。 ボディ. .私がrelaxed/relaxedを好むのは、トランスポートチェーンに沿った典型的なフォーマット訂正では誤警報が発生しないからである。なぜなら、トランスポート・チェーンに沿った典型的なフォーマット訂正は誤報を発生させないからである。 ディーケーアイエム-一方、不必要な拒否はあまり起こらない。.

シグネチャの耐久性のために正規化が重要な理由

最大限の一貫性を目指している。署名, なぜなら、有効なチェックをするたびに、受信者との信頼関係が構築されるからです。メーリングリスト経由の転送では、件名に接頭辞を入れたり、フッターを追加したりします。構成その場合、すぐに壊れてしまう。セキュリティゲートウェイはヘッダーとボディを部分的に書き換えるので、relaxedの方がクッションになり、無効な署名が少なくなる。アーカイブシステムやオートレスポンダーはメタデータを変更するので、私は意識的に署名されたヘッダーを選択し、relaxedを使用している。DKIMが有効なままであることが多ければ多いほど、私のDKIMに対する評価は明確になる。 ドメイン そして、正当なメッセージがスパムで終わることが少なくなります。これにより、ブランドの評判が守られ、コミュニケーション・チャネルが混乱することがなくなります。.

リラックスしたシンプルな仕事の詳細

私の決定が再現可能であることを保証するために、私は正典化の特定のルールを守っている：

ヘッダーのリラックスヘッダー名を小文字にし、コロンの周りの余計な空白を削除し、連続する行を1行に折り畳み、ヘッダー値内の複数の空白を正確に1つの空白にする。署名されるヘッダーの順序はh=リストに従って保持され、重複はそこで指定された順序で考慮される。.
シンプルなヘッダー私は各バイト列を送信されたとおりに残す。中間駅でスペースを追加したり、改行したり、再フォーマットしたりするたびに、チェックは中断される。.
体がリラックスしているCRLFで行を区切り、行末の空白を削り、単語と単語の間の空白を1つに減らし、本文の最後に余分な空行を削除する。完全に空のメッセージは1行の空行として正規化される。.
シンプルなボディ行末を含むすべての行の完全一致が必要です。変換された行末でもチェックに失敗することがあります。.

これらのルールは、ヘッダーの折りたたみ、空白の修正、7bit/8bit変換、異なるMTA実装といった典型的なトランスポートの変更を反映している。relaxedを使うことで、意味的な操作を隠蔽することなく、外見的な逸脱を防いでいる。.

ベストプラクティス：リラックス vs シンプル

なぜなら、ヘッダー名の大文字表記や追加スペースといった小さなことが、ヘッダーの署名に大きな影響を与えるからだ。審査でないと不必要に傾いてしまう。改行が正規化され、行末のスペースが削られることで、より広いスペースが得られるからだ。 妥当性 トランスポート適応後。c=relaxed/relaxedの組み合わせは、暗号ステートメントを弱めることなく、異種インフラで最も信頼できる結果をもたらします。私はSimpleを特に厳密に管理された内部環境で使用しています。パス-ステーション。オープンなインターネットでは、単純なことは不必要なリスクをもたらし、有効なメッセージが失敗するため、責任あるチームをイライラさせる。大規模なプロバイダーからの受信トレイに対応する人は、リラックス／リラックスの方がはるかにリラックスでき、コストも節約できる。 サポート-時間だ。.

技術的基礎：DKIM署名とキー

私は、送信サーバー上の秘密鍵と、以下のDNS TXTレコードとしての公開鍵を使用しています。 ドメインキー, 受信システムが検証できるようにするためである。DNSエントリには、バージョン、鍵のタイプ、Base64エンコードされた公開鍵が含まれる。キー; 秘密鍵はサーバに安全に残っている。受信者がDKIM署名を発見するとすぐに、DNSレコードに問い合わせ、署名とドメインが一致するかどうかをチェックする。このチェーンは、フォーマット、長さ、セレクタ名を適切に定義し、かつ ファイリング 私的資料の全体像については、コンパクトな電子メールのセキュリティ・マトリックス, これは、SPF、DKIM、DMARC、BIMIの役割を明確に整理したものである。これは、SPF、DKIM、DMARC、BIMIの暗号化ステートメントが メッセージ 追跡可能で永久に検証可能である。.

ヘッダーリスト、パラメーター、安全なデフォルト設定

私はc=だけでなく、他のDKIMパラメータによっても署名の安定性をコントロールしている：

h= は、署名されたヘッダーを、それらが使用される正確な順序でリストしている。私は、From、To、Subject、Date、Message-ID、MIME-Versionといった安定したフィールドを含め、ほとんど常に途中で変化する揮発性のフィールド（Received、Return-Path、Authentication-Results、X-Headerなど）は省いている。.
d= は署名ドメインを指定する。DMARCアライメントでは、受信者がIDを明確に割り当てられるように、送信者ドメイン（または適切なサブドメイン）でd=を選択する。.
s= はセレクタを表します。私は、ローテーションやマルチクライアント・シナリオを明確にするために、日付/サービス参照（例：s=mail2026）を含む説明的な名前を使用しています。.
t= には署名のタイムスタンプが含まれる、, x= オプションで有効期限。古い、遅れたメールを不必要にひっくり返さないように、x=中程度に設定した。.
bh= は正規化されたボディのハッシュであり、コンテンツの完全性を保護する。. b= は、選択されたヘッダーとボディのハッシュを介した実際の署名である。.
l= 部分的なボディ署名はリプレイ攻撃のリスクを高めるので、私はボディ長タグを使用しない。私は、明確な完全性のためにフルボディのハッシュを好む。.
z= (コピーされたヘッダー）は一般的に省略される。付加価値はほとんどないが、データ保護と安定性のリスクが高まる可能性がある。.

鍵の強度にはRSA 2048ビットを使っている。これは広範な互換性があり、パフォーマンスも高く、通常は断片化を引き起こすことなくDNSのTXTレコードに収まる。長すぎる鍵はDNSとリゾルバに問題を引き起こす可能性があり、短すぎる鍵（1024）はセキュリティを低下させる。公開鍵を255文字の文字列にきれいに分割し、正しい逆カンマに注意し、不用意なスペースを避ける。.

メールサーバーへの実装

私はキー生成から始め、明確なセレクタ名を定義し、そのセレクタ名を保持する。 ファイル が混ざらないように、サーバー上で厳密に分離されている。その後、公開鍵をDNSに公開し、解決をチェックして、セミコロン、逆カンマ、および記録. .サーバーの設定で、どのドメインに署名するか、どのヘッダーが署名に含まれるか、どの正規化（通常はc=relaxed/relaxed）を使うかを定義する。その後、さまざまなメールボックスにテストメールを送信し、ヘッダー、本文のハッシュ、使用された正規化を分析します。 セレクター. .運用中、私は配信率、フィードバックループ、DMARCレポートを監視し、異常があれば正規化を調整したり、ヘッダーリストを適応させたりする。このようにして、技術的な基盤をクリーンな状態に保ち評価理解しやすい。

MIME、文字セット、トランスポート変換

私は、MTAやゲートウェイがコンテンツ転送のエンコーディングや文字セット、改行コードを変更することを計画している：

Quoted-PrintableとBase64の比較この2つの間の変換は一般的である。Relaxed-bodyの正規化は、空白や行末の違いを捕らえるが、意味的な変更（MIMEパーツの再パッケージなど）は署名を壊す。.
7bit/8bit変換8bitを7bitに変換するシステムもある。Relaxedは行末を正規化するが、コンテンツが再エンコードされたりラップされたりする場合は、中間宛先での再署名(例えばメーリングリストの場合)か、真正性の連鎖のためのARCだけが助けになる。.
末尾の改行私は、本文の最後がCRLFで正しく終わるようにしている。Relaxedは余分な終了行を削除しますが、simpleは削除しません。.
空っぽの死体relaxでは、空のボディは1行の空行として定義されている。エッジケースを除外するために、テストではこれを明示的にチェックしています。.

HTMLコンテンツについては、インライナー、DLPスキャナー、リンクチェッカーが属性や空白を変更しないか監視している。もしそうなら、署名され、影響を受ける可能性のあるヘッダーの数を少なくし、美容的な介入を最小限にするためにrelaxed/relaxedを主張する。.

典型的なエラーの原因を避ける

不適切な改行、セミコロンや引用符の欠落により、受信者がパブリック・レコードを認識できないのです。キーをきれいにロードする。また、DNSとサーバーファイルの同期がとれていないと、キー変更時に同期がとれないために問題が発生する。走る. .simple/simpleのような厳しすぎる正規化は、メーリングリスト、ゲートウェイ、アーカイブですぐに失敗し、不必要に配信性を損ないます。頻繁に変更される多くのヘッダに署名することは、メッセージの妥当性を危うくするので、同様に危険です。署名脆弱である。そのため、私はバランスの取れたヘッダーリストを使い、From、To、Subject、Dateと適切な補足に焦点を当て、ヘッダーと ボディ 準備ができている。このアプローチは連鎖反応を防ぎ、トラブルシューティングの時間を節約する。.

ヘッダーとボディの正規化の比較

決断を具体的にするために、各モードの効果をコンパクトな表にまとめ、以下のような実用的なヒントを加えた。 セレクション. .比較することで、自分に合ったモードを見つけることができる。 周辺環境 死角を作ることなく。.

アスペクト	シンプル（ヘッダー／ボディ）	リラックス（ヘッダー／ボディ）	実践編
スペースに対する耐性	低く、違いはすぐに壊れる	高く、複数のスペースが標準化されている	混合路線の場合リラックス好意
改行の処理	厳格、フォーマットは正確にフィットしなければならない	一般的なバリアントを正規化	再フォーマット可能なゲートウェイリラックス
転送／メーリングリスト	骨折のリスクが高い	かなり高い抵抗	件名のプレフィックスとフッター和らげる
内部管理されたネットワーク	ホモジニアス・トラックに最適	可能性もある	シンプルは、以下の場合にのみ使用する。駅知られている
推奨される組み合わせ	c=シンプル/ほとんど役に立たない	c=リラックスしている/ほとんどのケースでリラックスしている	リラックスしたヘッダー、ボディリラックス

合成チェックはすべてのメールボックスで機能するわけではないからだ。 ルート マップを作成します。私はまた、中間局が新しいヘッダーを挿入したり、エンコーディングを変更したりしないか定期的にチェックし、それを調整する。構成その後.

モニタリング、DMARC、SPFの相互作用

私はDMARCのレポートを分析し、DKIMやSPFが受信側で有効になる頻度を確認し、その頻度を修正します。設定その結果SPFがリダイレクトで失敗することが多いのは、リダイレクト先のサーバーがSPFレコードにないためであり、そのため信頼性の高いDKIMチェックが必要になる。 サウンド が指定されている。私は適切なDMARCポリシーを使って、SPFやDKIMを通過しないメールを受信者がどのように処理するかを規制している。その際、Header-From、DKIM-d、およびDKIM-dの間のドメイン割り当てが、SPFまたはDKIMを通過しないメールを受信者がどのように処理するかを規制するために、私はアライメント・ルールを守っている。 SPF-mailfromが合う。細かい制御には DMARCポリシーガイド, に、典型的なシナリオと副作用について概説している。DKIMが正規化を通じてより一貫して実行されればされるほど、その効果はより確実になる。 ＤＭＡＲＣ 日常生活の中で。

正規化におけるARCとメーリングリスト

私は、メーリングリストや転送サービスがコンテンツを変更することを考慮しており、元のDKIM署名が無効になることがよくある。日常生活では、2つの戦略が役立ちます：

再契約 リストまたはゲートウェイによって：中間局は元の署名を自身の署名に置き換える。これにより受信者の完全性は保たれるが、元の送信者とのDMARCの整合性はしばしば失われる。.
ARC（認証された受信チェーン）ARCは、オリジナルの配送の認証結果を署名されたチェーンに保存する。これにより、壊れたDKIM署名は保存されませんが、受信者はオリジナルの信頼性を考慮することができます。.

実際には、正規化を緩やかにし、署名付きヘッダーを堅牢なフィールドに減らし、リスト／フォワーダーについてはARCか再署名に頼っている。このようにして、オリジナルの署名の一貫性と、ルートに沿った追跡可能な真正性のチェーンを組み合わせている。.

複数の署名、サードパーティプロバイダー、サブドメイン

例えば、私のメインドメインからの署名と、契約している配送サービスプロバイダーからの署名などです。これにより、フォーマットの変更や再署名によって署名が無効になった場合に備えて冗長性を持たせている。DMARCのアライメントについては、少なくとも1つの署名がドメイン（該当する場合は対応するd=とサブドメインポリシー）から見えるものと一致するようにしています。クライアント環境では、各送信IDを独自のセレクタと鍵で署名し、鍵とDNSレコードをきれいに分離し、責任を明確に文書化します。.

トラブルシューティング：ヘッダーの分析と典型的な指標

私は故障に対して構造的なアプローチを取る：

私はチェックする 認証結果-受信側のヘッダー：どのメソッド（DKIM/SPF/DMARC）がパスし、どれが失敗し、どのセレクタが使われたか？
比較する bh= そして b=ボディ・ハッシュ（bh=）が一致しない場合は、行末の変更、行末のスペース、挿入されたフッター・テキストを探す。.
をチェックする。 h=-リスト：list:そこにリストされているヘッダーが、途中で折り直されたり、並べ替えられたり、追加されたりしたか？Relaxedは空白をインターセプトしますが、定義されたルール外のセマンティックな変更やシーケンスの変更はインターセプトしません。.
私はこう見る。 c=ゲートウェイは再フォーマットしているが、テストはシンプル／シンプルに設定されているか？それからrelaxed/relaxedに切り替えて、もう一度テストする。.
をチェックする。 DNSキーTXTレコードを完全かつ正確に検索できるか、すべてのセグメントが正しく引用されているか、セレクタは正しいか。

いくつかのMTAチェーンは他のMTAチェーンよりも「厳格」であるため、複数の大手プロバイダーのメールを比較することで、私はより迅速にパターンを認識することができます。私は発見したことを、正規化、ヘッダーリスト、プロセスの調整（送信前の空白の平滑化など）に取り入れています。.

キー・ローテーションとガバナンス

私はDKIMキーを体系的にローテーションし、古いキーが不必要に長い間DNSに存在することになり、リスクが高まる。私はローテーションの前に、すべてのサービスが新しいセレクタを使用しているかどうかをチェックし、両方のサービスが新しいセレクタを使用できるように移行フェーズを準備しています。 セレクター は有効です。切り替え後、すべての発信システムが新しいコンフィギュレーションを使うようになったら、すぐに古い公開鍵を削除する。私はこのルーチンを、カレンダーのリマインダー、文書化された責任、そして以下のテストプランとリンクさせている。再発. .実装には DKIMキーのローテーション, これは、明確な手順と適切な間隔を記述したものである。これによって暗号の連鎖がクリーンに保たれ管理は明確だ。.

簡単にまとめると

私がrelaxed/relaxedに頼っているのは、それが小さなフォーマットの変更を和らげ、最小化するからである。署名より多くの場合、その宛先に有効に到着する。署名されたヘッダーを巧みに選択することで、そのヘッダーを危険にさらすことなく操作を防ぐことができる。 一貫性 サービスの質を不必要に危険にさらす。実際のメールボックスを使った徹底的なテストによって、ゲートウェイがどこで状況を変え、どう調整する必要があるかがわかります。DKIMが確実にテスト可能であり続け、SPFが転送中にぐらつくようであれば、DMARCは大きな恩恵を受ける。 アライメント. .キーのローテーション、明確な文書化、監視のための組織化されたプロセスにより、私は業務を安全かつセキュアに維持しています。 維持可能. .これらの点に留意すれば、スパムのリスクを減らし、ドメインのアイデンティティを保護し、配信率を顕著に向上させることができます。.