Un portail peut accepter une candidature alors que sa réception échoue, ou envoyer des rappels avec succès pendant que les mises à jour de statut utilisent un relais oublié. Dans les deux cas, le citoyen subit un service interrompu. Traitez les reçus, les rappels et les notifications de statut comme trois itinéraires indépendants avant de vous appuyer sur une métrique d'authentification combinée.
Liez chaque notification à une transition d’état
Pour un reçu, identifiez l'événement d'application qui le crée et l'identifiant qui le relie à la soumission. Pour un rappel de rendez-vous, enregistrez le système de planification, le fuseau horaire et le comportement de reprogrammation. Pour une mise à jour du statut, identifiez la transition de gestion de cas et l'endroit faisant autorité où le citoyen peut la vérifier. Séparez l’heure de notification de l’heure de l’événement sous-jacent.
Mappez chaque événement à l'application d'envoi, au locataire du fournisseur, à partir du domaine, expéditeur d'enveloppe, DKIM domaine et sélecteur. Le domaine du portail Web et le certificat TLS n'indiquent pas quel système envoie le courrier électronique. Une intégration d'application peut sélectionner un fournisseur différent pour chaque famille de notifications, même lorsque tous les messages partagent la même conception visuelle.
Concevoir des tests autour des changements, et pas seulement du chemin heureux
Utilisez des applications fictives et des boîtes mail de test autorisées. Déclenchez une soumission, un rendez-vous modifié, un rendez-vous annulé et un changement de statut dans un environnement de test approuvé, le cas échéant. Inspectez les octets finaux du message et le résultat de l'authentification fiable du destinataire. Confirmez que les liens et les références affichées mènent au service officiel attendu, sans inclure les détails du cas réel des citoyens dans les journaux de test généraux.
Un rappel mis en file d'attente avant la reprogrammation peut être correctement signé et décrire néanmoins un rendez-vous obsolète. L'authentification de domaine ne résout pas ce défaut d'application. Suivez l'événement d'origine et la version de la notification afin que les opérations puissent distinguer le contenu obsolète d'un échec d'identité. De même, un reçu en double doit faire l'objet d'une enquête en tant que problème d'événement ou de nouvelle tentative au lieu d'être automatiquement classé comme usurpation d'identité.
Décidez qui arrête un voyage interrompu
Le propriétaire de l'application doit juger si le citoyen peut continuer en toute sécurité lorsque le courrier électronique n'est pas disponible. Le responsable de la planification doit gérer les écarts de rappel et les opérations de cas doivent gérer les notifications d'état. Définissez le chemin alternatif de vérification de l’état et le contact d’escalade approuvés avant de renforcer la politique. Ne promettez pas un canal alternatif à moins qu’il ne soit véritablement soutenu et doté en personnel.
Si un expéditeur n’est pas aligné, vérifiez la capacité réelle de domaine personnalisé du service et les enregistrements générés par le locataire. Modifiez uniquement le chemin d'identité approuvé, testez-le et conservez un plan de restauration daté. Évitez les larges SPF ajouts effectués uniquement parce qu’une adresse IP source semble familière. Un fournisseur peut authentifier son propre domaine sans parvenir à établir alignement avec le domaine From du service public.
Surveiller l’exhaustivité plutôt que simplement les pourcentages
Enregistrez quelles familles de notifications ont été observées, lesquelles ont été testées et lesquelles restent non vérifiées. Incluez des événements de cycle de vie peu fréquents et des variantes en langue locale lorsqu'ils utilisent des modèles ou des systèmes différents. Utiliser rapports agrégés pour identifier les modèles dans leur couverture réelle de reporting, puis enquêter sur les itinéraires manquants ou défaillants avec des preuves de service. Actualisez la carte après les mises à niveau du portail, les modifications du planificateur, le remplacement du fournisseur et les modifications apportées au domaine From. Aucun délai de notification légal spécifique n’est ici affirmé.
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.
- reçu : visible à partir du domaine receipts.civic.example ; DKIM d=receipts.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 du service d’application. Action suivante : obtenez un échantillon autorisé et un résultat de récepteur fiable pour ce locataire précis.
- rappel de rendez-vous : visible Depuis le domaine appointments.civic.example ; DKIM d=appointments.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 de la planification. 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.
- avis d'état : visible Depuis le domaine status.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é : Propriétaire de la gestion de cas. 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 DMARC échec : 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.
Résoudre un exemple de rappel obsolète
Supposons que la version 1 du rendez-vous du cas fictif C-01 était à 10h00 TPS et que la version 2 le déplace à 11h00 TPS le même jour. Un rappel de version 1 déjà en file d'attente est stipulé pour transmettre DKIM aligné. Son résultat d'identité ne fait pas 10h00 d'actualité. Le responsable de la planification doit appliquer la règle d'annulation ou de remplacement approuvée, vérifier le rendez-vous en cours sur le portail officiel et vérifier si une correction a effectivement été apportée. Si le message contient la version 2 mais aucune preuve d'authentification fiable, étudiez la route du courrier séparément. Aucun cas réel, message, travail de replanification ou envoi de correction n'a été utilisé 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.