En sikker e-postgateway og DMARC løse overlappende driftsproblemer, men er ikke utskiftbare. En gateway kan inspisere, rute, sette i karantene eller endre meldinger. DMARC evaluerer justert autentisering og gir domenepolicyinformasjon til mottakere. Det viktige spørsmålet er hvordan hele ruten din oppfører seg, inkludert transformasjoner etter at en signatur er opprettet.
Tegn selve meldingsbanen
Record innsending, signering, gateway-behandling og endelig kvittering i orden. Identifiser hvilke komponenter du kontrollerer og hvilke identiteter hver er autorisert til å signere. Et diagram som sier at bare gateway er aktivert kan ikke fastslå om en nedstrøms mottaker får en intakt justert signatur. Skaff originale og endelige råmeldinger fra en autorisert testrute, og oppbevar meldingsidentifikatorer og tider.
DKIM dekker utvalgte overskrifter og en kanonisert kropp. En omskrivning av kroppen kan ugyldiggjøre en eksisterende signatur selv om den endrede koblingen er en del av en legitim sikkerhetsfunksjon. RFC 6376 definerer signatur- og verifiseringsatferden. DKIM spesifikasjon. Ta vare på den signerte overskriftslisten, kanonisering valg og eventuelle kroppslengdeparametere når du forklarer en spesifikk feil.
Plasser bekreftelse og signering bevisst
En innkommende gateway kan bekrefte en melding før endring, men det interne resultatet er ikke automatisk pålitelig for alle nedstrømsmottakere. Definer hvordan det neste systemet gjenkjenner pålitelige resultater og hva det gjør med uklarerte topptekstpåstander. RFC 8601. En senere verifikatoren som sjekker modifiserte bytes kan oppnå et annet resultat av en legitim grunn.
For en utgående rute du administrerer, kan signering etter godkjente transformasjoner unngå å bryte den endelige signaturen. Underskriveren må være autorisert for sitt domene, og justering trenger fortsatt evaluering. Å legge til en gyldig signatur fra et urelatert gatewaydomene gir ikke nødvendigvis et justert DMARC resultat. Ikke fjern sikkerhetsinspeksjon bare for å bevare en signatur uten å gå gjennom den bredere kontrolldesignen.
Spor en hypotetisk omskriving
Anta at en autorisert brand.test-underskriver signerer en meldingstekst som inneholder en URL. En gateway endrer deretter den dekkede URL-adressen uten å legge til en autorisert justert signatur etterpå. Hvis de kanoniserte signerte bytene endres, vil ikke den tidligere signaturen valideres mot den endrede kroppen. En transformasjon som lar de relevante kanoniserte signerte bytene være uendret, trenger ikke bryte signaturen. Inspiser kanonisering, valgte overskrifter og eventuell l=-grense i stedet for å anta at hver omskriving har samme effekt.
Hvis en separat autorisert signatur signerer den endelige transformerte meldingen, kan den nye signaturen bekreftes selv mens den gamle signaturen mislykkes. Den reparerer ikke den gamle signaturen eller beviser at den nye underskriveren hadde forretningsmyndighet. Evaluer det nye d=-domenets justering og det klarerte endelige mottakerresultatet. Dette er protokollbaserte hypotetiske utfall, ikke råmeldingsprøver, genererte nøkler, dkimpy-utdata eller et utført gateway-eksperiment.
Oversett resultatet til en rutetest
I produksjon, reproduser den relevante autoriserte transformasjonen ved å bruke kontrollerte mottakere og leverandørens støttede konfigurasjon. Fang den endelige mottakerens pålitelige resultater i stedet for å utlede suksess fra gateway-konsollen. Sammenlign den samme innholdsrevisjonen på tvers av ruten, og legg merke til andre endringer som emneprefikser eller ansvarsfraskrivelser. En bestått ny signatur beviser ikke at tidligere autentisering overlevde.
Test feilhåndtering også. Hvis et signeringstrinn ikke er tilgjengelig, avgjør om e-postkøer, mislykkes eller går uten forventet signatur. Hold gjenopprettingsinstruksjonene knyttet til den faktiske tjenesten. Unngå en nødbypass som gjør et innesluttet autentiseringsproblem til ubegrenset relé eller uinspisert levering.
Akseptoppføringen skal gi navn til den testede ruten, transformasjon, underskriverplassering, endelige identiteter og mottakerresultat. Oppretthold separate kontroller for filtrering av skadelig programvare, phishing deteksjon og domeneautentisering. Å bestå én test er et nyttig bevis for denne evnen, ikke et sertifikat på at hele meldingen eller gatewayen er trygg.
Kilde og utførelsesgrense
RFC 9989 avsnitt 4.4, 5.3.5 og 5.4 skille autentisering, justering og håndtering; et pass godkjenner ikke meldingsinnhold. De operasjonelle beslutningene her er anbefalinger med omfang og eksplisitt hypotetiske eksempler, ikke nye tester av en kunde, leverandør eller historisk inventar. Enhver reell endring krever sitt eget autoriserte omfang, beholdt bevis og ansvarlig beslutning.