リストを 2 番目の送信ステップとして扱う
Simplelists メッセージには少なくとも 2 つの関連ステージがあります。メンバーが投稿を送信し、リストがそれを再配布します。元の提出物に対して機能した認証は、メンバーに配信されたコピーには記載されていない可能性があります。このガイドでは、文書化された複数リスト アカウントのカスタム ドメインと再配布されたメッセージの動作について説明します。すべてのアカウント タイプ、リスト設定、または元の送信者が同じ ID を使用することを前提としていません。
まずはビジネスの成果を選択します。発表リストは一貫して組織を表す場合があります。ディスカッション リストには、さまざまなメンバーを表示し、適切に返信する必要がある場合があります。送信者の書き換えを変更する前に人々がどのような動作を期待しているかを記録します。そうしないと、技術的に変更が成功すると、会話が混乱したり、隠すつもりだった匿名リストの詳細が公開されたりする可能性があります。
ドメインと受信ルーティング境界を確立する
Simplelists の独自ドメイン ガイド [全般設定]、[ドメイン] の順に複数リスト アカウントでドメインを追加し、それをプライマリとして設定し、結果のリスト アドレスを確認する方法について説明します。これはプロバイダーの 2017 年のセットアップ記事であるため、ナビゲーションを使用する前に現在のアカウント制御を確認してください。また、管理者にアカウントの場所を示します。 SPF そして DKIM 情報。公開されている例をコピーするのではなく、正しいアカウントとドメインから値を取得します。
同じガイドでは、プライマリとセカンダリの受信MXにそれぞれmx1.simplelists.comとmx2.simplelists.comという名前を付け、変更には最大 72 時間かかる可能性があると警告しています。経過時間を承認として扱うのではなく、現在のアカウントの指示と実際のキャッシュの状態を確認します。それを受信ルーティングの決定として扱います。組織がすでに従業員のメールをルート ドメインで受信している場合は、それらのメールを置き換えます MXレコード リスト以外にも影響を与える可能性があります。専用リストのサブドメインが適切かどうかを判断し、既存のメール所有者を特定し、公開前に承認されたルーティング スコープを記録します。
受信ルーティングと送信認証を別々のワークシート行に保持します。投稿がリストに正常に配信されたからといって、リストから送信されたコピーが認証されることは証明されません。逆に、 DKIM問題だけでは、会社の受信メールを移動することは正当化されません。
アカウント発行記録を取得して確認する
発行された各エントリの完全なレコード所有者、タイプ、公開値、および対象のドメインを取得します。提案された所有者を既存のDNSデータと比較して回避します。 セレクタ 衝突またはドメインサフィックスの重複。別のプロバイダーがDNSをホストしている場合は、レジストラー アカウントだけでなく、権限ゾーンの変更を確認します。
SPFの場合は、同じドメインの他の正当な送信者を保持します。 RFC 7208 複数の方法を定義します SPFレコード DNS に依存する用語が処理されます。追加サービスを承認する前に、完全なポリシーとネストされた検索コストを確認してください。セットアップ画面にはスタンドアロンの例が表示されるため、競合するSPFポリシーを作成しないでください。
DKIMの場合は、発行されたセレクターおよびパブリック レコードを、制御リスト メッセージで生成された署名と比較します。 RFC 6376 d= フィールドと s= フィールドを定義します。公開されたキーは、実際のメッセージに対応する有効な署名が含まれている場合にのみ役立ちます。元のメンバーの署名を含む、観察されたすべての署名を証拠パケットに保管します。
外部メンバー ID の処理方法を決定する
Simplelists のDMARC説明 アカウント ドメインからの送信と、別のドメインから発信されたメールの再配布を区別します。ドメイン外の条件付き書き換えについて説明します。その 機能ガイド また、一貫して書き換えるオプションと、元の送信者の詳細を表示するための制御についても説明します。
それらの選択肢は人間の判断に値します。委員会は安定したリストのアドレスを優先することができます。ディスカッション グループは、貢献者を表彰することを優先する場合があります。選択した From 表示と返信先を記録し、配信されたコピーで両方を確認します。匿名性が重要な場合は、本文と引用されたスレッドも確認してください。 1 つのヘッダーを非表示にしても、メンバーの署名ブロックや以前に引用されたアドレスを消去することはできません。
リストが無関係な外部メンバーのドメインとして署名できると想定しないでください。最終的に表示される From ドメインとそれをサポートする認証パスを特定します。複数の設定を一度に変更するのではなく、不一致を調査しながら、予想される会話の動作を維持します。
テスト計画にコンテンツの変更を含める
フッター、ヘッダーの挿入、または件名のプレフィックスは、署名内容に応じて、元の署名に影響を与える可能性があります。シンプルリスト」 配送トラブルシューティング ガイド では、スプーフィングの疑いのある拒否を調査する際のこれらの変更について説明します。また、 封筒の差出人 通常、これはリスト アドレスであり、受信者サーバーの詳細の電子メール配信ビューを指します。
組織の送信者、厳格なポリシーを持つ外部の送信者、および実際のリスト変更設定という小さなマトリックスを構築します。組織が使用しており、アカウントがそれらをサポートしている場合にのみ、ダイジェストまたはその他の個別の配信モードを追加します。各行は、理論上の機能チェックリストではなく、実際のワークフローを表す必要があります。
無害な投稿と管理された受信者を使用します。送信時刻とメッセージ識別子を保持して、リスト ログを受信したコピーと照合できるようにします。両方が関連する場合は、外部受信者と組織独自のゲートウェイをテストします。内部の受け入れは、外部メンバーが共有しないローカル例外に依存する場合があります。
最終的な正体と結果を記録する
配信されたコピーごとに、表示される From、Reply-To、エンベロープ ドメイン、すべてのDKIM d= および s= ペア、および信頼できる受信者のSPF 、 DKIMおよび DKIM を記録します。 DMARC 結果。元の投稿の結果は別に保存してください。 2 つのステージは異なる質問に回答するため、テスト記録内で相互に上書きしないでください。
RFC 9989 DMARCを定義します アライメント。受け渡しメカニズムとそれをサポートするドメイン関係を特定します。最終的な From ドメインに関係のないプロバイダー ドメイン パスでは、その関係は確立されません。 From アドレスが書き換えられると、関連する比較が変更される可能性があるため、最終コピーを検査することが重要です。
受信サーバーがメッセージを拒否した場合は、その正確な診断テキストを保存します。メッセージを受け入れても受信者がメッセージを見つけられない場合は、 DNS障害を想定せずに配信調査を続行します。認証結果を特定するための最初の代替手段として広範なホワイトリストを作成することは避けてください。
リスト再配布ワークシートを使用する
Simplelists のルートと送信者の動作ワークシート (ここで説明するフィールドを使用して別のレビュー レコードを作成します) には、受信リストのドメイン、元の投稿者のカテゴリ、書き換えの決定、コンテンツの変更、および最終的な ID が記録されます。これにより、ビジネス オーナーは返信動作を承認することができ、メール管理者は技術的な結果を添付することができます。
サインオフする前に、すべてのテスト行を比較します。組織の発表が 1 つ成功しただけでは、外部メンバーのディスカッション投稿が有効になるわけではありません。カバーされていないルートを明示的に保留のままにし、追加のテストが必要であることを示します。後の変更を追跡できるように、ドメイン構成とリスト設定のバージョンを結果とともに保持します。
ディスカッション フッターを含む架空の診断ケース
架空の書面によるケースのみ: SLS-01 では、オリジナルの From member@outside.exampleとオリジナルの合格署名d=outside.example.再配布されたコピーでは、フッターの変更後に元の署名が失敗します。最終的な From はmember@outside.exampleままです。リストの封筒、追加の署名、およびその結果は不明であるため、 DMARC完全な判定は下されません。リスト所有者は、最終コピーと文書化された書き換え設定を検査し、意図された返信動作を承認し、その正確なルートをテストする必要があります。組織のドメインにSPFを追加しても、無関係な元の署名は修復されません。実際のリストやメッセージは検査されませんでした。
メンバーのメールに影響を与えずに設定を復元
変更を制御する前に、以前のリスト設定とDNS状態を記録します。返信または送信者のプレゼンテーションが間違っている場合は、影響を受けるロールアウトを一時停止し、所有者がレビューしている間、承認された動作を復元します。レコードの廃棄を、残りのリストおよびキューに入れられたメッセージと調整します。共有ドメインは、異なる動作スケジュールを持つ複数のリストをサポートする場合があります。
ドメインの変更、変更の書き換え、新しいフッター、ルーティングの変更、または移行の後に再テストします。この未公開のドラフトでも、ライブアカウントの検査、発行された値、 DNS観察、受信メッセージの証拠、元のスコープの受け入れ、視覚的なレビュー、および SME による人間の承認が依然として必要です。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。