DMARC - DMARC

Denne artikel handler om et e -mailvalideringssystem. For telefonikrydsningspunktet, se afgrænsningspunkt .
For ikke at forveksle med dMarc Broadcasting .

DMARC ( domænebaseret meddelelsesgodkendelse, rapportering og overensstemmelse ) er en e-mail-godkendelsesprotokol . Det er designet til at give e -mail -domæneejere muligheden for at beskytte deres domæne mod uautoriseret brug, almindeligvis kendt som e -mail -spoofing . Resultatet Formålet og primære gennemføre DMARC er at beskytte et domæne fra at blive brugt i erhvervslivet email kompromis angreb , phishing e-mails, e-mail-svindel og andre cyber trussel aktiviteter.

Når DMARC DNS -posten er offentliggjort, kan enhver modtager -e -mail -server godkende den indgående e -mail baseret på de instruktioner, der er offentliggjort af domæneejeren inden for DNS -posten. Hvis e -mailen passerer godkendelsen, bliver den leveret og kan have tillid til. Hvis e -mailen fejler kontrollen, kan e -mailen blive leveret, karantæne eller afvist afhængigt af instruktionerne i DMARC -posten. For eksempel leverer en e-mail-videresendelsestjeneste mailen, men som "From: no-reply@<forwarding service>".

DMARC udvider to eksisterende e -mail -godkendelsesmekanismer, Sender Policy Framework (SPF) og DomainKeys Identified Mail (DKIM). Det giver den administrative ejer af et domæne mulighed for at offentliggøre en politik i deres DNS -poster for at angive, hvilken mekanisme (DKIM, SPF eller begge dele), der bruges, når der sendes e -mail fra dette domæne; hvordan man kontrollerer From:feltet, der præsenteres for slutbrugere; hvordan modtageren skal håndtere fejl - og en rapporteringsmekanisme for handlinger, der udføres under disse politikker.

DMARC er defineret i Internet Engineering Task Forces offentliggjorte dokument RFC 7489, dateret marts 2015, som "informationsmæssigt".

Oversigt

En DMARC -politik giver en afsenders domæne mulighed for at angive, at deres e -mails er beskyttet af SPF og/eller DKIM, og fortæller en modtager, hvad han skal gøre, hvis ingen af ​​disse godkendelsesmetoder passerer - f.eks. At afvise beskeden eller sætte den i karantæne. Politikken kan også angive, hvordan en e -mail -modtager kan rapportere tilbage til afsenderens domæne om meddelelser, der passerer og/eller fejler.

Disse politikker offentliggøres i det offentlige Domain Name System (DNS) som tekst -TXT -poster .

DMARC adresserer ikke direkte, om en e -mail er spam eller på anden måde svigagtig. I stedet kan DMARC kræve, at en meddelelse ikke kun består DKIM- eller SPF -validering, men at den også skal passe justering . Under DMARC kan en meddelelse mislykkes, selvom den passerer SPF eller DKIM, men mislykkes tilpasning.

Opsætning af DMARC kan forbedre leveringen af ​​meddelelser fra legitime afsendere.

Justering

DMARC fungerer ved at kontrollere, at domænet i meddelelsesfeltet From:(også kaldet "RFC5322.From") er "justeret" med andre godkendte domænenavne. Hvis enten SPF- eller DKIM -justeringskontrol passerer, passerer DMARC -justeringstesten.

Justering kan angives som streng eller afslappet. For streng tilpasning skal domænenavne være identiske. For afslappet justering skal "Organisationsdomæne" på øverste niveau matche. Det organisatoriske domæne findes ved at kontrollere en liste over offentlige DNS -suffikser og tilføje den næste DNS -etiket. Så for eksempel har "abcdexample.com.au" og "example.com.au" det samme organisationsdomæne, fordi der er en registrator, der tilbyder navne i ".com.au" til kunderne. Selvom der på tidspunktet for DMARC -specifikationen var en IETF -arbejdsgruppe om domænegrænser, kan det organisatoriske domæne i dag kun udledes af Public Suffix List .

