Un avis d'appel d'offres peut être authentique mais contenir une modification non autorisée des coordonnées bancaires après une compromission de compte. L'authentification permet d'évaluer l'identité du domaine. L’autorité en matière d’approvisionnement émane du processus approuvé et de personnes responsables. Concevez les deux contrôles pour qu’ils se renforcent mutuellement sans permettre à l’un de se substituer à l’autre.
Associer l'avis au dossier d'approvisionnement
Pour la publication d'appels d'offres, les avis de fournisseurs et les achats délégués, enregistrez le système d'enregistrement, l'identifiant de l'avis, l'expéditeur approuvé et le rôle contractuel responsable. La notification devrait aider un fournisseur à trouver le dossier d'approvisionnement faisant autorité par un canal connu. Évitez de traiter un lien dans un message inattendu comme une vérification indépendante du même message.
Enregistrez le locataire de l'application, du domaine, du domaine de l'enveloppe, DKIM domaine et sélecteur pour chaque itinéraire. Un portail de passation des marchés externalisé peut disposer d'une infrastructure d'envoi distincte de celle du courrier du personnel de l'autorité. Un pied de page de marque ou une adresse de réponse n'établit pas de chemin d'authentification aligné. Conservez la gestion des réponses dans la feuille de route, car une véritable notification peut diriger les réponses vers une autre boîte aux lettres opérationnelle.
Conserver les modifications consécutives derrière leur propre approbation
Classez les avis en fonction de ce qu'ils demandent au destinataire de faire. Une annonce d'appel d'offres, une modification de délai, une communication d'attribution et une demande de détails de paiement ont différentes conséquences opérationnelles. Ce guide recommande une vérification séparée des achats et des finances pour les changements sensibles de fournisseur ou de banque en utilisant les enregistrements de contact établis, et non un numéro de téléphone fourni dans l'e-mail litigieux.
DMARC n'inspecte pas les conditions d'une offre et ne détermine pas qui a approuvé une attribution. Une signature passagère n’établit pas non plus qu’un compte bancaire appartient au fournisseur prévu. Conserver l'autorité de modification, le dossier approuvé et le résultat de la vérification indépendante dans le système d'approvisionnement. Il s'agit de recommandations en matière de flux de travail et non d'une déclaration de la loi sur les marchés publics d'une juridiction.
Testez l’expéditeur délégué avant une date limite
Exécutez des échantillons approuvés pour l’avis initial, la modification et l’annulation, avec des détails d’appel d’offres fictifs. Confirmer l'identité de l'expéditeur prévu, le résultat de la signature, applicable alignement, destination de réponse et accès réussi au dossier officiel. Un test de signature ne permet pas d'établir que l'avis est arrivé avant un délai légal. Conservez séparément les preuves de livraison et de publication pertinentes.
Si un entrepreneur change de plate-forme pendant un appel d'offres actif, conservez l'ancien itinéraire jusqu'à ce que le basculement approuvé et la gestion de la file d'attente soient compris. Définissez un propriétaire pour les notifications ayant échoué et un processus de notification alternatif documenté. Ne soumettez pas à nouveau silencieusement une notification via une nouvelle identité car une intégration a échoué. Un tel changement peut dérouter les fournisseurs et doit être traité dans le cadre du processus de communication approuvé par l'équipe d'approvisionnement.
Réévaluer la frontière avec les fournisseurs
Examinez les rapports par service d'approvisionnement, et pas seulement pour l'ensemble du volume de courrier du département. Un agrégat apparemment sain peut cacher un expéditeur d’amendements de faible volume. Faites remonter les domaines de signature inattendus, les nouvelles destinations de réponse et les comptes de fournisseurs sans propriétaire. Avant de retirer un domaine ou un sélecteur, déterminez quels dossiers d'appel d'offres et avis récurrents en dépendent encore. Les preuves d’authentification doivent accompagner, plutôt qu’à la place, les dossiers d’audit des achats.
Travailler sur trois enregistrements d'itinéraire écrits
Ces exemples de domaines réservés, de sélecteurs, de rôles et de prémisses DKIM de passage sont fictifs. Aucun message signé, clé, vérification cryptographique, recherche DNS , transaction SMTP ou test de service en direct n'est fourni ou exécuté dans ces cas. Aucun code de test ou spécimen externe n’est nécessaire pour inspecter le raisonnement ci-dessous.
- publication d'appel d'offres : visible depuis le domaine tenders.civic.example ; DKIM d=tenders.civic.example; démo du sélecteur1 ; supposez que DKIM passe uniquement pour ce cas écrit. SPF COURRIER DE identité et résultat inconnus ; autres signatures inconnues ; découverte et mise en œuvre réelles des politiques inconnues. Propriétaire proposé : Responsable des achats. Action suivante : obtenez un échantillon autorisé et un résultat de récepteur fiable pour ce locataire précis.
- avis fournisseur : visible Depuis le domaine suppliers.civic.example ; DKIM d=suppliers.civic.example; démo2 du sélecteur ; supposez que DKIM passe uniquement pour ce cas écrit. SPF MAIL FROM identité et résultat inconnus ; autres signatures inconnues ; découverte et mise en œuvre réelles des politiques inconnues. Propriétaire proposé : Propriétaire des communications avec les fournisseurs. Action suivante : confirmez cette route distincte et son événement commercial plutôt que d'hériter du résultat de la première route.
- passation des marchés délégués : visible depuis le domaine contracts.civic.example ; DKIM d=provider.example.net; démo du sélecteur3 ; supposez que DKIM passe uniquement pour ce cas écrit. SPF MAIL FROM identité et résultat inconnus ; autres signatures inconnues ; découverte et mise en œuvre réelles des politiques inconnues. Propriétaire proposé : Pouvoir adjudicateur. Action suivante : demandez au fournisseur vérifié le chemin de signature aligné pris en charge par ce locataire ; n’étende pas l’autorisation à l’ensemble de son réseau.
Pour les deux premières signatures stipulées, d= est exactement égal au domaine From, de sorte que l'identifiant satisfait à un alignement strict et assoupli. Compte tenu du résultat DKIM réussi stipulé, un chemin d’authentification aligné existe pour ces messages hypothétiques. Le troisième signataire n'a délibérément aucun rapport avec le domaine de l'auteur et ne peut pas fournir ce chemin aligné. N'appelez pas le troisième message un échec DMARC : SPF aligné ou autre passage aligné Signature DKIM pourrait encore satisfaire le mécanisme, et ces entrées sont inconnues. Ne déduisez pas un déploiement réel ou un placement dans la boîte de réception à partir d'une ligne.
Une signature cryptographique authentifie la responsabilité d'un domaine signataire, et non la véracité ou l'autorisation de chaque instruction. Les modifications apportées aux octets canonisés couverts peuvent invalider une signature ; toutes les modifications visibles ne modifient pas nécessairement l'entrée signée. L’authentification et l’acceptation au niveau de l’application restent distinctes.
Utilisez une carte d'acceptation spécifique à l'avis
Pour l'appel d'offres fictif T-01, modification version 2, exigez la version enregistrée approuvée, le rôle contractuel autorisé, l'identité de l'expéditeur, la destination de la réponse, l'heure de publication et la preuve de notification du destinataire. Si l'authentification réussit mais que le procès-verbal reste la version 1, arrêter et rapprocher la modification avec la passation des marchés ; ne l’étiquetez pas approuvé. Si l'enregistrement est correct mais que la notification échoue, invoquez le processus de notification alternatif déjà approuvé et conservez les preuves de timing. Un bénéficiaire modifié déclenche le processus de vérification financière distinct, quel que soit le résultat. Il s’agit de décisions proposées et non d’exigences du droit des marchés publics ou de tests réalisés.
Appliquer les normes sans prétendre être conformes
RFC 9989 sections 4.4 et 5.3.5 soutenir l’alignement et la distinction des mécanismes. Sa section 7.4 met en garde contre l'interopérabilité du courrier indirect : les domaines utilisant p=reject doit utiliser DKIM valide, pas SPF seul, et l'utilisation de listes de diffusion à usage général nécessite une attention particulière. Un inventaire d'itinéraires n'est pas en soi une autorisation d'imposer un rejet. RFC 6376 sections 3.4 à 3.7 et 6.1 décrire les entrées signées et la vérification. RFC 9990 section 3.1 fournit un contexte de reporting, et non une preuve d'arrivée par destinataire. RFC 5321 section 4.2.5 distingue la responsabilité d'acceptation du serveur des résultats de livraison ultérieurs. Les choix de flux de travail sectoriels sont ici des recommandations éditoriales ; la portée juridique, l’adéquation des facteurs et l’autorisation locale nécessitent leur propre examen responsable.