video: DMARC - Technisch overzicht

By 7 december 2015E-mail technologie, Video's

We hebben een short samengesteld technisch overzicht van DMARC:

Deze video is onderdeel van een grotere videoserie over alle dingen DMARC.

Het transcript volgt:


Deze korte video is een technisch overzicht van DMARC - Op domein gebaseerde berichtverificatie, rapportage en conformiteit.

DMARC probeert met beide een koppeling te maken tussen de inhoud van een e-mail en een domein SPF or DKIM. Voor de nieuwsgierige kijker, SPF en DKIM worden behandeld in afzonderlijke video's.

De e-mailinhoud die DMARC houdt zich bezig met is het domein gevonden in de Van: header. De kop Van: is vrijwel het enige stuk informatie dat aangeeft wie of waar een e-mail vandaan komt die moet worden opgenomen in wat wordt beschouwd als "goed gevormde e-mail". Vanwege dit, DMARC sluit af van het domein in de kop Van:.

DMARC sluit niet af van een andere koptekst, inclusief de afzender: koptekst. Het blijkt dat het toestaan ​​van meerdere beleidssleutels veel verwarring veroorzaakt en zelfs het nut van kan ondermijnen DMARC zelf, en zo DMARC sluit alleen het domein af dat is gevonden in de kop Van:

SPF en DKIM zijn beide technologieën die stabiele identificaties op domeinniveau produceren. SPF en DKIM zijn vrij beschikbare technische specificaties die een brede implementatie hebben gezien bij veel verschillende e-mailleveranciers. Hoewel ze hun zaken op verschillende manieren doen, DMARC geeft alleen om de resultaten die ze produceren, en als die resultaten iets te maken hebben met het domein in de kop Van:. De resultaten die worden geproduceerd door SPF en DKIM worden in de wereld van DMARC.

Een sleutelbegrip van DMARC is "Identifier Alignment". Dit is gewoon een mooie manier om te zeggen dat de resultaten van SPF en DKIM moeten gerelateerd zijn aan de DMARC domein nuttig te zijn. De belangrijkste reden hiervoor is dat ontvangers een eenvoudige manier nodig hebben om te begrijpen of de resultaten van SPF en DKIM relevant zijn voor het domein dat DMARC sleutels af van.

Tijdens de volgende dia's van deze video lopen we door verschillende combinaties van geverifieerde identificaties met als doel te illustreren waarom identificatie van de id belangrijk is vanuit het perspectief van een e-mailontvanger.

In dit eerste voorbeeld kreeg een e-mailontvanger een stuk e-mail waar de DMARC domein (dit is het domein gevonden in de From: header) is 'bank.com'. Bovendien is de SPF cheque leverde een domein op van "bank.com". Er was geen DKIM handtekening op het stuk e-mail, dus onze rij is gemarkeerd met "geen". De e-mailontvanger zoekt naar een positief signaal dat de e-mail kan worden herleid tot het domein 'bank.com' en de e-mailontvanger maakt het niet uit of dat signaal afkomstig is van SPF or DKIM - zolang het signaal er is. In dit voorbeeld de geverifieerde identificatie die afkomstig is SPF was "bank.com", en dat komt exact overeen met de DMARC domein, en dus voldoet de e-mail aan DMARC.

In dit volgende voorbeeld is alles vrijwel hetzelfde, behalve dat de Authenticated Identifier dat is SPF de opbrengst is een subdomein van bank.com - mail.bank.com. Voor een mens in het vlees zijn de twee domeinen duidelijk verwant. Het blijkt echter dat er op internet geen standaardmanier is om erachter te komen of bank.com een ​​domein van het hoogste niveau is, zoals .com of .org, of dat het een domein van het tweede niveau is. Er is geen standaardmanier om dit uit te zoeken. Een ander voorbeeld is bank.co.uk. Er is geen standaard manier voor machines om te horen dat "co.uk" het domein op het hoogste niveau is. In de wereld van DMARCwordt het domein van het tweede niveau het organisatiedomein genoemd. Door bepaalde bronnen van internet te halen - met name de openbare suffixlijst die wordt beheerd door de Mozilla Foundation - kan een e-mailontvanger ontdekken dat bank.com het organisatiedomein is en dat mail.bank.com een ​​subdomein is dat de hetzelfde organisatiedomein als bank.com. In dit geval voldoet de e-mail aan DMARC.

Dit 3rd-voorbeeld toont iets interessants. In plaats van SPF die een geverifieerde identificatie van bank.com of een subdomein van bank.com oplevert, is de geverifieerde identificatie banknewsletter.com. Voor zover we weten, is banknewsletter.com een ​​echt domein dat eigendom is van en wordt beheerd door dezelfde entiteit die eigenaar is van bank.com. OF…. banknewsletter.com is eigendom van en wordt beheerd door criminelen die mensen willen misleiden om te denken dat ze legitiem zijn. Er is gewoon geen manier om dergelijke associaties tussen domeinen betrouwbaar te onderhouden en te communiceren - hetzij door afzenders zelf databases van associaties te creëren of door ontvangers die hun eigen onderhouden - beide zijn taken die met onnauwkeurigheden beladen zouden kunnen zijn en in feite het nut van DMARC. En dus voldoet deze e-mail NIET aan DMARC en zou worden beïnvloed door een gepubliceerd DMARC het beleid.