Ligesom SPF og DKIM bruger DMARC begrebet en domæneejer, den eller de enheder, der er autoriseret til at foretage ændringer af et givet DNS -domæne.

SPF kontrollerer, at IP -adressen på den afsendende server er godkendt af ejeren af ​​det domæne, der vises i SMTP MAIL FROM-kommandoen. (E-mailadressen i MAIL FROM kaldes også bounce-adressen , envelope-from eller RFC5321.MailFrom.) Udover at kræve, at SPF-tjekket passerer, kontrollerer DMARC, at RFC5321.MailFrom er på linje med 5322.From.

DKIM tillader, at dele af en e -mail -besked krypteres, og signaturen skal dække feltet Fra. Inden for DKIM-Signatur-mailoverskriften angiver d=(domæne) og s=(selector) -tags, hvor i DNS de skal hente den offentlige nøgle til signaturen. En gyldig signatur beviser, at underskriveren er en domæneejer, og at feltet Fra ikke er blevet ændret siden signaturen blev anvendt. Der kan være flere DKIM -signaturer på en e -mail -besked; DMARC kræver én gyldig signatur, hvor domænet i d=tagget flugter med afsenderens domæne, der er angivet i From:overskriftsfeltet.

DNS -registrering

DMARC poster offentliggøres i DNS med et underdomæne etiket _dmarc, f.eks _dmarc.example.com. Sammenlign dette med SPF på example.comog DKIM på selector._domainkey.example.com.

Indholdet i TXT -ressourceposten består af name=valuetags, adskilt af semikolon, svarende til SPF og DKIM. For eksempel: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"

Her ver versionen, per politikken (se nedenfor), spunderdomæne -politikken, pctprocentdelen af ​​"dårlige" e -mails, som politikken skal anvendes på, og ruaer URI'en til at sende samlede rapporter til. I dette eksempel har den enhed, der kontrollerer example.com DNS -domænet, til hensigt at overvåge SPF- og/eller DKIM -fejlfrekvenser og forventer ikke, at e -mails sendes fra underdomæner på example.com. Bemærk, at et underdomæne kan offentliggøre sin egen DMARC -post; modtagere skal tjekke det, før de falder tilbage til den organisatoriske domænerekord.

Trin for trin adoption

Protokollen giver mulighed for forskellige skralder eller overgangsstater, så mailadministratorer gradvist kan overgå fra ikke at implementere DMARC overhovedet til en uoverskuelig opsætning. Begrebet trinvis adoption antager, at målet med DMARC er den stærkeste ramme, hvilket ikke er tilfældet for alle domæner. Uanset hensigt giver disse mekanismer større fleksibilitet.

Politik

Først og fremmest er der tre politikker:

  • ingen er entry level -politikken. Modtagere kræver ingen særlig behandling, men giver et domæne mulighed for at modtage feedbackrapporter.
  • karantæne beder modtagere om at behandle meddelelser, der ikke fejler DMARC -kontrol med mistanke. Forskellige modtagere har forskellige midler til at implementere det, f.eks. Markere meddelelser eller levere dem i spam -mappen.
  • afvise beder modtagere om direkte at afvise meddelelser, der ikke fejler DMARC -kontrol.

Den publicerede politik kan formindskes ved kun at anvende den på en procentdel af de meddelelser, der ikke fejler DMARC -kontrol. Modtagere bliver bedt om at vælge den givne procentdel af meddelelser ved hjælp af en simpel Bernoulli -samplingsalgoritme. Resten af ​​meddelelserne bør undergå den lavere politik; det vil sige ingen hvis p=quarantine, karantæne hvis p=reject. Hvis ikke angivet, er pct som standard 100% af meddelelserne. Sagen p=quarantine; pct=0;bruges til at tvinge postliste -ledere til at omskrive feltet Fra: da nogle ikke gør det når p=none.

