Ein Portal kann eine Bewerbung annehmen, während der Empfang fehlschlägt, oder Erinnerungen erfolgreich senden, während Statusaktualisierungen ein vergessenes Relay verwenden. In beiden Fällen erfährt der Bürger einen Dienstausfall. Behandeln Sie Belege, Erinnerungen und Statusbenachrichtigungen als drei unabhängige Routen, bevor Sie sich auf eine kombinierte Authentifizierungsmetrik verlassen.
Verknüpfen Sie jede Benachrichtigung mit einem Zustandsübergang
Identifizieren Sie für eine Quittung das Anwendungsereignis, das sie erstellt, und die Kennung, die sie mit der Übermittlung verbindet. Notieren Sie für eine Terminerinnerung das Planungssystem, die Zeitzone und das Umplanungsverhalten. Identifizieren Sie für eine Statusaktualisierung den Fallverwaltungsübergang und den maßgeblichen Ort, an dem der Bürger dies überprüfen kann. Halten Sie die Benachrichtigungszeit getrennt von der zugrunde liegenden Ereigniszeit.
Ordnen Sie jedes Ereignis der sendenden Anwendung, dem Anbieter-Mandanten, der Von-Domäne usw. zu. Umschlagabsender, DKIM Domäne und Wähler. Die Domäne und TLS -Zertifikat des Webportals zeigen nicht an, welches System E-Mails sendet. Eine Anwendungsintegration kann für jede Benachrichtigungsfamilie einen anderen Anbieter auswählen, selbst wenn alle Nachrichten das gleiche visuelle Design haben.
Designtests rund um Veränderungen, nicht nur den glücklichen Weg
Nutzen Sie fiktive Anwendungen und autorisierte Testpostfächer. Lösen Sie eine Übermittlung, einen geänderten Termin, einen abgesagten Termin und eine Statusänderung in einer genehmigten Testumgebung aus, sofern verfügbar. Überprüfen Sie die endgültigen Nachrichtenbytes und das vertrauenswürdige Authentifizierungsergebnis des Empfängers. Bestätigen Sie, dass Links und angezeigte Referenzen zum erwarteten offiziellen Dienst führen, ohne dass in den allgemeinen Testprotokollen echte Falldetails von Bürgern enthalten sind.
Eine Erinnerung, die vor einer Neuterminierung in der Warteschlange steht, kann korrekt unterschrieben sein und dennoch einen veralteten Termin beschreiben. Die Domänenauthentifizierung behebt diesen Anwendungsfehler nicht. Verfolgen Sie das Ursprungsereignis und die Version der Benachrichtigung, damit Vorgänge veraltete Inhalte von einem Identitätsfehler unterscheiden können. Ebenso sollte ein doppelter Beleg als Ereignis oder Wiederholungsproblem untersucht werden, anstatt automatisch als klassifiziert zu werden Spoofing.
Entscheiden Sie, wer eine kaputte Reise stoppt
Der Eigentümer der Anwendung sollte beurteilen, ob der Bürger sicher fortfahren kann, wenn E-Mails nicht verfügbar sind. Der Planungseigentümer sollte sich um Unstimmigkeiten bei Erinnerungen kümmern, und Fallbearbeiter sollten sich um Statusmitteilungen kümmern. Definieren Sie den genehmigten alternativen Pfad zur Statusprüfung und den Eskalationskontakt, bevor Sie die Richtlinien verschärfen. Versprechen Sie keinen alternativen Kanal, es sei denn, dieser wird wirklich unterstützt und verfügt über entsprechendes Personal.
Wenn ein Absender nicht ausgerichtet ist, überprüfen Sie die tatsächliche Fähigkeit des Dienstes zur benutzerdefinierten Domäne und die vom Mandanten generierten Datensätze. Ändern Sie nur den genehmigten Identitätspfad, testen Sie ihn und behalten Sie einen datierten Rollback-Plan bei. Vermeiden Sie breit SPF Ergänzungen, die ausschließlich vorgenommen wurden, weil eine Quell-IP bekannt vorkommt. Ein Anbieter kann seine eigene Domäne authentifizieren, obwohl die Einrichtung fehlschlägt Ausrichtung mit der From-Domäne des öffentlichen Dienstes.
Überwachen Sie die Vollständigkeit und nicht nur die Prozentsätze
Notieren Sie, welche Benachrichtigungsfamilien beobachtet wurden, welche getestet wurden und welche noch nicht überprüft wurden. Beziehen Sie seltene Lebenszyklusereignisse und lokale Sprachvarianten ein, wenn sie unterschiedliche Vorlagen oder Systeme verwenden. Verwenden aggregierte Berichte um Muster innerhalb ihrer tatsächlichen Berichtsabdeckung zu identifizieren und anschließend fehlende oder fehlerhafte Routen anhand von Servicenachweisen zu untersuchen. Aktualisieren Sie die Karte nach Portal-Upgrades, Zeitplanänderungen, Anbieterwechsel und Änderungen an der Von-Domäne. Eine konkrete gesetzliche Anzeigefrist wird hier nicht geltend gemacht.
Arbeiten Sie drei schriftliche Routenaufzeichnungen durch
Diese reservierten Beispieldomänen, Selektoren, Rollen und übergebenen DKIM Prämissen sind fiktiv. Für diese Fälle werden keine signierten Nachrichten, Schlüssel, kryptografischen Überprüfungen, DNS Suchen, SMTP Transaktionen oder Live-Service-Tests bereitgestellt oder ausgeführt. Für die Überprüfung der folgenden Argumentation ist kein Testcode oder externe Probe erforderlich.
- Quittung: sichtbar Von der Domain receipts.civic.example “; DKIM d=receipts.civic.example; Selektor Demo1; Wir gehen davon aus, dass DKIM ausschließlich für diesen schriftlichen Fall gilt. SPF MAIL FROM Identität und Ergebnis unbekannt; weitere Unterschriften unbekannt; Die tatsächliche Entdeckung und Bereitstellung der Richtlinien ist unbekannt. Vorgeschlagener Eigentümer: Eigentümer des Anwendungsdiensts. Nächste Aktion: Fordern Sie eine autorisierte Probe und ein vertrauenswürdiges Empfängerergebnis für genau diesen Mandanten an.
- Terminerinnerung: sichtbar Von der Domäne appointments.civic.example “; DKIM d=appointments.civic.example; Selektor Demo2; Wir gehen davon aus, dass DKIM ausschließlich für diesen schriftlichen Fall gilt. SPF MAIL FROM Identität und Ergebnis unbekannt; weitere Unterschriften unbekannt; Die tatsächliche Entdeckung und Bereitstellung der Richtlinien ist unbekannt. Vorgeschlagener Eigentümer: Planungseigentümer. Nächste Aktion: Bestätigen Sie diese separate Route und ihr Geschäftsereignis, anstatt das Ergebnis der ersten Route zu erben.
- Statushinweis: sichtbar Von der Domäne status.civic.example ; DKIM d=provider.example.net; Selektor Demo3; Wir gehen davon aus, dass DKIM ausschließlich für diesen schriftlichen Fall gilt. SPF MAIL FROM Identität und Ergebnis unbekannt; weitere Unterschriften unbekannt; Die tatsächliche Entdeckung und Bereitstellung der Richtlinien ist unbekannt. Vorgeschlagener Eigentümer: Fallmanagement-Inhaber. Nächste Aktion: Fragen Sie den verifizierten Lieferanten nach dem unterstützten ausgerichteten Signaturpfad dieses Mandanten. Erweitern Sie die Autorisierung nicht auf das gesamte Netzwerk.
Für die ersten beiden festgelegten Signaturen entspricht d= genau der From-Domäne, sodass der Bezeichner sowohl eine strikte als auch eine entspannte Ausrichtung erfüllt. Angesichts des festgelegten erfolgreichen DKIM Ergebnisses existiert ein abgestimmter Authentifizierungspfad für diese hypothetischen Nachrichten. Der dritte Unterzeichner hat bewusst keinen Bezug zur Autorendomäne und kann diesen ausgerichteten Pfad nicht bereitstellen. Nennen Sie die dritte Nachricht nicht a DMARC Fehler: ausgerichteter SPF oder ein anderer ausgerichteter Durchgang DKIM Signatur könnte den Mechanismus immer noch erfüllen, und diese Eingaben sind unbekannt. Schließen Sie aus keiner Zeile auf die tatsächliche Bereitstellung oder Posteingangsplatzierung ab.
Eine kryptografische Signatur authentifiziert die Verantwortung einer signierenden Domäne, nicht die Wahrheit oder Autorisierung jeder Anweisung. Änderungen an abgedeckten kanonisierten Bytes können eine Signatur ungültig machen; Nicht jede sichtbare Bearbeitung ändert zwangsläufig die signierte Eingabe. Authentifizierung und Akzeptanz auf Anwendungsebene bleiben getrennt.
Lösen Sie ein Beispiel für eine veraltete Erinnerung
Angenommen, im fiktiven Fall C-01 war der Termin Version 1 um 10:00 Uhr GST und Version 2 verschiebt ihn auf 11:00 Uhr GST am selben Tag. Eine bereits in der Warteschlange befindliche Version-1-Erinnerung ist erforderlich, um den abgestimmten DKIM zu bestehen. Sein Identitätsergebnis macht 10:00 nicht aktuell. Der Termininhaber sollte die genehmigte Stornierungs- oder Ersatzregelung anwenden, den aktuellen Termin im offiziellen Portal überprüfen und prüfen, ob tatsächlich eine Korrektur abgegeben wurde. Wenn die Nachricht stattdessen Version 2, aber keinen vertrauenswürdigen Authentifizierungsnachweis enthält, untersuchen Sie die E-Mail-Route separat. Hier wurde kein echter Fall, keine Nachricht, kein Umplanungsauftrag oder kein Korrekturversand verwendet.
Wenden Sie die Standards an, ohne Anspruch auf Einhaltung zu erheben
RFC 9989 Abschnitte 4.4 und 5.3.5 unterstützen die Ausrichtung und Mechanismusunterscheidung. In Abschnitt 7.4 wird vor der Interoperabilität indirekter E-Mails gewarnt: Domänen verwenden p=reject Es muss ein gültiges DKIM verwendet werden, nicht nur SPF , und die allgemeine Verwendung von Mailinglisten erfordert besondere Sorgfalt. Eine Routeninventarisierung selbst ist keine Erlaubnis, eine Ablehnung zu erzwingen. RFC 6376 Abschnitte 3.4–3.7 und 6.1 Beschreiben Sie signierte Eingaben und die Überprüfung. RFC 9990 Abschnitt 3.1 Bietet einen Berichtskontext und keinen Empfangsnachweis pro Empfänger. RFC 5321 Abschnitt 4.2.5 unterscheidet die Verantwortung für die Serverakzeptanz von späteren Lieferergebnissen. Bei den Auswahlmöglichkeiten für Branchen-Workflows handelt es sich hier um redaktionelle Empfehlungen. Der rechtliche Geltungsbereich, die Faktoreignung und die örtliche Zulassung bedürfen einer eigenen, verantwortungsvollen Prüfung.