Om verder te gaan met het 4ste voorbeeld, is de e-mail hetzelfde, maar nu zien we een DKIM handtekening voor de eerste keer. In dit voorbeeld DKIM heeft een Authenticated Identifier van bank.com opgeleverd, waarmee het voorbeeld voldoet DMARC. Dat wil zeggen dat de e-mailontvanger naar de geverifieerde identificatie kijkt die afkomstig is SPF en ziet dat banknieuwsbrief.com niets te maken heeft met bank.com en het gewoon negeert. Omdat de ontvanger op zoek is naar een positief signaal dat het bericht echt van bank.com en kwam DKIM geeft zo'n signaal, de e-mail passeert de DMARC controleren.

Dit 5ste voorbeeld toont een e-mail dat is DMARC helemaal. Beide SPF en DKIM leverde Authenticated Identifiers van bank.com op. De ontvanger vindt het alleen belangrijk om een ​​positief signaal te vinden, dus het hebben van 2 positieve signalen is dubbel goed, maar betekent niets meer dan "positief signaal". De reden voor het verzenden van e-mail waar beide SPF en DKIM de juiste resultaten opleveren, omdat beide technologieën beschikbaar zijn, zodat e-mail kan blijven bestaan DMARC compliant, zelfs als het een of het ander - om welke reden dan ook - niet beschikbaar is of faalt.

Dit 6e voorbeeld toont hetzelfde met het verschil dat "news.bank.com" de Authenticated Identifier is voor beide SPF en DKIM. Het is vrij gebruikelijk voor grote organisaties om een ​​subdomein te delegeren aan een e-mailserviceprovider zodat de serviceprovider e-mail namens de organisatie kan verzenden. In dit voorbeeld hebben de eigenaren van bank.com mogelijk het subdomein 'nieuws' aan hun marketingverkoper gedelegeerd zodat de verkoper kan sturen DMARC compliant e-mail via bank.com.

Dit gekunstelde voorbeeld laat zien dat iedereen domeinen kan registreren en zetten SPF en DKIM op zijn plaats. Zou het niet mooi zijn als de slechteriken zulke voor de hand liggende domeinen zouden gebruiken? Toch gewoon omdat SPF en DKIM slagen en een geverifieerde identificatie opleveren, betekent niet dat de e-mail goed of gewenst is.

Het laatste voorbeeld hier laat dat zien SPF leverde een geverifieerde identificatie van "bark.com" ... zoals in het geluid dat een hond maakt. Dit is een bekende aanval die sommige fraudeurs gebruiken om mensen te misleiden die handmatig stukjes e-mail inspecteren om de legitimiteit te bepalen. Een snelle blik kan het oog bedriegen en iemand doen denken dat schors echt bank is. Erger nog, het is mogelijk om enkele karaktercoderingstrucs te gebruiken zodat de gerenderde glyphs er precies hetzelfde uitzien als het beoogde domein. Machines worden niet voor de gek gehouden door dit soort tom-foolery, daarom moeten machines Identifier Alignment-controles uitvoeren en geen mensen.

Voordat we ingaan op wat DMARC records eruit zien en wat ze kunnen doen, zullen we kort ingaan op hoe DMARC records worden ontdekt.

Wanneer een e-mailontvanger een stuk e-mail verwerkt in de context van DMARC, haalt de ontvanger het domein uit de kop Van: op. Dit domein vormt de basis van waar de ontvanger naar een overeenkomstige zoekt DMARC record. De ontvanger slaat een underbar-dmarc-voorvoegsel in het domein en vraagt ​​de DNS om een ​​TXT-record.

In het hier getoonde voorbeeld is het geëxtraheerde domein EUROPE.ENG.EXAMPLE.ORG. De ontvanger zou underbar-dmarc aan dit domein toevoegen en de DNS opvragen om te proberen een TXT-record te vinden. Maar wat als de zoekopdracht niets of een TXT-record oplevert waarvan de inhoud niets te maken heeft DMARC. De ontvanger haalt dan het organisatiedomein uit het domein ... in dit geval EXAMPLE.ORG en probeert opnieuw om een DMARC record door under-dmarc voor het domein te slaan en naar een TXT-record te vragen.

Zo DMARC recorddetectie is beperkt tot alleen 2 DNS-lookups. Dit heeft ook enkele handige gevolgen. U kunt een single publiceren DMARC opnemen op het niveau van de organisatiedomein en alle subdomeinen afdekken. Het maakt niet uit of een spammer zijn eigen subdomeinen maakt, u kunt nog steeds een DMARC record dat ze dekt zonder expliciet te hoeven publiceren DMARC records voor alle denkbare subdomeinen. Het andere handige is dat je kunt publiceren DMARC records voor al uw echte subdomeinen en dergelijke DMARC records hebben voorrang op wat op het niveau van de organisatiedomein wordt gepubliceerd.

