[ DKIM ]

Diagnostiser DKIM efter ændringer af mailingliste

Kortlisteændringer og signeringsidentiteter, før du beslutter, hvordan legitim listepost skal håndteres.

Af EmailAuth -forskningsteamet

[Nøglepunkter]

  • Sammenlign listeinput og -output, og hold hver signatur adskilt.
  • En ny listesignatur reparerer ikke en original signatur.
  • Test tilskrivning og svar sammen med godkendelse.
På denne side

Postlister kan ændre selve indholdet til en original DKIM signatur beskytter. Et emnepræfiks, sidefod, MIME omskrivning eller ændring af forfatter-header kan ændre resultatet. Diagnostiser hver transformation og listens egen signeringsadfærd, før du beslutter, om problemet er kryptografisk verifikation, justering eller modtagerhåndtering.

Fang listegrænsen

Brug en kontrolleret besked sendt både direkte og gennem listen. Få den originale indsendelse, hvor den er godkendt, listens videredistribuerede besked og den endelige modtagers betroede godkendelsesresultat. Optag det synlige From-domæne før og efter omfordeling og hver DKIM signering af domæne.

En sidefod kan ændre kropshash. Et emnepræfiks kan ugyldiggøre en signatur, der dækker emne. MIME genopbygning kan ændre kropsrepræsentationen, selv når den viste tekst ligner. Under RFC 6376 §5.4, Fra skal være dækket af en DKIM signatur, så omskrivning af den ændrer beskyttet headerindhold for den originale signatur. Det præcise resultat afhænger stadig af kanonisering, dækning og alle andre kontroller.

Skeln på listens signatur

RFC 6376 §5.5 siger, at en ændrende listeadministrator, der implementerer DKIM bør kontrollere en eksisterende signatur ved input og skal foretage ændringer, før den gensigner. En ny signatur kan autentificere listens endelige indhold under listens underskriftsdomæne. Den gendanner ikke den originale signatur med tilbagevirkende kraft eller hævder automatisk den oprindelige forfatters domæne.

For DMARC, undersøg justering i forhold til det endelige forfatterdomæne under RFC 9989 §4.4.1. Hvis listen beholder det oprindelige forfatterdomæne, men kun signerer med et ikke-relateret listedomæne, er det nye DKIM pas ikke alene en tilpasset sti. Hvis en understøttet listekonfiguration omskriver Fra til et listekontrolleret domæne og signerer med et tilpasset domæne, er de identiteter, der evalueres hos modtageren, forskellige. Denne ændring har brugersynlige svar- og tilskrivningskonsekvenser og bør gennemgås, ikke behandles som en skjult teknisk kontakt.

Gå gennem en kontrolleret sammenligning

Illustrativ case: en original meddelelse fra et forfatterdomæne har en gyldig helkropssignatur. Listen tilføjer en sidefod og signerer den ændrede besked ved hjælp af sit eget ikke-relaterede domæne, mens den originale Fra bevares. Den originale signatur kan fejle, og listesignaturen kan bestå, men sidstnævnte opfylder ikke i sig selv DKIM justeringen for den originale From. Dette forklarer, hvorfor et generisk " DKIM pass"-mærke kan være vildledende.

Brug kun en anden test, hvis listen tilbyder et understøttet alternativ, såsom en anden ændrings- eller forfatterhåndteringspolitik. Sammenlign modtagerresultater og menneskevendt svaradfærd. Antag ikke, at hvert listeprodukt har de samme muligheder, eller at alle modtagere vil træffe den samme acceptbeslutning.

Vælg en dokumenteret listepolitik

Mulige designvalg omfatter reduktion af unødvendige ændringer, signering af det endelige omdistribuerede indhold eller brug af understøttet forfatterhåndteringsadfærd med tydelig tilskrivning. Hvert valg skal være knyttet til listens formål og aktuelle produktdokumentation. Undgå at aktivere delvis kropsdækning gennem l som en universel sidefodløsning; RFC 6376 §8.2 advarer om risici med usigneret tilføjet indhold.

Hvis en modtager accepterer legitim indirekte post gennem en lokal undtagelse eller yderligere pålidelige beviser, skal denne beslutning dokumenteres separat fra DKIM og DMARC -dommene i overensstemmelse med RFC 9989 §5.3.6. Undlad at svække hele forfatterens domænepolitik, blot fordi en listesti kræver undersøgelse.

Valider læseroplevelsen

Test almindelig tekst, HTML og vedhæftede filer, plus Besvar og svar alle-adfærd. Bevar både autentificeringsbeviser og en menneskelig gennemgang af tilskrivning. En fuldført rettelse viser, hvilken identitet der tager ansvar for den videredistribuerede besked, hvilke originale garantier, der overlever, og hvordan abonnenter kan svare uden at blive vildledt.

Beviser nødvendig for den næste beslutning

