「許可リストに登録してください」という言葉は簡単に聞こえますが、この用語は非常に異なるコントロールを表すことができます。個人のアドレス帳エントリ、組織のフィルタリング例外、およびプロバイダーの内部決定は互換性がありません。まず、システムと、それを実際に変更できる管理者の名前を指定します。
境界線を確立する
通常、例外は、例外が設定されているシステム内部にのみ適用されます。すべての受信プロバイダーに送信者を信頼するように指示するものではありません。 Googleは、 Gmail電子メールプロバイダーからの許可リストリクエストを受け入れないと明確に述べている。したがって、送信者は、ユニバーサルGmail許可リストを販売したり、約束したりしてはなりません。 Google 送信者のガイドライン.
例外をサポートしている受信組織については、現在の製品ドキュメントとポリシーを参照してください。提案されたルールによってスパム処理、認証処理、またはその他の制御が変更されるかどうかを判断します。 「信頼できる送信者」というフレンドリ名から正確なバイパス動作を推測しないでください。
一致する ID を定義する
目に見える From アドレスは、なりすましの可能性があるクレームです。それ自体では、承認されたメッセージであることの十分な証拠とはなりません。どの認証済みの ID、ルート、またはその他のサポートされている条件を受信コントロールが安全に評価できるかを判断します。無関係なテナントやサービスを含む広範なパターンは避けてください。
共有アウトバウンド IP には特に注意が必要です。 IP ベースの例外は、対象となる組織を超えて適用される場合があります。誰かがルールを承認する前に、その暴露を記録します。このガイドでは、最小範囲の例外を推奨しますが、汎用的な製品構文を規定するものではありません。
有効期限の前後および期限境界でのテスト
指定された日付の 20:00 UTC より前に厳密に有効である、ルート R 上のテナント A に対して提案された仮想の例外を考えてみましょう。レビュー計画には 4 つのケースが含まれています。19:00 の意図した認証済みテナントとルート、別のテナント、予期しないルート、および期限切れ時の意図したケースです。その宣言されたルールでは、最初のルールのみが一致することが期待されます。他の 3 つは通常の処理を受ける必要があります。
これらはテストの期待値であり、実際のフィルターの結果ではありません。製品が、タイムゾーンや正確な境界動作を含む、サポートされている認証済み ID と有効期限条件を表現できることを確認します。それができない場合は、チケットにそのように記載されているという理由だけで、提案されたルールに範囲が狭いというラベルを付けないでください。受信側所有者の承認プロセスを通じて、サポートされている代替案を選択します。
例外の一致はローカル ルールの決定であり、リモートの受け入れ、受信箱の配置、または安全なコンテンツの証明ではありません。認可された実装には、実際の陽性および陰性のテスト証拠が必要です。 記録 そのうちの保護はアクティブなままです。
例外を管理変更として使用する
ビジネス上の理由、所有者、一致する条件、影響を受けるコントロール、テスト計画、レビュー日を記録します。受信側システムの所有者から許可を取得します。ロールバック パスを保持し、意図したメッセージと一致しないはずの否定的なケースの両方を確認します。
例外は、壊れた送信者や虐待的な視聴者を修正する代わりにすべきではありません。送信者の認証を維持し、元の分類の問題を調査します。一時的な例外が正当化される場合は、文書化されていない永続的なバイパスを残すのではなく、期限切れにしてください。
観察された範囲と残留リスクを確認して終了します。 1 つのテナント内でのテストの成功は、より広範な受信トレイ配信の証拠にはなりません。バイパスは、一致するすべてのメッセージが安全であることを証明するものであると決して説明してはなりません。
送信者がプロバイダーまたは署名 ID を変更した場合の例外を再確認します。以前の狭いルールにより、正規のトラフィックの照合が停止されたり、古い共有アドレスが後で無関係の送信者にサービスを提供したりする可能性があります。元のチケットが再検出されると想定するのではなく、そのレビューを所有者に割り当てます。
防御可能な次のステップを記録する
例外は、グローバルな評判の修復ではなく、限定された受信システムの変更です。陰性の場合と有効期限を確認します。所有者の名前、証拠がまだ不足していること、および調査を終了する条件を明らかにしてください。サポートされていない結果は不明なままにしておきます。