Oké, nu verder met wat DMARC records eruit zien en wat ze kunnen doen.

DMARC records zijn eenvoudige lijsten met tag / waarde-paren. In dit voorbeeld het domein dat dit heeft gepubliceerd DMARC opnemen ... we kunnen vertellen dat het een DMARC opnemen omdat het begint met "v =DMARC1; ”… publiceert een“ geen ”-beleid en vraagt ​​dat alle op XML gebaseerde geaggregeerde rapporten worden verzonden naar reports@example.org om te verwerken. DMARC is ontworpen om domeinen informatie te laten verzamelen zonder e-mail te beïnvloeden ... en zo is het gedaan - door een te publiceren p=none het beleid.

In termen van wat DMARC records kunnen doen, de opties zijn vrij eenvoudig. Allemaal DMARC records moeten beginnen met een protocolversietag. Hierna kan het beleid worden geconfigureerd, u kunt een beleid configureren dat wordt toegepast op alle subdomeinen…. Als u bijvoorbeeld weet dat uw domein nooit subdomeinen gebruikt, kunt u een s publicerenp=reject beleid, terwijl alleen gegevens over uw organisatiedomein worden verzameld met behulp van p=none. De pct-tag is als een schuifregelaar die van 0 naar 100 gaat, zodat elk gepubliceerd beleid langzaam kan worden uitgerold ... als je zegt pct = 1, dan is alleen 1 van elke 100-e-mails die anders zouden zijn getroffen door een DMARC beleid zal worden beïnvloed.

U kunt ook configureren of de geverifieerde identificatiegegevens al dan niet worden verkregen door SPF en DKIM zijn vereist om exact overeen te komen met DMARC domein. De standaardinstelling "relaxed" heeft in bijna alle gevallen de voorkeur, maar in de "strikte modus" kunt u Identifier Alignment die is gebaseerd op subdomeinen, weigeren, misschien als u zich in een omgeving bevindt waar u geen controle hebt over de verzonden e-mail gedelegeerde subdomeinen gebruiken.

De volgende twee tags, rua en ruf, worden gebruikt om de wereld te vertellen waar rapporten voor het domein naartoe moeten worden gestuurd. Omdat de rapporten anders zijn, sturen mensen de rapporten naar verschillende e-mailadressen voor verzameling en analyse.

De laatste tags hebben betrekking op het configureren van rapportage-indelingen, intervallen en het verzenden van bewerkte kopieën van afzonderlijke e-mails die mislukken DMARC. De eerste twee tags hebben alleen 1-waarde en zijn daarom een ​​beetje nutteloos, en de laatste optie lijkt het genereren van rapporten door sommige rapportaanbieders vanwege softwarefouten uit te schakelen, dus laat ze misschien weg als u deze wilt verzamelen.

Oké, we sluiten dit overzicht af met de verschillende beleidsregels die DMARC maakt en met een korte blik op de 2 verschillende feedbackrapporten mogelijk DMARC biedt.

DMARCDe beleidsopties zijn heel eenvoudig. U kunt een "geen" -beleid publiceren dat alleen maar betekent "stuur me rapporten zonder te handelen op e-mail die niet werkt DMARC controleren". U kunt een "quarantaine" -beleid publiceren dat ontvangers naar spam-e-mails stuurt die niet werken DMARC controleren. Als er geen map met spam bestaat, doet de ontvanger misschien alles wat hij kan om het bericht met een grotere mate van verdenking te behandelen, zoals de agressiviteit van anti-spam scannen verhogen.

Het laatste beleid dat kan worden toegepast, is het beleid "Weigeren", dat ontvangers opdraagt ​​e-mail te blokkeren of te weigeren. DMARC controleren. Op het scherm zie je iets meer over de pct-tag, en als je het gebruikt met een weigeringsbeleid, dan zal welk percentage e-mail dat niet wordt afgewezen vanwege de percentagetag, in plaats daarvan in quarantaine worden geplaatst.

Ten slotte melden de 2-vormen van feedback dat DMARC kunnen bieden zijn heel anders. De op XML gebaseerde verzamelrapporten worden gegenereerd op een 24-uurcyclus en bevatten uitgebreide statistieken over hoe een e-mailontvanger uw domein gebruikt ziet, inclusief alle e-mail die volledig is doorgegeven DMARC. Het 2nd-type feedback bestaat uit bewerkte kopieën van afzonderlijke e-mails die zijn mislukt SPF, DKIM of allebei. Deze rapporten zijn niet altijd beschikbaar vanwege privacyoverwegingen, volumekwesties of de opvatting dat ze niet verplicht zijn om te krijgen DMARC nauwkeurig ingezet.

dmarcian verwerkt beide soorten feedback om te maken DMARC eenvoudig te implementeren. Vragen over DMARC of de dmarcian dienst zal graag worden beantwoord.

Om mee te beginnen met DMARC, bezoek dmarcian.com.

Vragen? neem contact op met support@dmarcian.com
Social? dmarcian is op Linked-in, G +, twitter en misschien meer.
Bedankt voor het kijken!