En sikker e-mail-gateway og DMARC løse overlappende driftsproblemer, men er ikke udskiftelige. En gateway kan inspicere, rute, sætte i karantæne eller ændre meddelelser. DMARC evaluerer tilpasset godkendelse og leverer oplysninger om domænepolitik til modtagere. Det vigtige spørgsmål er, hvordan din komplette rute opfører sig, inklusive transformationer efter en signatur er oprettet.
Tegn den faktiske beskedsti
Rekordafsendelse, underskrift, gatewaybehandling og endelig kvittering i orden. Identificer, hvilke komponenter du kontrollerer, og hvilke identiteter hver enkelt er autoriseret til at underskrive. Et diagram, der siger, at kun gateway er aktiveret, kan ikke fastslå, om en downstream-modtager får en intakt justeret signatur. Få originale og endelige råbeskeder fra en autoriseret testrute, og behold meddelelsesidentifikatorer og -tider.
DKIM dækker udvalgte overskrifter og en kanoniseret krop. En kropsomskrivning kan ugyldiggøre en eksisterende signatur, selvom det ændrede link er en del af en legitim sikkerhedsfunktion. RFC 6376 definerer signatur og verifikationsadfærd. DKIM specifikation. Bevar den underskrevne overskriftsliste, kanonisering valg og enhver kropslængdeparameter, når man forklarer en specifik fejl.
Placer verifikation og underskrift bevidst
En indgående gateway kan bekræfte en meddelelse før ændring, men det interne resultat er ikke automatisk troværdigt for enhver downstream-modtager. Definer, hvordan det næste system genkender pålidelige resultater, og hvad det gør med upålidelige header-påstande. RFC 8601. En senere verifikator, der kontrollerer ændrede bytes, kan nå et andet resultat af en legitim årsag.
For en udgående rute, du administrerer, kan underskrift efter godkendte transformationer undgå at bryde den endelige signatur. Underskriveren skal være autoriseret til sit domæne, og justering skal stadig evalueres. Tilføjelse af en gyldig signatur fra et ikke-relateret gateway-domæne producerer ikke nødvendigvis et justeret DMARC resultat. Fjern ikke sikkerhedsinspektionen blot for at bevare en signatur uden at gennemgå det bredere kontroldesign.
Spor en hypotetisk omskrivning
Antag, at en autoriseret brand.test-underskriver underskriver en meddelelsestekst, der indeholder en URL. En gateway ændrer derefter den dækkede URL uden at tilføje en autoriseret tilpasset signatur efterfølgende. Hvis de kanoniserede signerede bytes ændres, vil den tidligere signatur ikke valideres mod den ændrede krop. En transformation, der efterlader de relevante kanoniserede signerede bytes uændrede, behøver ikke at bryde signaturen. Undersøg kanonisering, udvalgte overskrifter og enhver l=-grænse i stedet for at antage, at hver omskrivning har den samme effekt.
Hvis en separat autoriseret underskriver underskriver den endelige transformerede meddelelse, kan den nye signatur bekræftes, selvom den gamle signatur mislykkes. Det reparerer ikke den gamle signatur eller beviser, at den nye underskriver havde forretningsautoritet. Evaluer det nye d=-domænes justering og det betroede endelige modtagerresultat. Disse er protokolbaserede hypotetiske resultater, ikke råbeskedprøver, genererede nøgler, dkimpy-output eller et udført gateway-eksperiment.
Oversæt resultatet til en rutetest
I produktion skal du reproducere den relevante autoriserede transformation ved hjælp af kontrollerede modtagere og leverandørens understøttede konfiguration. Fang den endelige modtagers pålidelige resultater i stedet for at udlede succes fra gateway-konsollen. Sammenlign den samme indholdsrevision på tværs af ruten, og bemærk andre ændringer såsom emnepræfikser eller ansvarsfraskrivelser. En bestået ny signatur beviser ikke, at tidligere autentificering overlevede.
Test fejlhåndtering også. Hvis et signeringstrin ikke er tilgængeligt, skal du afgøre, om postkøer, fejler eller forlader uden den forventede signatur. Hold genoprettelsesinstruktioner knyttet til den faktiske tjeneste. Undgå en nødbypass, der forvandler et indesluttet godkendelsesproblem til ubegrænset relæ eller ukontrolleret levering.
Acceptregistreringen skal navngive den testede rute, transformation, underskriverplacering, endelige identiteter og modtagerresultat. Vedligehold separate kontroller for malware-filtrering, phishing registrering og domænegodkendelse. At bestå én test er et nyttigt bevis for denne evne, ikke et certifikat for, at hele beskeden eller gatewayen er sikker.
Kilde og udførelsesgrænse
RFC 9989 afsnit 4.4, 5.3.5 og 5.4 skelne autentificering, justering og håndtering; et pas godkender ikke beskedindhold. De operationelle beslutninger her er scoped anbefalinger og eksplicit hypotetiske eksempler, ikke nye test af en kunde, udbyder eller historisk inventar. Enhver reel ændring kræver sit eget autoriserede omfang, bevarede beviser og ansvarlig beslutning.