Endelig giver underdomæne-politikken sp=og den nyligt tilføjede politik uden domæne mulighed for at justere politikken for bestemte underdomæner.

Rapporter

DMARC er i stand til at producere to separate typer rapporter. Samlede rapporter sendes til den adresse, der er angivet efter rua. Retsmedicinske rapporter sendes via e -mail til adressen efter rufmærket. Disse mailadresser skal angives i URI mailto -format (f.eks. Mailto: [email protected]). Flere rapporteringsadresser er gyldige og skal være i fuldt URI -format adskilt med et komma.

Mål -e -mail -adresser kan tilhøre eksterne domæner. I så fald skal måldomænet oprette en DMARC -post for at sige, at det accepterer at modtage dem, ellers ville det være muligt at udnytte rapportering til spamforstærkning . Sig f.eks. receiver.exampleModtagelse af en mailbesked From: [email protected]og ønsker at rapportere den. Hvis den finder ruf=mailto:[email protected]den, leder den efter en bekræftende DNS -post i navneområdet, der administreres af målet, således: 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

Samlede rapporter

Samlede rapporter sendes som XML -filer, typisk en gang om dagen. Det emne nævner "Rapport domæne", som angiver DNS-domænenavn, om hvilken rapporten blev genereret, og "afsender", som er den enhed, der har udstedt rapporten. Nyttelasten er i en vedhæftet fil med et langt filnavn bestående af bang-adskilte elementer såsom den rapportudstedende modtager, begyndelses- og slutepoker af den rapporterede periode som tidsstempler i Unix-stil, en valgfri unik identifikator og en udvidelse, der afhænger af den mulige komprimering (plejede at være .zip).

For eksempel: example.com!example.org!1475712000!1475798400.xml.gz.

XML -indholdet består af et overskrift, der indeholder den politik, som rapporten er baseret på, og rapportmetadata efterfulgt af et antal poster. Optegnelser kan sættes i en database som en relation og ses i tabelform. XML -skemaet er defineret i appendiks C med specifikationer, og en rå post er eksemplificeret i dmarc.org. Her holder vi fast i et relationelt eksempel, som bedre formidler datatypen. DMARC -poster kan også direkte transformeres i HTML ved at anvende et XSL -stilark .

DMARC -rækker af en samlet post vist i tabelform
Kilde -IP Tælle Disposition SPF DKIM Overskrift fra SPF domæne (resultat) DKIM -domæne (resultat)  
192.0.2.1 12 ingen ✓  Pass ✓  Pass eksempel.org example.org ( ✓  Pass ) example.org ( ✓  Pass )  
192.0.2.1 1 ingen ✓  Pass ✗  Fail eksempel.org example.org ( ✓  Pass ) eksempel.org ( ✗  Fejl )  
192.0.2.28 42 ingen ✗  Fail ✓  Pass eksempel.org eksempel.org ( ✗  Fejl ) example.org ( ✓  Pass ) speditøreksempel ( ✓  pas )
192.0.2.82 21 ingen ✗  Fail ✗  Fail eksempel.org discusslist.example ( ✓  Pass ) eksempel.org ( ✗  Fejl ) discusslist.example ( ✓  Pass )
...

Rækker er grupperet efter kilde -IP og godkendelsesresultater, der kun sender antallet af hver gruppe. Resultatkolonnerne til venstre, mærket SPF og DKIM, viser DMARC-resultater, enten bestået eller mislykket, under hensyntagen til justering. De til højre med lignende etiketter viser navnet på det domæne, der hævder at deltage i afsendelsen af ​​meddelelsen og (i parentes) godkendelsesstatus for det krav i henhold til den originale protokol, SPF eller DKIM, uanset identifikatorjustering. På højre side kan SPF højst vises to gange, én gang til Return-Path:testen og én gang til HELOtesten; DKIM kan vises én gang for hver signatur, der findes i meddelelsen. I eksemplet repræsenterer den første række det vigtigste mailflow fra eksempel.org, og den anden række er en DKIM -fejl, f.eks. Signaturbrud på grund af en mindre ændring i transit. Den tredje og fjerde række viser typiske fejltilstande for henholdsvis en videresender og en mailingliste. DMARC -godkendelse mislykkedes kun for den sidste række; det kunne have påvirket beskedets disposition, hvis example.org havde angivet en streng politik.

