En postlisteimplementering involverer mere end én afsendende identitet. Domænet, der er vært for listen, kan sende abonnementsmeddelelser og videredistribuere beskeder skrevet af personer i andre domæner. Medarbejdere kan også poste fra organisationens domæne til lister, der drives andetsteds. Hver vej har brug for sin egen autentificering og politikvurdering.
Start med at navngive den rolle, der gennemgås. En rekord beskyttelse af listestyringsmeddelelser løser ikke automatisk autentificering for omfordelte indlæg. En gyldig listesignatur stemmer ikke automatisk overens med den oprindelige forfatters Fra-domæne.
Adskil de tre mailstrømme
Byg et lille ruteregister, før du ændrer politik:
- Administrativ post stammer fra listetjenesten, såsom abonnementsbekræftelser.
- Indlæg modtaget fra forfattere og videredistribueret til abonnenter.
- Beskeder, som brugere sender fra dit domæne til eksterne lister.
For hver skal du registrere den ansvarlige operatør, synlig fra domæne, kuvertidentitet, signeringsdomæner og transformationer. Behold listen over softwareindstillinger med den rute i stedet for at behandle hver besked fra den samme server som det samme flow.
De e-mail-identitetskæde forklarer hvilke felter der betyder noget. Under RFC 9989 §3.2.2, kan en svar-til-adresse eller en venlig liste ikke erstatte forfatterdomænet for DMARC justering.
Sammenlign direkte og omdistribueret levering
Tabellen nedenfor er en syntetisk sammenligning, ikke opfangede meddelelsesdata. Antag en gældende gyldig DMARC -politik, gennemførte kontroller og ikke-relaterede organisationsdomæner for writers.example og lists.example . Antag, at en original besked fra author@writers.example er korrekt signeret med d=writers.example og sendt via en SPF-autoriseret original rute.
- Observation: Synlig fra domæne; Direkte rute: writers.example ; Listeomfordeling, der bevarer From: writers.example
- Observation: Tilslutningskilde; Direkte rute: Original afsendelsestjeneste; Listeomfordeling, der bevarer Fra: Listeserver
- Observation: Konvolutdomæne; Direkte rute: writers.example ; Listeomfordeling, der bevarer From: lists.example , efter listeomskrivning
- Observation: Original DKIM signatur; Direkte rute: Gælder i dette eksempel; Listeomfordeling, der bevarer Fra: Afhænger af, om signeret indhold overlever
- Bemærkning: Yderligere liste signatur; Direkte rute: Ingen antaget; Listeomfordeling, der bevarer Fra: d=lists.example kan verificere
- Observation: DMARC spørgsmål; Direkte rute: Passer en forbipasserende original identitet?; Listeomfordeling, der bevarer Fra: Er enhver overlevende forbipasserende identitet stadig på linje med writers.example ?
Under RFC 9989 §4.4.2 og RFC 7208 §2.4, hvis listen omskriver konvolutten til lists.example , en SPF pass godkender listens identitet. Det stemmer ikke overens med writers.example , blot fordi omfordeling var legitim. Under RFC 9989 §4.4.1 og RFC 9989 §5.3.5, hvis den originale DKIM signatur overlever og justeres, kan den stadig levere den nødvendige sti. Hvis en listesidefod eller en ændret signeret overskrift ugyldiggør den originale signatur, erstatter en ny signatur fra et ikke-relateret listedomæne ikke den manglende justering.
Det faktiske resultat afhænger af de faktiske transformationer, signaturer og modtager. Undersøg begge versioner i stedet for at antage, at hver liste bevarer eller ødelægger det samme materiale.
Gem meddelelsesændringsbeviser
Når en omfordelt besked mislykkes DKIM, sammenligne den originale signerede version med versionen hos abonnenten. Tjek kropsændringer, emneredigeringer og andre signerede felter som beskrevet i RFC 6377 §3.3. Normale meddelelsesoverskrifter, der tilføjes senere, ugyldiggør ikke alle DKIM ; underskriftens dækning og kanonisering sagen under RFC 6376 §3.4 og RFC 6376 §3.7.
Behold hver signatur og dens d- og s-værdier. En besked kan have flere signaturer, og en fejl betyder ikke, at hver signatur mislykkedes. Bruge body-hash-undersøgelsen når kroppen ændrede sig, og skelne dette resultat fra en manglende nøgle eller en anden verifikationsfejl.
Fjern aldrig en ægte virksomhedssidefod udelukkende ud fra et gæt om, at den forårsagede fiasko. Demonstrer ændringen og se listeoperatørens understøttede konfiguration. Den nyttige rettelse bevarer den påkrævede listefunktion, samtidig med at den resulterende identitetsadfærd tydeliggøres.
Vurder tilgængelige driftsvalg
En listeoperatør kan undersøge understøttede måder at undgå at beskadige den originale signatur, underskrive sin egen mail og vælge, hvordan den præsenterer forfatterskab. Som diskuteret i RFC 7960 §4.1.3.3, hvis tjenesten omskriver det synlige Fra til et listekontrolleret domæne, vedrører den resulterende DMARC evaluering det nye forfatterdomæne. Det kan ændre den identitet, der vises til abonnenter, og svaroplevelsen, så test både sikkerhed og brugervenlighed.
Som beskrevet i RFC 6377 §5.8, underskriver videredistribueret post, da listen kan etablere ansvar for det pågældende listedomæne. Den kan ikke i sig selv certificere den oprindelige forfatter eller gendanne justeringen med et ikke-relateret uændret Fra-domæne.
For modtagende organisationer kan lokal analyse genkende en legitim indirekte rute. Under RFC 9989 §5.4, er accept i henhold til denne analyse ikke det samme som DMARC pass. Bevar det faktiske resultat og enhver tilgængelig tilsidesættelsesforklaring, og undgå at behandle en bred tillade-regel som en permanent løsning for hver meddelelse, der bruger listens infrastruktur.
Vælg politik for domænets faktiske brug
RFC 9989 §7.4 advarer eksplicit mod at offentliggøre afvisning for domæner, hvis generelle brugere kan sende til internet-mailinglister. Dens interoperabilitetssektion beskriver både brugerpåvirkning og modtageransvar. Et program bør anvende denne vejledning, når det vælger politik, snarere end at love, at alle domæner i sidste ende skal bruge afvisning.
Et domæne, der kun stammer fra kontrollerede listeadministrationsmeddelelser, har en anden anvendelse end et personaledomæne, hvis brugere deltager i mange eksterne lister. Gennemgå de vigtige indirekte strømme, før du vælger politik for enten. Afvisning af domæneudgivelse skal anvende gyldige DKIM signaturer og må ikke udelukkende stole på SPF .
Hold en reproducerbar listetest
Brug godkendte testforfattere og abonnentkonti. Send en direkte kontrol og en repræsentativ listepost, og bevar derefter versioner, rute, tidsstempler og betroede modtagerresultater inden for den grænse, der er angivet af RFC 8601 §7.1. Medtag de listefunktioner, der faktisk bruges, såsom sidefødder og emnepræfikser. Registrer softwareversion og konfiguration, når de påvirker transformationen.
Ingen reel listeudførelse hævdes af sammenligningen i denne vejledning. I dit eget miljø skal du beholde faktiske observationer og gentest, når du viser software, gateways, signering eller politikændringer. Et resultat fra én rute eller modtager etablerer ikke universel levering.
En nyttig mailingliste-vurdering viser, hvem der stammede fra hver besked, hvad listen ændrede sig, hvilke autentificerede identiteter der overlevede, og hvordan abonnentens modtager håndterede det. Opbevar disse resultater hos listeejeren, så senere ændringer ikke genstarter undersøgelsen fra en politiketiket.
Registrer beslutningen og dens grænser
Med uændret Fra og det formodede ikke-relaterede listedomæne, vil tab af den originale beståede DKIM signatur efterlade hverken omskrevet-konvolut SPF eller listesignaturen justeret. Hvis den originale signatur overlever, kan den bevare stien. En fra-omskrivning skaber en anden evaluering, ikke et bevis på, at det oprindelige forfatterdomæne bestod. DKIM fejl alene identificerer ikke, hvilket hop ændret indhold: bevar også nøgle-, signatur- og kanoniseringsbeviser.