苦情レポートはワークフローへの入力であり、ワークフローが終了したことを証明するものではありません。実際の結果は、関連する送信システムが、決定を説明するために必要な証拠を保持しながら、望ましくない通信を停止することです。信頼、相関、範囲、適用を中心にパイプラインを設計します。
指示を抽出する前にレポートを検証する
RFC 5965人間が読める情報、機械が読めるフィールド、返されるメッセージ内容を含むマルチパート フィードバック レポートを定義しています。また、偽造やプライバシーのリスクにも対処します。明示的なサイズとネスト制限を使用してMIMEを解析します。返されたコンテンツを実行したり、コンテンツに埋め込まれたリンクをたどったりしないでください。 RFC 5965.
プロバイダーと受信システムに適切な出所を要求します。表示名が一致するだけでは十分ではありません。攻撃者が提供したヘッダーを額面通りに受け入れるのではなく、受信境界からの信頼できる認証結果を保持します。信頼できないレポートや不正なレポートは、対処可能な苦情とは別に、制限されたレビュー キューに保管します。
承認されたスコープを関連付けて選択する
送信側アプリケーションの保持されている識別子に対してレポートを解決します。出力では、文書化された信頼度に基づいて、サブスクライバー、ストリーム、および苦情イベントを識別する必要があります。レポートに安全な一意の一致がない場合は、未解決のままにしておきます。同じ件名のメッセージを受信したすべての人を抑制しないでください。
組織の承認された抑制ポリシーを適用します。プロモーションに関する苦情の場合は、その受信者をマーケティングから削除する必要がある場合がありますが、重要なアカウント セキュリティに関するコミュニケーションには、別個のサービスとポリシーの決定が必要です。この区別を、プロモーションをトランザクション メールとして再パッケージ化する許可として説明しないでください。受取人の表明された好みおよび責任ある事業主との適用される義務を尊重します。
永続化と強制を別個のチェックポイントにする
処理の成功を確認する前に、抑制決定を永続的に書き込みます。これを関連するすべての送信者に伝播し、スケジューリングまたはキューの準備が現在の抑制状態を参照していることを確認します。キャンペーン エンジンが決してチェックしないデータベース行は、効果的な抑制とはなりません。
安定したイベント キーを使用して、重複レポートを無害にします。最初の受信、決定時刻、ダウンストリームの確認応答、および再試行を記録します。ダウンストリーム サービスが利用できない場合は、再試行可能なタスクを保持し、ワークフローが完全に強制された成功を報告しないようにします。 1 つの API 呼び出しが成功したという理由だけで元のイベントを削除することは避けてください。
サポートされた決定を未解決のレポートから分離する
仮想のアリス/ニュース、アリス/セキュリティ、ボブ/ニュースのサブスクリプションを考えてみましょう。ソースが独立して検証され、保持されている送信識別子がアリス/ニュースに一意にマッピングされている苦情は、組織の承認された範囲内の決定をサポートします。この意図的に狭い教育方針の下では、他の 2 つのレコードは変更されない一方で、Alice/News は抑制されます。このポリシー例は、すべての苦情について法的に決定されるものではありません。
信頼できないレポートまたは 2 つの妥当なサブスクライバーを持つ送信識別子は、推測をサポートしません。制限付きレビューのままにして、不足している出所や相関関係の証拠を要求してください。繰り返し検証されたイベントは、無関係な 2 番目のアクションを作成することなく、同じ意図した抑制を保持する必要があります。この例では、レポートは処理されず、サブスクリプションも変更されませんでした。
完全な障害パスをテストする
本番環境を有効にする前に、重複配信、パーサーの障害、期限切れの相関レコード、およびダウンストリームの停止を実行してください。サポート スタッフが不要なメッセージ コンテンツを表示せずに保留中の適用を確認できることを確認します。不要なメールの再送信を避けるために必要な最小限の抑制レコードとは別に、未加工レポートの保存期間を定義します。
再サブスクリプションを慎重に検討してください。古い「登録済み」値が含まれているという理由だけで、後のインポートで苦情抑制を消去してはなりません。その人が新しく有効なサブスクリプションを選択した場合は、その移行に関する証拠と承認されたプロセスを保存してください。検証された苦情、サポートされている ID、承認された範囲と確認された施行、または明示的に保留中のギャップなど、測定可能な結果で終了します。
ダウンストリームの停止を可視化する
抑制の決定は永続的に保存されますが、キャンペーン サービスは利用できないとします。その特定の送信者に対して強制保留のマークを付け、再試行可能なタスクを保持します。苦情を再度受信すると、別の送信ボックス項目を作成したり、保留中の決定を消去したりするのではなく、既存のイベントを見つける必要があります。後の確認応答は、意図された受信者、範囲、および送信者に対応している必要があります。
API 確認と、次の視聴者選択パスが実際に変更を尊重するかどうかの検証を区別してください。古いエクスポートがそれを回避できる場合、抑制は完全には適用されません。これらは提案された状態および証拠の要件であり、実行された永続性または停止の実験ではありません。認可された実装テストでは、決定時間、ダウンストリーム試行、および制御された次回送信除外を保持します。
残りの執行作業を割り当てる
保留中の施行を伴う永続的な決定を行うには、特定のイベントとダウンストリーム ターゲット、次回の再試行、および所有者を保持します。決定を失ったり、重複した副作用を発生させたりすることなく、失敗したルートを復元します。意図した送信パスがそれを遵守する場合にのみ、完了を報告します。