Den disposition afspejler den politik offentliggjort faktisk anvendes til beskeder, ingen , karantæne , eller afvise . Sammen med det, der ikke er vist i tabellen, giver DMARC mulighed for at tilsidesætte en politik. Nogle grunde til, at en modtager kan anvende en anden politik end den anmodede, er allerede angivet i specifikationen:

videresendt
mens den samme bounce -adresse bevares, bryder den normalt ikke DKIM,
stikprøve ud
fordi en afsender kun kan vælge at anvende politikken kun på en procentdel af meddelelser,
betroet speditør
meddelelsen kom fra en lokalt kendt kilde
mailingliste
modtageren bestemte heuristisk, at meddelelsen kom fra en mailingliste,
lokal politik
modtagere er naturligvis fri til at anvende den politik, de kan lide, det er bare fedt at lade afsendere vide,
Andet
hvis ingen af ​​ovenstående gælder, giver et kommentarfelt mulighed for at sige mere.

Retsmedicinske rapporter

Retsmedicinske rapporter, også kendt som fejlrapporter, genereres i realtid og består af redigerede kopier af individuelle e -mails, der mislykkedes SPF, DKIM eller begge dele, baseret på hvilken værdi der er angivet i fotagget. Deres format, en udvidelse af misbrugsrapporteringsformat , ligner det med regelmæssige afvisninger, idet de enten indeholder en "besked/rfc822" eller en "tekst/rfc822-overskrift".

Retsmedicinske rapporter indeholder også følgende:

- Kilde til afsendelse af IP -adresse

- Fra e -mail -adresse

- Modtagerens e -mail -adresse

- E -mail -emnelinje

- SPF- og DKIM -godkendelsesresultater

- Modtaget tid

- Overskrifter til e -mail -beskeder, der inkluderer afsenderværten, e -mail -id, DKIM -signatur og andre tilpassede overskriftsoplysninger.

Kompatibilitet

Speditører

Der er flere forskellige former for videresendelse af e -mails , hvoraf nogle kan bryde SPF.

Postlister

Postlister er en hyppig årsag til legitim brud på den originale forfatteres domæne DKIM -signatur, f.eks. Ved at tilføje et præfiks til emneoverskriften. En række løsninger er mulige, og mailingliste -softwarepakker arbejder på løsninger.

Slå alle meddelelsesændringer fra

Denne løsning beholder standardforløbet for mailinglisten og vedtages af flere store mailinglisteoperatører, men udelukker, at listen tilføjer sidefødder og emne -præfikser. Dette kræver en omhyggelig konfiguration af mailingsoftware for at sikre, at signerede overskrifter ikke bliver omorganiseret eller ændret. En forkert konfigureret mailserver kan List-id i sit DKIM med beskeder sendt til en mailingliste, og derefter er listeoperatøren tvunget til at afvise den eller gøre From: rewriting.

From: omskrivning

En af de mest populære og mindst påtrængende løsninger består i at omskrive From:headerfeltet. Den originale forfatteradresse kan derefter tilføjes til Reply-To:feltet. Omskrivning kan variere fra blot tilføjelse .INVALIDtil domænenavnet, til tildeling af et midlertidigt bruger -id, hvor et uigennemsigtigt ID bruges, dette holder brugerens "rigtige" e -mail -adresse privat fra listen. Desuden kan visningsnavnet ændres, så det viser både forfatteren og listen (eller listeoperatoren). Disse eksempler ville resultere i henholdsvis et af: 

From: John Doe <[email protected]>
From: John Doe <[email protected]>
From: John Doe via MailingList <[email protected]>
and
Reply-To: John Doe <[email protected]>

