Authentication-Results låter ett e-postsystem kommunicera autentiseringsutvärderingar till nedströmskomponenter. Det är användbart just eftersom ett filter eller användargränssnitt kanske inte upprepar varje originalkontroll. Denna användbarhet skapar också ett säkerhetsberoende: konsumenten måste veta vilken utvärderares rapport den läser och om en angripare kunde ha tillhandahållit den rapporten.
Läs resultatet tillsammans med dess identitet
Fältet inkluderar en autentiseringstjänstidentifierare, vanligen kallad authserv-id, följt av metodresultat och egenskaper. Ett resultat som spf=pass behöver sin tillhörande utvärderade identitet; dkim=pass gäller en viss signeringsdomän; dmarc=pass gäller den tillämpliga författare-domänen inriktning utvärdering. Samla inte ordet "pass" från någonstans i rubriken och visa ett universellt autentiserat märke. RFC 8601 avsnitt 2.2 och 2.7.
Identifieraren för autentiseringstjänsten namnger rapporteringstjänsten i det relevanta administrativa sammanhanget. Det är inte en signatur över fältet. En avsändare kan skriva in samma identifierare i ett meddelande om inte gränshantering förhindrar att det opålitliga fältet förväxlas med ett lokalt genererat.
Definiera konsumentens pålitliga källor
Upprätta den faktiska mottagningsvägen, inklusive godkända uppströms gateways och interna reläer. Dokumentera vilka tjänstidentifierare som förväntas, vilka komponenter som genererar resultat och hur externa fält tas bort eller bevaras som opålitliga. RFC 8601 :s säkerhetsvägledning tar upp detta förtroendegränsproblem. Sluta inte enbart till en säker konfiguration från ett rimligt värdnamn eller fältet som visas nära toppen av ett kopierat meddelande. RFC 8601 avsnitt 7.
En konfigurationsändring till en uppströms gateway kan ändra vilka resultat som är användbara nedströms. Granska beroendet istället för att bara lägga till varje ny identifierare till en betrodd lista. Ett inaktuellt förtroendebeslut kan göra ett annars väl analyserat resultat missvisande.
Läs en hypotetisk metodspecifik rapport
Antag att den etablerade mottagande utvärderaren rapporterar spf=pass för smtp.mailfrom= vendor.example , dkim=pass för header. d=brand.example och dmarc=pass för rubrik. from=brand.example. SPF pass stämmer inte bara för att det säger pass; den exakta DKIM signeringsdomän i det här exemplet matchar författarens domän. Den rapporterade DMARC Resultatet är därför förenligt med den anpassade signaturen, förutsatt att en tillämplig policy och inga olösta utvärderingsfel.
Anta nu att ett annat fält rapporterar spf=temperror. Skriv inte över det första SPF -resultatet utan att identifiera dess utvärderare, hopp och utvärderade identitet. De två rapporterna kan beskriva olika utvärderingar. Om det sammanhanget saknas, rapportera konflikten och osäkerheten. Dessa är hypotetiska rapportvärden, inte oberoende beräknade SPF , DKIM eller DMARC resultat.
En användbar konsumentutgång namnger den betrodda utvärderaren och visar varje metod, domän och resultat separat. Den får inte marknadsföra en opålitlig rapport med samma namn bara för att dess värdnamn liknar den konfigurerade tjänsten.
Bevara nyans i domen
Håll metodresultat åtskilda, inklusive inga, misslyckade och feltillstånd som tillämpligt. Ett frånvarande resultat är inte ett fel som du har observerat, och ett tillfälligt utvärderingsproblem är inte ett bevis på att domänens permanenta konfiguration är felaktig. Korrelera den valda rapporten med meddelande och anslutningsbevis före åtgärd. Avsluta med rapporteringstjänsten, dess etablerade förtroendegrund, metoden och identiteten samt gränsen för slutsatsen. Autentisering kan stödja routing- eller filtreringsbeslut utan att intyga avsändarens avsikt.
Anteckna vad varje resultat faktiskt betyder
- Utvärderare: namnge tjänsten och bevisen som bekräftar dess ursprung.
- Metod: bevara SPF , DKIM och DMARC som separata resultat.
- Identitet: bifoga den utvärderade domänen eller egendomen till sitt eget resultat.
- Osäkerhet: Fortsätt saknas, ingen, misslyckas och feltillstånd distinkta.
- Konsument: bekräfta att gatewayändringar inte har ogiltigförklarat förtroendekonfigurationen.