入札通知は本物であっても、口座侵害後の不正な銀行詳細変更が含まれている場合があります。認証はドメイン ID の評価に役立ちます。調達権限は、承認されたプロセスと責任ある人材から生まれます。 2 つのチェックを、一方が他方を置き換えることなく相互に強化できるように設計します。
通知を調達記録にマッピングする
入札公告、サプライヤー通知、および委託された調達については、記録システム、通知識別子、承認された送信者、責任ある契約役割を記録します。この通知は、サプライヤーが既知のチャネルを通じて信頼できる調達記録を見つけるのに役立ちます。予期しないメッセージ内のリンクを、同じメッセージの独立した検証として扱うことは避けてください。
アプリケーションのテナント、From ドメイン、エンベロープ ドメインを記録します。 DKIM ドメインと セレクタ ルートごとに。外部委託された調達ポータルには、当局のスタッフのメールとは別の送信インフラストラクチャが存在する場合があります。ブランドのフッターまたは返信先アドレスでは、調整された認証パスが確立されません。本物の通知は返信を別の動作中のメールボックスに送信できるため、ルート マップでの返信処理を維持します。
重大な変更は自分自身の承認の背後に置く
通知を受信者に求める内容ごとに分類します。入札公開の発表、締め切りの修正、落札の連絡、支払い詳細の要求は、運用上のさまざまな影響を及ぼします。このガイドでは、問題の電子メールに記載されている電話番号ではなく、確立された連絡先記録を使用して、機密性の高いサプライヤーまたは銀行の変更について、調達と財務を個別に検証することを推奨しています。
DMARC 入札条件を検査したり、誰が落札を承認したかを決定したりすることはありません。また、署名を渡すことによって、銀行口座が対象のサプライヤーのものであることが証明されるわけでもありません。変更権限、承認された記録、および独立した検証結果を調達システムに保持します。これらはワークフローの推奨事項であり、管轄区域の調達法の声明ではありません。
期限前に代理送信者をテストする
架空の入札詳細を使用して、最初の通知、修正、キャンセルの承認済みサンプルを実行します。意図した From ID、署名結果、該当することを確認します アライメント、返信先と公式記録へのアクセスに成功しました。署名テストでは、通知が法的期限より前に到着したことを証明することはできません。関連する納品および出版の証拠を個別に保存してください。
アクティブな入札中に請負業者がプラットフォームを変更する場合は、承認されたカットオーバーとキューの処理が理解されるまで古いルートを保持します。失敗した通知の所有者を設定し、代替通知プロセスを文書化します。統合が失敗したため、新しい ID を使用して通知をサイレントに再送信しないでください。このような変更はサプライヤーを混乱させる可能性があるため、調達チームの承認されたコミュニケーションプロセスに基づいて処理する必要があります。
サプライヤー側の境界線を再評価する
部門の総メール量だけでなく、調達サービスごとにレポートを確認します。一見健全な集合体には、少量の修正送信者が隠れている可能性があります。予期しない署名ドメイン、新しい返信先、および所有されていないベンダー アカウントをエスカレーションします。ドメインまたはセレクターを廃止する前に、どの入札記録と定期通知が依然として依存しているかを確認してください。認証証拠は、調達監査記録の代わりではなく、並行して存在します。
3 つの書面によるルート記録に取り組む
これらの予約済みのサンプル ドメイン、セレクター、ロール、および受け渡すDKIM前提は架空のものです。これらの場合、署名されたメッセージ、キー、暗号検証、 DNSルックアップ、 SMTPトランザクション、またはライブ サービス テストは提供されず、実行されません。以下の推論を検証するために、テスト コードや外部サンプルは必要ありません。
- 入札出版物: ドメインtenders.civic.exampleから表示可能; DKIM d=tenders.civic.example;セレクターデモ1;この書面による場合のみDKIMパスを想定してください。 SPF メール送信元 正体も結果も不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: 調達責任者。次のアクション: このテナントの承認されたサンプルと信頼できる受信者の結果を取得します。
- サプライヤー通知: ドメインsuppliers.civic.exampleから表示可能。 DKIM d=suppliers.civic.example;セレクターデモ2;この書面による場合のみDKIMパスを想定してください。 SPF MAIL FROM の身元と結果は不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: サプライヤー コミュニケーションの所有者。次のアクション: 最初のルートの結果を継承するのではなく、この別のルートとそのビジネス イベントを確認します。
- 委任された調達: ドメインcontracts.civic.exampleから表示可能。 DKIM d=provider.example.net;セレクターデモ3;この書面による場合のみDKIMパスを想定してください。 SPF MAIL FROM の身元と結果は不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: 契約当局。次のアクション: 検証済みのサプライヤーに、このテナントでサポートされている調整された署名パスを問い合わせます。許可をネットワーク全体に拡大しないでください。
最初の 2 つの規定された署名では、d= は From ドメインと正確に等しいため、識別子は厳格なアライメントと緩和されたアライメントを満たします。 DKIM結果が成功したと規定されている場合、それらの仮想メッセージに対して調整された認証パスが存在します。 3 番目の署名者は作成者ドメインとは意図的に無関係であるため、その調整されたパスを提供できません。 3 番目のメッセージをDMARC失敗とは呼ばないでください: アライメントされたSPFまたは別のアライメントされたパッシング DKIM署名 まだメカニズムを満たす可能性がありますが、それらの入力は不明です。どの行からも実際の展開や受信トレイの配置を推測しないでください。
暗号署名は、署名ドメインの責任を認証するものであり、すべての命令の真実性や承認を認証するものではありません。対象となる正規化されたバイトを変更すると、署名が無効になる可能性があります。目に見えるすべての編集が必ずしも署名付き入力を変更するわけではありません。認証とアプリケーションレベルの受け入れは分離されたままになります。
通知専用の受付カードを使用する
架空入札 T-01 修正バージョン 2 の場合、承認された記録バージョン、承認された契約役割、送信元 ID、返信先、公開時刻、および受信者通知の証拠が必要です。認証は合格したが、公式記録がバージョン 1 のままの場合は、修正を中止し、調達と調整します。承認済みというラベルを付けないでください。記録は正しいが通知が失敗した場合は、すでに承認されている代替通知プロセスを呼び出し、タイミング証拠を保持します。受取人が変更されると、どちらの結果に関係なく、別の財務検証プロセスがトリガーされます。これらは提案された決定であり、調達法の要件や完了したテストではありません。
準拠を主張せずに標準を適用する
RFC 9989セクション 4.4 および 5.3.5 アライメントと機構の区別をサポートします。そのセクション 7.4 では、間接メールの相互運用性について警告しています: を使用するドメイン p=reject SPFだけではなく有効なDKIM使用する必要があり、汎用メーリング リストの使用には特に注意が必要です。ルート インベントリ自体は拒否を強制する許可ではありません。 RFC 6376セクション 3.4 ～ 3.7 および 6.1 署名された入力と検証について説明します。 RFC 9990セクション 3.1 受信者ごとの到着証明ではなく、レポートのコンテキストを提供します。 RFC 5321セクション 4.2.5 サーバーの受け入れ責任とその後の配信結果を区別します。ここでの部門ワークフローの選択は編集者の推奨事項です。法的範囲、要素の適合性、および現地の認可は、独自の責任あるレビューが必要です。