En portal kan acceptere en ansøgning, mens dens modtagelse mislykkes, eller sende påmindelser med succes, mens statusopdateringer bruger et glemt relæ. Borgeren oplever i begge tilfælde en ødelagt service. Behandl kvitteringer, påmindelser og statusmeddelelser som tre uafhængigt ejede ruter, før du stoler på en kombineret godkendelsesmetrik.
Knyt hver notifikation til en tilstandsovergang
For en kvittering skal du identificere den applikationsbegivenhed, der opretter den, og den identifikator, der forbinder den med indsendelsen. For en påmindelse om en aftale skal du registrere planlægningssystemet, tidszonen og omlægningsadfærden. For en statusopdatering skal du identificere sagsbehandlingsovergangen og det autoritative sted, hvor borgeren kan verificere den. Hold notifikationstiden adskilt fra den underliggende begivenhedstid.
Tilknyt hver begivenhed til den afsendende applikation, leverandørlejer, Fra domæne, konvolutafsender, DKIM domæne og vælger. Webportalens domæne og TLS certifikat viser ikke, hvilket system der sender e-mail. En applikationsintegration kan vælge en anden udbyder for hver meddelelsesfamilie, selv når alle meddelelser deler det samme visuelle design.
Designtest omkring ændringer, ikke kun den lykkelige vej
Brug fiktive applikationer og autoriserede testpostkasser. Udløs en indsendelse, ændret aftale, aflyst aftale og statusændring i et godkendt testmiljø, hvor det er muligt. Undersøg de endelige meddelelsesbytes og modtagerens troværdige godkendelsesresultat. Bekræft, at links og viste referencer fører til den forventede officielle service, uden at inkludere reelle borgersagsdetaljer i generelle testlogfiler.
En påmindelse i kø før omlægning kan underskrives korrekt og stadig beskrive en forældet aftale. Domænegodkendelse løser ikke denne applikationsfejl. Spor notifikationens oprindelige hændelse og version, så operationer kan skelne gammelt indhold fra en identitetsfejl. På samme måde bør en dublet kvittering undersøges som en hændelse eller et forsøg igen i stedet for automatisk at blive klassificeret som spoofing.
Beslut hvem der stopper en ødelagt rejse
Ansøgningsejeren bør vurdere, om borgeren kan fortsætte sikkert, når e-mail ikke er tilgængelig. Planlægningsejeren skal håndtere påmindelsesafvigelser, og sagsbehandlingen skal håndtere statusmeddelelser. Definer den godkendte alternative statuskontrolsti og eskaleringskontakt før stramning af politik. Lov ikke en alternativ kanal, medmindre den er reelt understøttet og bemandet.
Hvis en afsender ikke er justeret, skal du kontrollere tjenestens faktiske tilpassede domænekapacitet og lejergenererede registreringer. Skift kun den godkendte identitetssti, test den, og behold en dateret tilbagerulningsplan. Undgå bred SPF tilføjelser lavet udelukkende fordi en kilde-IP ser bekendt ud. En udbyder kan godkende sit eget domæne uden at etablere justering med public service's From-domæne.
Overvåg fuldstændigheden i stedet for blot procenter
Registrer hvilke underretningsfamilier der blev observeret, hvilke blev testet, og hvilke forbliver ubekræftede. Inkluder sjældne livscyklushændelser og lokale sprogvarianter, når de bruger forskellige skabeloner eller systemer. Bruge samlede rapporter at identificere mønstre inden for deres faktiske rapporteringsdækning, og derefter undersøge manglende eller svigtende ruter med servicebeviser. Opdater kortet efter portalopgraderinger, planlægningsændringer, leverandørudskiftning og ændringer af Fra-domænet. Der er ikke fastsat nogen specifik lovbestemt anmeldelsesfrist her.
Gennemfør tre skriftlige ruteoptegnelser
Disse reserverede eksempeldomæner, vælgere, roller og forbipasserende DKIM lokaler er fiktive. Ingen signeret besked, nøgle, kryptografisk verifikation, DNS opslag, SMTP transaktion eller live-servicetest leveres eller udføres for disse tilfælde. Ingen testkode eller ekstern prøve er nødvendig for at inspicere begrundelsen nedenfor.
- kvittering: synlig fra domæne receipts.civic.example ; DKIM d=receipts.civic.example; vælgerdemo1; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Applikationstjenesteejer. Næste handling: Få en autoriseret prøve og et betroet modtagerresultat for netop denne lejer.
- påmindelse om aftale: synlig fra domænet appointments.civic.example ; DKIM d=appointments.civic.example; vælgerdemo2; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Skemaejer. Næste handling: Bekræft denne separate rute og dens forretningsbegivenhed i stedet for at arve den første rutes resultat.
- statusmeddelelse: synlig fra domænet status.civic.example ; DKIM d=provider.example.net; vælgerdemo3; antage DKIM bestå alene for denne skriftlige sag. SPF MAIL FRA identitet og resultat ukendt; andre signaturer ukendte; faktisk politik opdagelse og levering ukendt. Foreslået ejer: Sagsbehandlerejer. Næste handling: Spørg den bekræftede leverandør om denne lejers understøttede tilpassede signeringssti; ikke udvide autorisation til hele dets netværk.
For de første to angivne signaturer er d= nøjagtigt lig med From-domænet, så identifikatoren opfylder både streng og afslappet justering. I betragtning af det angivne succesfulde DKIM resultat findes der en tilpasset godkendelsessti for disse hypotetiske meddelelser. Den tredje underskriver er bevidst ikke relateret til forfatterdomænet og kan ikke levere den tilpassede sti. Ring ikke til den tredje besked a DMARC fejl: justeret SPF eller en anden justeret pasning DKIM signatur kunne stadig opfylde mekanismen, og disse input er ukendte. Udled ikke reel implementering eller indbakkeplacering fra nogen række.
En kryptografisk signatur autentificerer et signeringsdomænes ansvar, ikke sandheden eller godkendelsen af enhver instruktion. Ændringer af dækkede kanoniserede bytes kan ugyldiggøre en signatur; ikke enhver synlig redigering ændrer nødvendigvis det signerede input. Godkendelse og accept på applikationsniveau forbliver adskilt.
Løs et eksempel på en gammel påmindelse
Antag, at den fiktive sag C-01 aftale version 1 var 10:00 GST og version 2 flytter den til 11:00 GST samme dag. En allerede i kø version-1 påmindelse er fastsat til at passere justeret DKIM . Dets identitetsresultat gør ikke 10:00 aktuelt. Planlægningsejeren bør anvende den godkendte annullerings- eller erstatningsregel, verificere den aktuelle aftale i den officielle portal og kontrollere, om en rettelse rent faktisk blev leveret. Hvis meddelelsen i stedet indeholder version 2, men ingen pålidelige godkendelsesbeviser, skal du undersøge postruten separat. Ingen reel sag, besked, omlægningsjob eller rettelsessending blev brugt her.
Anvend standarderne uden at kræve overholdelse
RFC 9989 afsnit 4.4 og 5.3.5 understøtte justeringen og mekanismens skelnen. Dens afsnit 7.4 advarer om interoperabilitet mellem indirekte mails: domæner, der bruger p=reject skal bruge gyldig DKIM , ikke SPF alene, og brug af mailinglister til generelle formål kræver særlig omhu. En ruteopgørelse er ikke i sig selv tilladelse til at håndhæve afvisning. RFC 6376 afsnit 3.4–3.7 og 6.1 beskrive signerede input og verifikation. RFC 9990 Afsnit 3.1 giver rapporteringskontekst, ikke bevis for ankomst pr. modtager. RFC 5321 Afsnit 4.2.5 adskiller serveracceptansvar fra senere leveringsresultater. Valg af sektorarbejdsgange her er redaktionelle anbefalinger; juridisk omfang, faktor egnethed og lokal autorisation har brug for deres egen ansvarlige gennemgang.