DMARC-politik tilsidesætter: Forklaret
I denne artikel forklares det i detaljer, hvad DMARC-politikoverskridelser er, hvordan de fungerer, hvad forskellen er mellem en DMARC-politikoverskridelse og en DMARC-politikfejl, og om det er legitimt at overskrive DMARC-poster eller ej.
DMARC-politik tilsidesætter: Forklaret
DMARC-politik tilsidesættelse sker, når den modtagende e-mail-server tilsidesætter den DMARC record, der er indstillet af afsenderen. Dette sker, når afsenderen har angivet, at han ønsker, at hans e-mail skal afvises, hvis den ikke passer til en indgående postservers politik, men den modtagende e-mailserver beslutter, at den ikke passer til sit eget sæt af politikker.
Hvis afsenderen f.eks. har angivet en streng politik (f.eks. "p=reject all mail without SPF or DKIM"), og den modtagende e-mail-server har en afslappet eller løs politik (f.eks. "accept all mail without SPF or DKIM"). I denne situation kan den modtagende server tilsidesætte afsenderens DMARC-politik med sin egen lokale politik og levere meddelelsen til modtagerens indbakke, selv om den ikke opfylder DMARC-kontrollen.
Forståelse af DMARC-politikoverskridelsesmekanismen
DMARC bruges til at kommunikere politikindstillinger, som e-mail-modtagere kan bruge til at håndhæve over for e-mails, der sendes fra dit domæne.
Du kan f.eks. bruge en politik til DMARC til at fortælle modtagerens e-mail-server, hvad den skal gøre (p=afvise eller p=ingen eller p=karantæne), hvis en SPF- eller DKIM-kontrol mislykkes i e-mails, der sendes fra dit domæne.
Dette opsummerer stort set DMARC's styrke, ikke sandt?
Men hvad nu, hvis den modtagende mailserver har sit eget sæt lokale politikker til behandling af modtagne e-mails? Vil den overholde de DMARC-politikker, der er fastsat af afsenderen, ELLER vil den tilsidesætte afsenderens politikker med sine egne lokale politikker?
Tja...
DMARC-specifikationen kræver, at postmodtagere i god tro bestræber sig på at overholde domæneejernes offentliggjorte DMARC-politikker. Så hvis en test af afsenderens SPF-, DKIM- og From-header mislykkes på en meddelelse, bør det udløse det, der er angivet i afsenderens DMARC-politik (p), f.eks. karantæne, afvisning eller INGEN.
Lad os nu antage, at situationen er denne:
➜ Dit domæne (mypersonaldomain.org) har en DMARC-politik (p=none).
➜ Modtagerens e-mail-server (theirdomain.org) afviser alle mails, der ikke opfylder SPF-kontrollen. Det betyder, at hvis en e-mail sendt til (theirdomain.org) ikke består SPF-kontrollen, vil den blive afvist. Ikke sandt?
Men...
Hvad sker der, hvis en e-mail fra dit domæne (mypersonaldomain.org) med DMARC-politik p=none modtages på somedomain.org og ikke består SPF-tjekket?
I dette tilfælde vil det afhænge af den modtagende mailserver (hvordan den er konfigureret) at acceptere den DMARC-politik, der er fastsat af afsenderen, ELLER afvise e-mailen ved at tilsidesætte afsenderens politik med regler, der er defineret i den lokale politik for p=reject ved fejlslagen SPF-kontrol.
Microsoft 365 er et eksempel på dette i realtid, da den sender alle p=afviste e-mails til brugerens junk/spam-mappe i stedet for at afvise dem. Dette skyldes, at O365 mener, at det er fint, at modtageren selv træffer den endelige beslutning om den endelige disposition.
De fem værdier for DMARC-politikoverskridelser
videresendt - E-mailen blev sandsynligvis videresendt, baseret på lokale algoritmer, der identificerer videresendelsesmønstre. Autentificering kan forventes at mislykkes.
local_policy - den lokale politik for postmodtageren undtog e-mailen fra at blive underkastet den handling, som domæneejeren har anmodet om. Når den ønskede politik f.eks. er indstillet til "reject" (afvisning), men ARC-kontrollen er bestået, kan en postmodtager tilsidesætte denne beslutning og vælge ikke at afvise en e-mail.
| Hvad er ARC?
ARC står for Authenticated Received Chain (autentificeret modtaget kæde) (ARC). Med ARC vil DKIM- og SPF-protokollerne for en e-mail ikke længere blive brudt af videresendelser eller postlister. Dette skyldes, at ARC bevarer resultaterne af e-mail-godkendelsen på tværs af routere, mellemled og andre systemer ("hops"), der kan ændre en meddelelse, når den passerer fra en knude på internettet til en anden. Så hvis der var en ARC-kæde til stede, kunne den modtagende mailserver, som ellers ville kassere meddelelserne, vælge at evaluere resultaterne af testen - og gøre en undtagelse, så legitime meddelelser fra disse indirekte poststrømme kan nå frem til deres destinationer. |
mailing_liste - E-mailen blev sendt fra en mailingliste, så filterprogrammet besluttede, at den sandsynligvis ikke var legitim.
sampled_out - Meddelelsen gjaldt ikke for politikken, fordi dens "pct"-indstilling var indstillet i DMARC-posten.
trusted_forwarder - Fejlen blev forudset af beviser, der knyttede e-mailen til en lokalt vedligeholdt liste over betroede videresendelsesadressater.
andre - Nogle politikker indeholdt undtagelser, som ikke var omfattet af de andre punkter på listen.
DMARC-politik tilsidesættelse: Er det tilladt?
I afsnit 6 i RFC 7489 står der, at mailservere skal respektere og behandle meddelelser i overensstemmelse med afsenderens politik. Selv om tilsidesættelser er i strid med ånden i DMARC, forbeholder postkasseleverandører sig ret til at tilsidesætte enhver afsenderpolitik. Så ja, det er tilladt for den modtagende server at tilsidesætte DMARC-politikken med sin lokale politik.
Det betyder, at en e-mail-server stadig kan levere en forfalsket meddelelse, selv om den politik, den skulle følge, sagde noget andet.
Skal du sende rapporter om tilsidesættelse af DMARC-politikker?
DMARC-politikoverskridelser finder for det meste sted, når:
- modtagerens heuristik identificerer en meddelelse, som ikke er blevet godkendt, men som måske er sendt af en autoriseret kilde.
- en postkasseudbyder har en meddelelse, som ikke bestod DMARC på grund af videresendelse af e-mail men de er sikre nok på, at den er legitim, kan de tilsidesætte politikken og levere den alligevel.
Selv om det er tilladt at tilsidesætte DMARC-politikker, fremgår det af afsnit 6 og 7.2 i RFC 7489, at når en modtager vælger at afvige fra domæneejerens offentliggjorte politik, skal modtageren rapportere dette samt begrundelsen for dette (ved hjælp af et samlet feedback-rapportformat) tilbage til domæneejeren.
Hvordan er det tilladt at tilsidesætte DMARC-politikker?
DMARC består af to dele:
DMARC-politik - Denne politik oprettes af den afsendende organisation (på den afsendende organisations offentlige DNS sammen med SPF og DKIM) og definerer, hvordan den modtagende side skal håndtere meddelelser, der ikke overholder dens politikker.
DMARC-verifikation - Den bruges af den modtagende organisation (på den modtagende organisations e-mail-sikkerhedsgateway) og kontrollerer alle meddelelser, der modtages fra en bestemt organisation, for de politikker, der er anført i den pågældende virksomheds DMARC-registreringer. Muligheden for at tilsidesætte en afsenderorganisations DMARC-politikhåndhævelse gælder dog også for modtagerorganisationer.
Oprettelse af en DMARC-politik er en "EN ANMODNING, IKKE EN FORPLIGTELSE": det betyder i bund og grund, at du "anmoder" om mailservere til at angive, hvordan de skal håndtere de e-mails, der sendes fra eller udgiver sig for at være dit domæne.
Modtagere af e-mails er dog ikke forpligtet til at følge et strengt sæt retningslinjer, når de behandler indgående e-mails. De kan udarbejde deres egne politikker for de meddelelser, de accepterer eller afviser, og anvende disse standarder i overensstemmelse hermed.
Hvis modtageren af e-mailen f.eks. anser meddelelsen for at være gyldig. Så hvis en e-mail ikke opfylder DMARC-kontrollen, kan modtageren stadig anvende sin lokale politik og levere den til indbakkerne. Desuden kan e-mail-modtagerens politik tilsidesætte en domæneejers politik.
Hvordan kan en modtagende organisation tilsidesætte min DMARC-politik?
Andre organisationer kan tilsidesætte din DMARC-politikkonfiguration ved hjælp af deres egne DMARC-verificeringsværktøjer og beslutte deres egne politikker for, hvordan de skal reagere på indgående meddelelser. Afhængigt af systemet kan en bruger med administratorrettigheder være i stand til at tilsidesætte alle domæner eller kun visse af dem.
Det skal bemærkes, at DMARC-politikker fastsættes af domæneejeren, og at hver enkelt politik kun gælder for den pågældende organisations domæner. En DMARC-politik kan således ikke påvirke andre organisationers adresser eller deres meddelelser.
DMARC Policy Failure vs. DMARC Policy Overrides: Hvad er forskellen?
DMARC-fejl er, når en mailserver ikke implementerer DMARC korrekt, hvilket fører til, at SPF- og DKIM-verifikationen fejler i modtagerens ende. Manglende mulighed for at verificere din legitimitet kan medføre, at indbakker markerer dig som spam eller afviser dine meddelelser. Her respekterer den modtagende mailserver afsenderens politik og tilsidesætter ikke denne politik med sin egen lokale politik.
DMARC-politikker tilsidesættes, når den modtagende mailserver ikke overholder afsenderens politik. I stedet tilsidesætter den afsenderens DMARC-politik med sin lokale politik. Det betyder, at hvis afsenderens meddelelse har en streng politik med p=reject uden SPF- eller DKIM-verifikation, tilsidesætter den modtagende mailserver politikken og leverer alligevel meddelelsen til indbakken.
Hold styr på DMARC-politikoverskridelser med PowerDMARC
At holde sig ajour med DMARC-politikkerne er en vigtig del af forebyggelsen af spoofing og efterligning af e-mail. De fleste organisationer har dog ikke tid eller ressourcer til at holde styr på deres DMARC-politikoverrides.
Du kan ikke stoppe DMARC-politikoverskridelser, men du kan holde styr på dem med vores DMARC-tjeneste. Vi giver dig komplette rapporter om, hvilke organisationer der tilsidesætter din politiktilstand, og hvilke typer meddelelser fra hvilke og hvilke e-mails der blev tilladt hos modtageren. Dette vil hjælpe afsenderen med at holde styr på det og træffe de nødvendige foranstaltninger, hvis der findes spoofing eller imitation.
Tilmeld dig vores Gratis DMARC-prøveperiode i dag og test det selv!
- Hvad er en phishing-mail? Vær på vagt og undgå at gå i fælden! - 31. maj 2023
- Fix "DKIM none message not signed"- Guide til fejlfinding - 31. maj 2023
- Fix SPF Permerror: Overvind for mange DNS-opslag - 30. maj 2023
