Authentication-Results lar et e-postsystem kommunisere autentiseringsevalueringer til nedstrømskomponenter. Det er nyttig nettopp fordi et filter eller brukergrensesnitt kanskje ikke gjentar hver opprinnelige kontroll. Denne nytten skaper også en sikkerhetsavhengighet: forbrukeren må vite hvilken evaluatorrapport den leser og om en angriper kunne ha levert den rapporten.
Les resultatet sammen med dets identitet
Feltet inkluderer en autentiseringstjenesteidentifikator, vanligvis kalt authserv-id, etterfulgt av metoderesultater og egenskaper. Et resultat som spf=pass trenger sin tilhørende evaluerte identitet; dkim=pass gjelder et bestemt signeringsdomene; dmarc=pass gjelder det aktuelle forfatterdomenet justering evaluering. Ikke samle ordet "pass" fra hvor som helst i overskriften og vis et universelt autentisert merke. RFC 8601 avsnitt 2.2 og 2.7.
Identifikatoren for autentiseringstjenesten navngir rapporteringstjenesten i den relevante administrative konteksten. Det er ikke en signatur over feltet. En avsender kan skrive inn den samme identifikatoren i en melding med mindre grensehåndtering forhindrer at det ikke-klarerte feltet forveksles med et lokalt generert.
Definer forbrukerens pålitelige kilder
Etablere selve mottaksbanen, inkludert godkjente oppstrøms gatewayer og interne releer. Dokumenter hvilke tjenesteidentifikatorer som forventes, hvilke komponenter som genererer resultater og hvordan eksterne felt fjernes eller bevares som uklarerte. RFC 8601 sikkerhetsveiledning adresserer dette tillitsgrenseproblemet. Ikke utlede en sikker konfigurasjon utelukkende fra et plausibelt vertsnavn eller feltet som vises nær toppen av en kopiert melding. RFC 8601 del 7.
En konfigurasjonsendring til en oppstrøms gateway kan endre hvilke resultater som er nyttige nedstrøms. Gå gjennom avhengigheten i stedet for bare å legge til hver nye identifikator til en klarert liste. En foreldet tillitsbeslutning kan gjøre et ellers godt analysert resultat misvisende.
Les en hypotetisk metodespesifikk rapport
Anta at den etablerte mottaksevaluatoren rapporterer spf=pass for smtp.mailfrom= vendor.example , dkim=pass for header. d=brand.example og dmarc=pass for header. from=brand.example. SPF pass passer ikke bare fordi det står bestått; den eksakte DKIM signeringsdomene i dette eksemplet samsvarer med forfatterdomenet. Den rapporterte DMARC Resultatet er derfor kompatibelt med den justerte signaturen, forutsatt en gjeldende policy og ingen uløst evalueringsfeil.
Anta nå at et annet felt rapporterer spf=temperror. Ikke overskriv det første SPF resultatet uten å identifisere dets evaluator, hop og evaluerte identitet. De to rapportene kan beskrive ulike evalueringer. Hvis den konteksten mangler, rapporter konflikten og usikkerheten. Dette er hypotetiske rapportverdier, ikke uavhengig beregnede SPF , DKIM eller DMARC -resultater.
En nyttig forbrukerutgang navngir den pålitelige evaluatoren og viser hver metode, domene og resultat separat. Den må ikke markedsføre en uklarert rapport med samme navn bare fordi vertsnavnet ligner den konfigurerte tjenesten.
Ta vare på nyanser i dommen
Hold metoderesultatene atskilt, inkludert ingen, feil- og feiltilstander etter behov. Et fraværende resultat er ikke en feil du har observert, og et midlertidig evalueringsproblem er ikke et bevis på at domenets permanente konfigurasjon er feil. Korreler den valgte rapporten med melding og koblingsbevis før utbedring. Avslutt med rapporteringstjenesten, dens etablerte tillitsgrunnlag, metoden og identiteten og grensen for konklusjonen. Autentisering kan støtte ruting- eller filtreringsbeslutninger uten å bekrefte avsenderens hensikt.
Registrer hva hvert resultat faktisk betyr
- Evaluator: navngi tjenesten og bevisene som fastslår dens opprinnelse.
- Metode: bevar SPF , DKIM og DMARC som separate resultater.
- Identitet: knytte det evaluerte domenet eller eiendommen til sitt eget resultat.
- Usikkerhet: hold mangler, ingen, feil og feiltilstander distinkte.
- Forbruker: bekreft at gatewayendringer ikke har ugyldiggjort klareringskonfigurasjonen.