Den sidste linje Reply-To:,, skal designes for at imødekomme svar-til-forfatter-funktionalitet, hvis funktionen svar til liste er omfattet af den foregående ændring i From:overskriftsfeltet. På den måde er den oprindelige betydning af disse felter omvendt.

Det er generelt ikke rimeligt at ændre forfatteren og kan bryde det forventede forhold mellem betydning og udseende af dette datum. Det bryder også automatisk brug af det. Der er fællesskaber, der bruger mailinglister til at koordinere deres arbejde, og implementerer værktøjer, der bruger From:feltet til at tilskrive forfatterskab til vedhæftede filer.

Andre løsninger

Indpakning af meddelelsen fungerer fint for dem, der bruger en e -mail -klient, der forstår indpakket beskeder. Ikke at foretage nogen ændringer er måske den mest oplagte løsning, bortset fra at de ser ud til at være lovligt skyldige i nogle lande, og at rutinemæssigt tab af SPF -godkendelse kan gøre den samlede godkendelse mere skrøbelig.

Afsenderfelt

Hvis du foretager ændringer i From:headerfeltet for at bestå DKIM -tilpasning, kan meddelelsen være ude af overensstemmelse med RFC 5322 afsnit 3.6.2: "Feltet" From: "angiver forfatteren (e) til meddelelsen, det vil sige postkassen (e) af den eller de personer eller systemer, der er ansvarlige for at skrive meddelelsen. " Postkasse refererer til forfatterens e -mail -adresse. Den Sender:overskrift er til rådighed til at indikere, at en e-mail blev sendt på vegne af en anden part, men DMARC kun kontrol politik for Fra domæne og ignorerer afsender domænet.

Både ADSP og DMARC afviser ved hjælp af feltet Afsender på det ikke-tekniske grundlag, at mange brugeragenter ikke viser dette til modtageren.

Historie

Et udkast til DMARC -specifikation er blevet opretholdt siden den 30. januar 2012.

I oktober 2013 blev GNU Mailman 2.1.16 frigivet med muligheder for at håndtere plakater fra et domæne med DMARC -politikken p=reject. Ændringen forsøgte at foregribe de forventede interoperabilitetsproblemer, hvis restriktive politikker blev anvendt på domæner med menneskelige brugere (i modsætning til rent transaktionelle mail -domæner).

I april 2014 ændrede Yahoo sin DMARC -politik til p=reject, hvilket forårsagede fejladfærd i flere mailinglister. Et par dage senere ændrede AOL også sin DMARC -politik til p=reject. Disse tiltag resulterede i en betydelig forstyrrelse, og disse postkasseudbydere er blevet beskyldt for at tvinge omkostningerne ved deres egne sikkerhedsfejl til tredjemand. Fra og med 2020 indeholder FAQ i den officielle DMARC -wiki flere forslag til mailinglister til håndtering af meddelelser fra et domæne med en streng DMARC -politik, hvoraf den mest implementerede er mailinglisten, der ændrer "Fra" -overskriften til en adresse i dens eget domæne.

En IETF -arbejdsgruppe blev dannet i august 2014 for at løse DMARC -spørgsmål, startende fra interoperabilitetsproblemer og muligvis fortsætte med en revideret standardspecifikation og dokumentation. I mellemtiden havde den eksisterende DMARC -specifikation nået frem til en redaktionel tilstand, der er aftalt og implementeret af mange. Det blev udgivet i marts 2015 på Independent Submission-strømmen i kategorien "Informativ" (ikke-standard) som RFC 7489.

I marts 2017 offentliggjorde Federal Trade Commission en undersøgelse af DMARC -brug af virksomheder. Ud af 569 virksomheder fandt undersøgelsen, at omkring en tredjedel implementerede enhver DMARC -konfiguration, færre end 10% brugte DMARC til at instruere servere om at afvise uautentificerede meddelelser, og et flertal havde implementeret SPF.

Bidragydere

Bidragyderne til DMARC -specifikationen omfatter:

Se også

Noter

Referencer

eksterne links