En portal kan godta en applikasjon mens mottaket mislykkes, eller sende påminnelser vellykket mens statusoppdateringer bruker et glemt relé. Innbyggeren opplever en ødelagt tjeneste i begge tilfeller. Behandle kvitteringer, påminnelser og statusvarsler som tre uavhengige eide ruter før du stoler på en kombinert autentiseringsberegning.
Knytt hver melding til en tilstandsovergang
For en kvittering, identifiser applikasjonshendelsen som oppretter den og identifikatoren som kobler den til innsendingen. For en avtalepåminnelse, ta opp planleggingssystemet, tidssonen og oppførselen for omplanlegging. For en statusoppdatering, identifiser saksbehandlingsovergangen og det autoritative stedet hvor innbyggeren kan bekrefte den. Hold varslingstiden atskilt fra den underliggende hendelsestiden.
Tilordne hver hendelse til avsenderapplikasjonen, leverandørleietaker, Fra domene, konvoluttavsender, DKIM domene og velger. Nettportalens domene og TLS sertifikat viser ikke hvilket system som sender e-post. En applikasjonsintegrasjon kan velge en annen leverandør for hver varslingsfamilie, selv når alle meldinger deler samme visuelle design.
Designtester rundt endringer, ikke bare den lykkelige veien
Bruk fiktive applikasjoner og autoriserte testpostbokser. Utløse en innsending, endret avtale, kansellert avtale og statusendring i et godkjent testmiljø der dette er tilgjengelig. Inspiser de endelige meldingsbytene og mottakerens pålitelige autentiseringsresultat. Bekreft at lenker og viste referanser fører til den forventede offisielle tjenesten, uten å inkludere reelle borgersaksdetaljer i generelle testlogger.
En påminnelse som står i kø før omlegging kan signeres korrekt og fortsatt beskrive en foreldet avtale. Domeneautentisering løser ikke denne applikasjonsfeilen. Spor varselets opprinnelseshendelse og versjon slik at operasjoner kan skille gammelt innhold fra en identitetsfeil. På samme måte bør en duplikatkvittering undersøkes som en hendelse eller prøve på nytt i stedet for automatisk å bli klassifisert som forfalskning.
Bestem hvem som stopper en ødelagt reise
Applikasjonseier bør vurdere om innbygger kan fortsette trygt når e-post er utilgjengelig. Planleggingseier bør håndtere påminnelsesavvik, og saksdrift skal håndtere statusmeldinger. Definer den godkjente alternative statussjekkingsveien og eskaleringskontakten før innstramming av policyen. Ikke lov en alternativ kanal med mindre den er genuint støttet og bemannet.
Hvis en avsender ikke er justert, verifiser tjenestens faktiske egendefinerte domenekapasitet og leietakergenererte poster. Endre bare den godkjente identitetsbanen, test den og behold en datert tilbakestillingsplan. Unngå bred SPF tillegg laget utelukkende fordi en kilde-IP ser kjent ut. En leverandør kan autentisere sitt eget domene uten å etablere justering med den offentlige tjenestens Fra-domene.
Overvåk fullstendighet i stedet for bare prosenter
Registrer hvilke varslingsfamilier som ble observert, hvilke som ble testet og hvilke som forblir ubekreftede. Inkluder sjeldne livssyklushendelser og lokalspråklige varianter når de bruker forskjellige maler eller systemer. Bruk samlede rapporter for å identifisere mønstre innenfor deres faktiske rapporteringsdekning, og deretter undersøke manglende eller sviktende ruter med servicebevis. Oppdater kartet etter portaloppgraderinger, planleggerendringer, leverandørbytte og endringer i Fra-domenet. Det er ikke hevdet noen spesifikk lovfestet meldefrist her.
Arbeid gjennom tre skriftlige ruteoppføringer
Disse reserverte eksempeldomenene, velgerne, rollene og forbigående DKIM lokaler er fiktive. Ingen signert melding, nøkkel, kryptografisk verifisering, DNS oppslag, SMTP transaksjon eller live-tjenestetest leveres eller utføres for disse tilfellene. Ingen testkode eller ekstern prøve er nødvendig for å inspisere resonnementet nedenfor.
- kvittering: synlig fra receipts.civic.example ; DKIM d=receipts.civic.example; velgerdemo1; anta at DKIM passerer kun for denne skriftlige saken. SPF -POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Applikasjonstjenesteeier. Neste handling: Skaff en autorisert prøve og et pålitelig mottakerresultat for denne eksakte leietakeren.
- avtalepåminnelse: synlig fra domene appointments.civic.example ; DKIM d=appointments.civic.example; velgerdemo2; anta at DKIM passerer kun for denne skriftlige saken. SPF -POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Planleggingseier. Neste handling: Bekreft denne separate ruten og dens forretningshendelse i stedet for å arve den første rutens resultat.
- statusmelding: synlig fra status.civic.example ; DKIM d=provider.example.net; velgerdemo3; anta at DKIM passerer kun for denne skriftlige saken. SPF -POST FRA identitet og resultat ukjent; andre signaturer ukjent; faktisk politikkoppdagelse og levering ukjent. Foreslått eier: Saksbehandlereier. Neste handling: Spør den bekreftede leverandøren om denne leietakerens støttede justerte signeringsbane; ikke utvide autorisasjonen til hele nettverket.
For de to første angitte signaturene er d= nøyaktig lik Fra-domenet, så identifikatoren tilfredsstiller både streng og avslappet justering. Gitt det angitte vellykkede DKIM resultatet, eksisterer det en justert autentiseringsbane for disse hypotetiske meldingene. Den tredje underskriveren er bevisst ikke relatert til forfatterdomenet og kan ikke oppgi den justerte banen. Ikke ring den tredje meldingen a DMARC feil: justert SPF eller en annen justert pasning DKIM signatur kan fortsatt tilfredsstille mekanismen, og disse inngangene er ukjente. Ikke antyd reell distribusjon eller innboksplassering fra noen rad.
En kryptografisk signatur autentiserer et signeringsdomenes ansvar, ikke sannheten eller autorisasjonen for hver instruksjon. Endringer i dekkede kanoniserte bytes kan ugyldiggjøre en signatur; ikke alle synlige redigeringer endrer nødvendigvis den signerte inngangen. Autentisering og godkjenning på applikasjonsnivå forblir atskilt.
Løs et eksempel på en gammel påminnelse
Anta at den fiktive saken C-01 avtale versjon 1 var 10:00 GST og versjon 2 flytter den til 11:00 GST samme dag. En allerede i kø versjon-1 påminnelse er fastsatt for å passere justert DKIM . Identitetsresultatet gjør ikke 10:00 aktuell. Planleggingseieren bør bruke den godkjente kansellerings- eller erstatningsregelen, verifisere gjeldende avtale i den offisielle portalen og sjekke om en korreksjon faktisk ble levert. Hvis meldingen i stedet har versjon 2, men ingen pålitelig autentiseringsbevis, undersøk e-postruten separat. Ingen reell sak, melding, omleggingsjobb eller korrigeringssending ble brukt her.
Bruk standardene uten å kreve overholdelse
RFC 9989 avsnitt 4.4 og 5.3.5 støtte justeringen og mekanismeskillet. Seksjon 7.4 advarer om interoperabilitet med indirekte e-post: domener som bruker p=reject må bruke gyldig DKIM , ikke SPF alene, og generell bruk av e-postlister krever spesiell forsiktighet. En rutebeholdning er ikke i seg selv tillatelse til å håndheve avvisning. RFC 6376 avsnitt 3.4–3.7 og 6.1 beskrive signerte inndata og verifisering. RFC 9990 Seksjon 3.1 gir rapporteringskontekst, ikke ankomstbevis per mottaker. RFC 5321 Seksjon 4.2.5 skiller serverakseptansvar fra senere leveringsresultater. Sektorarbeidsflytvalg her er redaksjonelle anbefalinger; juridisk omfang, faktor egnethet og lokal autorisasjon trenger sin egen ansvarlige vurdering.