Brug en hypotetisk listekørsel til at udfylde én række pr. signatur: original-/listeidentitet, signerede overskrifter, kropsdækning, verifikationsresultat og justering til det endelige forfatterdomæne. Hvis originalen fejler, og den ikke-relaterede liste-identitet passerer, skal du kontrollere SPF justering separat, før du tildeler et DMARC -resultat. Fang svaradfærd, før du godkender en synlig identitetsomskrivning. Disse er foreslåede gennemgangstrin, ikke udførte tests.

[ Takeaway ]

Sammenlign listeinput og -output, og hold hver signatur adskilt. En ny listesignatur reparerer ikke en original signatur. Test tilskrivning og svar sammen med godkendelse.

[Efter rolle]

Hvad betyder det for dig

Vælg din rolle for praktiske næste trin.

IT / Mail Admin

Kort original og liste signaturer

Adskil inputbekræftelse fra outputsignering og justering.

Næste trin

  1. Fang begge grænser.
  2. Test hver understøttet listeindstilling.

CISO / SecOps

Anvendelsesområde for beslutninger om indirekte mail

En listeundtagelse bør ikke stille lempe beskyttelsen for hver afsender.

Næste trin

  1. Dokumenter tillidsantagelser.
  2. Gennemgå den resterende risiko for personefterligning.

Grundlægger / Ikke-teknisk

Inkluder abonnentoplevelse

En teknisk forbigået ændring kan stadig forvirre tilskrivning eller svar.

Næste trin

  1. Godkend synlige identitetsændringer.
  2. Test vigtige diskussionslister.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Kan et emnepræfiks bryde DKIM ?

Ja, når det ændrer et emnefelt, der er dækket af den originale signatur.

RFC 6376 §5.4

Kan en listesidefod ændre body-hashen?

Ja, under almindelig helkropsdækning tilføjer det væsentligt indhold med underskrevet krop.

RFC 6376 §3.4 RFC 6376 §3.7

Reparerer listesignering den originale signatur?

Nej. Det skaber en separat signatur over den omfordelte besked.

RFC 6376 §5.5

Hvorfor kan liste DKIM pass mens DMARC fejler?

Listens signeringsdomæne flugter muligvis ikke med det endelige synlige Fra-domæne, og ingen anden justeret sti må passere.

RFC 9989 §4.4.1 RFC 9989 §5.3.5

Er From omskrivning usynlig for abonnenter?

Nej. Det ændrer en synlig identitet og kan påvirke tilskrivning og svaradfærd.

Skal hver liste bruge l?

Nej. Delvis kropsdækning skaber usignerede indholdsrisici og er ikke et universalmiddel.

RFC 6376 §8.2

Skal vi deaktivere domænehåndhævelse for én liste?

Diagnostiser listeruten og understøttede alternativer først; en bred politikændring kan have bredere konsekvenser.

Hvad hører hjemme i accepttest?

Godkendelsesresultater, sammenligning af rå beskeder, afsendertilskrivning og Svar/Svar alle-adfærd på tværs af relevante formater.

[ Kilder ]

Kilder

  1. RFC 6376

    Afsnit §1 · §3.1 · §3.4 · §3.5 · §3.7 · §5.4 · §5.5 · §8.2

  2. RFC 9989

    Afsnit §4.4 · §4.4.1 · §5.3.5 · §5.3.6

  3. RFC 8601

    Afsnit §1.2 · §7.1

[ Ordliste ]

Ordliste

DKIM
En domæneassocieret signatur over valgt beskedindhold, verificeret ved hjælp af offentlig nøgledata.

RFC 6376 §1

Vælger
S-værdien, der bruges med d-signeringsdomænet til at finde bekræftelsesdata.

RFC 6376 §3.1 RFC 6376 §3.5

DMARC justering
Det påkrævede forhold mellem en autentificeret identifikator og forfatterdomænet.

RFC 9989 §4.4

Kanonisering
Specificeret klargøring af overskrifter eller brødtekst før DKIM hashing og verifikation.

RFC 6376 §3.4

Virksomhedens herkomst

Hvorfor top finansielle institutioner og regeringer pensionerede deres e-mailsikkerhedsdashboards.

Traditionelle e-mail-godkendelsesplatforme sælger dig et dashboard og beder dine ingeniører om at gøre arbejdet. I miljøer med høj indsats betyder manuel overvågning forsinket håndhævelse, konfigurationsdrift og uovervågede skyggedomæner.

EmailAuth er den agentiske e-mail-herkomstplatform. Vores agenter håndhæver p=reject, hold tredjepartsafsendere på linje og flyt dine domæner til fuld RFC 9989 compliance, den nye DMARC standard, med menneskelig auditabilitet.

regeringer Store virksomheder Tier-1 finansielle institutioner

SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering

Vidensbase