Un citoyen peut recevoir du courrier d'un service central, d'un portail d'agence et d'un service de rappel contracté lors d'une seule demande. Une migration réussie de boîtes aux lettres ne prouve pas grand-chose sur ces deux derniers. Cartographiez le parcours du service avant de modifier la politique d'authentification, avec la propriété au point où le citoyen dépend du message.
Suivre le service plutôt que l'organigramme
Choisissez un parcours de service public, comme demander un permis. Énumérez le reçu de soumission, les demandes de renseignements supplémentaires, les avis de rendez-vous et la notification de décision finale. Enregistrez l'application qui déclenche chaque message, le fournisseur de services, son locataire, l'adresse d'expéditeur visible, expéditeur d'enveloppe, DKIM domaine et sélecteur, et le propriétaire d'entreprise responsable. Un carnet d'adresses départemental ne révèle pas tous ces systèmes.
Contrôle d'enregistrement de domaine séparé, contrôle DNS délégué et administration des applications. Une agence peut être propriétaire de son application tandis que le ministère parent publie ses dossiers ; un entrepreneur peut configurer la signature alors qu'aucun des deux ne peut approuver les modifications de l'autre. Nommez à la fois le propriétaire du service qui accepte l'impact de l'utilisateur et le propriétaire technique qui peut exécuter une modification. Ne considérez pas un nom d’affichage familier ressemblant à un gouvernement comme une preuve de l’une ou l’autre autorité.
Établir la limite du domaine délégué
Pour chaque domaine d'agence déléguée, inspectez son DNS réel et les DMARC plutôt que de supposer que le paramètre de domaine central le couvre comme prévu. Enregistrez s'il envoie, reçoit ou existe uniquement en tant qu'adresse Web. Documentez la portée de l'envoi autorisé de l'entrepreneur et sa date de fin. La configuration DKIM personnalisée et l'identité de l'enveloppe doivent être vérifiées par rapport au locataire particulier, et non copiées à partir de la configuration d'une autre agence.
La feuille de route ci-dessous inclut délibérément un entrepreneur supposé avoir une signature de passage sous le domaine du fournisseur, mais ne correspond pas exactement au domaine de l'agence. La tâche corrective consiste à examiner le chemin aligné approuvé, et non à autoriser chaque adresse appartenant à ce fournisseur. Obtenez de nouvelles valeurs du service vérifié, organisez le changement restreint et testez l’itinéraire réel avant une application plus large.
Protéger la continuité de service lors d’un changement
Planifiez des tests autour de flux peu fréquents mais conséquents, notamment un rejet de candidature ou une demande de documents manquants. Une newsletter mensuelle en masse n’est pas un substitut adéquat. Convenez avec les opérations du service de la manière dont un test échoué est signalé, de la manière dont les citoyens peuvent vérifier de manière indépendante l'état de leur demande et qui peut arrêter le déploiement. N'envoyez pas de vrais dossiers de citoyens aux destinataires des tests.
Utilisez un enregistrement de modification daté avec des preuves préalables, l'identité attendue, l'approbateur, l'opérateur et l'action d'annulation. Supprimez l’accès des entrepreneurs et leur pouvoir de signature grâce à un plan de départ coordonné après avoir confirmé que les messages en file d’attente et récurrents ont été déplacés. Examinez la feuille de route chaque fois qu'une agence se voit déléguer un nouveau contrôle DNS , qu'un portail change de fournisseur ou qu'une migration de boîte aux lettres centrale commence. Tout mandat gouvernemental ou obligation de conservation nécessite une vérification juridique spécifique à la juridiction ; ce guide ne fait aucune prétention réglementaire universelle.
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.
- portail citoyen : visible depuis le domaine portal.civic.example ; DKIM d=portal.civic.example; démo du sélecteur1 ; 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 de services numériques. Action suivante : obtenez un échantillon autorisé et un résultat de récepteur fiable pour ce locataire précis.
- agence déléguée : visible Depuis le domaine agency.civic.example ; DKIM d=agency.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 de l'agence. 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.
- rappels des entrepreneurs : visibles à partir du domaine notices.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é : Gestionnaire de contrat. 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, donc l'identifiant satisfait aux exigences strictes et assouplies. alignement. 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.
Attribuer une décision de libération concrète
Pour le parcours de permis fictif P-01, le propriétaire des services numériques accepte la couverture des reçus, le propriétaire de l'agence accepte la couverture des avis de décision et le gestionnaire de contrat obtient la configuration du locataire de rappel. L'opérateur DNS implémente uniquement une différence exacte approuvée ; l'accès aux applications à lui seul n'autorise pas cette différence. Si l'entrepreneur ne peut pas démontrer un itinéraire aligné, laissez cet itinéraire non résolu et suspendez le changement de politique concerné plutôt que de déclarer l'ensemble du voyage prêt. Enregistrez un chemin alternatif de vérification de statut approuvé et son personnel avant de promettre la continuité. Aucun de ces propriétaires ou artefacts n’est vérifié ici.
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.