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 videoreeks over alle dingen DMARC.

Het transcript volgt:


Deze korte video is een technisch overzicht van DMARC: domeingebaseerde berichtverificatie, rapportage en conformiteit.

DMARC probeert een koppeling tot stand te brengen tussen de inhoud van een e-mail en een domein met behulp van SPF of DKIM. Voor de nieuwsgierige kijker worden SPF en DKIM behandeld in afzonderlijke video's.

De e-mailinhoud waar DMARC mee bezig is, is het domein dat wordt gevonden in de kop Van :. De From: header is vrijwel het enige brok informatie dat aangeeft wie of waar een e-mail vandaan komt die moet worden opgenomen in wat wordt beschouwd als "goed gevormde e-mail". Daarom worden de sleutels van het domein gevonden in de kop van: DMARC.

DMARC speelt geen sleutel af van een andere header, inclusief de header Sender:. Het blijkt dat het toestaan ​​van meerdere beleidssleutels veel verwarring veroorzaakt en mogelijk zelfs het nut van DMARC zelf ondermijnt, en zo worden alleen DMARC-sleutels verwijderd van het domein dat is gevonden in de kop Van :.

SPF en DKIM zijn beide technologieën die stabiele domeinnamen op domeinniveau produceren. SPF en DKIM zijn gratis beschikbare technische specificaties die bij veel verschillende e-mailproviders breed zijn geïmplementeerd. Hoewel ze op verschillende manieren met hun bedrijf bezig zijn, geeft DMARC alleen maar om de resultaten die ze produceren en of die resultaten iets te maken hebben met het domein dat in de kop From staat. De resultaten die worden geproduceerd door SPF en DKIM worden 'geverifieerde identificaties' genoemd in de wereld van DMARC.

Een belangrijk concept van DMARC is "Identifier Alignment". Dit is gewoon een mooie manier om te zeggen dat de resultaten van SPF en DKIM relevant moeten zijn voor het DMARC-domein. 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 waartoe de DMARC-sleutels behoren.

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 e-mail waarin het DMARC-domein (het domein dat is gevonden in de kop Van:) 'bank.com' is. Bovendien leverde de SPF-controle een domein op van "bank.com". Er was geen DKIM-handtekening op het stuk e-mail, dus onze rij is gemarkeerd met "none". De e-mailontvanger is op zoek naar een positief signaal dat de e-mail terug te voeren is naar het "bank.com" -domein, en het maakt de e-mailontvanger niet uit als dat signaal afkomstig is van SPF of DKIM - net zo lang als het signaal daar is . In dit voorbeeld was de geverifieerde ID die afkomstig was van SPF "bank.com" en die komt exact overeen met het DMARC-domein en dus voldoet de e-mail aan DMARC.

In dit volgende voorbeeld is alles vrijwel hetzelfde, behalve dat de geverifieerde identificatie die SPF heeft opgeleverd een subdomein is van bank.com - mail.bank.com. Voor een mens in het vlees zijn de twee domeinen natuurlijk verwant. Het blijkt echter dat er geen standaardmanier op internet is om erachter te komen of bank.com een ​​topdomein is zoals .com of .org of een domein op het tweede niveau. Er is geen standaardmanier om dit te achterhalen. Een ander voorbeeld is bank.co.uk. Er is geen vaste manier om machines te laten weten dat "co.uk" het topniveaudomein is. In de wereld van DMARC wordt het domein dat een domein op het tweede niveau is, het organisatiedomein genoemd. Door bepaalde bronnen van internet in te trekken - met name de openbare achtervoegselijst die wordt beheerd door de Mozilla Foundation - kan een e-mailontvanger erachter komen 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 dat SPF een geverifieerde identificatie van bank.com of een subdomein van bank.com oplevert, is de geverifieerde identificatie banknewsletter.com. Voor zover wij weten, is banknewsletter.com een ​​echt domein in eigendom 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 laten denken dat ze legitiem zijn. Er is eenvoudigweg geen manier om dergelijke associaties tussen domeinen betrouwbaar te onderhouden en communiceren - hetzij door afzenders zelf die databases van associaties maken of door ontvangers die hun eigen domein onderhouden - beide zijn taken die vol zitten met onnauwkeurigheden en in wezen het nut van DMARC ondermijnen. Deze e-mail voldoet dus NIET aan DMARC en wordt beïnvloed door een gepubliceerd DMARC-beleid.

Om verder te gaan met het 4th-voorbeeld, is de e-mail hetzelfde, behalve dat we nu voor de eerste keer een DKIM-handtekening zien. In dit voorbeeld heeft DKIM een geverifieerde identificatie van bank.com opgeleverd, waardoor het voorbeeld voldoet aan DMARC. Dat wil zeggen, de e-mailontvanger kijkt naar de geverifieerde identificatie die afkomstig was van SPF en ziet dat banknewsletter.com niets met bank.com te maken heeft en negeert het gewoon. Aangezien de ontvanger op zoek is naar een positief signaal dat het bericht echt afkomstig is van bank.com en DKIM een dergelijk signaal afgeeft, wordt de e-mail doorgegeven aan de DMARC-controle.

Dit 5th-voorbeeld toont een e-mail die helemaal DMARC is. Zowel SPF als DKIM hebben geverifieerde id's van bank.com opgeleverd. De ontvanger geeft alleen om het vinden van een positief signaal, dus het hebben van 2-positieve signalen is dubbel goed, maar betekent niet meer dan "positief signaal". De reden voor het verzenden van e-mail waarbij zowel SPF als DKIM de juiste resultaten opleveren, is omdat beide e-mailtechnologieën het mogelijk maken dat e-mail DMARC-compatibel blijft, zelfs als de ene of de andere - om welke reden dan ook - niet beschikbaar is of faalt.

Dit 6th-voorbeeld toont hetzelfde met het verschil dat "news.bank.com" de geverifieerde identificator is voor zowel SPF als DKIM. Het is vrij gebruikelijk voor grote organisaties om een ​​subdomein naar een e-mailserviceprovider te delegeren, zodat de serviceprovider namens de organisatie e-mail kan verzenden. In dit voorbeeld kunnen de eigenaren van bank.com het subdomein van "nieuws" hebben gedelegeerd aan hun marketingleverancier, zodat de leverancier DMARC-compatibele e-mail kan verzenden met behulp van bank.com.

Dit gekunstelde voorbeeld laat zien dat iedereen domeinen kan registreren en SPF en DKIM kan plaatsen. Zou het niet aardig zijn als de slechteriken zulke voor de hand liggende domeinen gebruikten? Toch, alleen omdat SPF en DKIM slagen en een geverifieerde identificatie opleveren, betekent niet dat de e-mail goed of gezocht is.

Het laatste voorbeeld hier laat zien dat SPF een geverifieerde identificatie van "bark.com" opleverde ... zoals in het geluid dat een hond maakt. Dit is een bekende aanval die sommige fraudeurs gebruiken om mensen te misleiden die stukjes e-mail handmatig controleren om legitimiteit te bepalen. Een snelle blik bedriegt het oog en laat iemand denken dat schors echt bank is. Erger nog, het is mogelijk om een ​​aantal tekencoderingstricks te gebruiken, zodat de gerenderde glyphs er precies zo uitzien als het bedoelde domein. Machines laten zich niet misleiden door dit soort dwaasheden. Daarom moeten machines controles uitvoeren op Identifier Alignment, en niet op mensen.

Voordat we ingaan op hoe DMARC-records er uitzien en wat ze kunnen doen, zullen we kort bespreken hoe DMARC-records worden ontdekt.

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

In het hier getoonde voorbeeld is het geëxtraheerde domein EUROPE.NL.EXAMPLE.ORG. De ontvanger zou onderbar-dmarc aan dit domein toevoegen en de DNS vragen om een ​​TXT-record te zoeken. Maar wat als de vraag niets oplevert of een TXT-record waarvan de inhoud niets met DMARC te maken had? De ontvanger extraheert dan het organisatiedomein uit het domein ... in dit geval EXAMPLE.ORG en probeert opnieuw een DMARC-record te vinden door under-dmarc voor het domein te meppen en naar een TXT-record te zoeken.

Op deze manier is detectie van DMARC-records beperkt tot alleen 2 DNS-zoekopdrachten. Er zijn ook een aantal handige vertakkingen als gevolg hiervan. U kunt een enkele DMARC-record publiceren op het niveau van het organisatiedomein en ervoor zorgen dat deze alle en alle subdomeinen beslaat. Het maakt niet uit of een spammer zijn eigen subdomeinen vormt, u kunt nog steeds een DMARC-record publiceren die deze dekt, zonder dat u expliciete DMARC-records voor alle denkbare subdomeinen hoeft te publiceren. Het andere handige is dat u DMARC-records voor al uw echte subdomeinen kunt publiceren en dat die DMARC-records prevaleren boven wat wordt gepubliceerd op het niveau van het organisatiedomein.

Goed, nu verder naar hoe DMARC-records er uitzien en wat ze kunnen doen.

DMARC-records zijn eenvoudige lijsten met tag- / waardeparen. In dit voorbeeld, het domein dat deze DMARC-record publiceerde ... kunnen we zien dat het een DMARC-record is omdat het begint met "v = DMARC1;" ... een "none" -beleid publiceert en vraagt ​​om alle XML-gebaseerde verzamelrapporten te verzenden naar reports@example.org om te verwerken. DMARC is ontworpen om domeinen toe te staan ​​informatie te verzamelen zonder e-mail te beïnvloeden ... en zo is het gedaan - door ap te publiceren = geen beleid.

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

U kunt ook configureren of de geverifieerde ID's die zijn opgegeven door SPF en DKIM, exact overeenkomen met het DMARC-domein. De standaardinstelling "ontspannen" heeft in bijna alle gevallen de voorkeur, maar in de "strikte modus" kunt u de afstelling van de id niet toestaan ​​die is gebaseerd op subdomeinen, bijvoorbeeld als u zich in een omgeving bevindt waar u geen controle hebt over de e-mail die wordt verzonden gebruik van gedelegeerde subdomeinen.

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 houden zich bezig met het configureren van rapportage-indelingen, intervallen en wanneer een geredigeerde kopie van afzonderlijke e-mails die niet voldoen aan DMARC moet worden verzonden. De eerste twee tags hebben alleen de waarde 1 en zijn daarom een ​​beetje nutteloos, en de laatste optie lijkt het genereren van rapporten door sommige rapportproviders te blokkeren vanwege softwarefouten, dus laat ze misschien weg als u deze wilt verzamelen.

Oke, we zullen dit overzicht afmaken met de verschillende beleidsregels die DMARC toestaat en met een korte blik op de verschillende feedbackrapporten van 2 die DMARC biedt.

DMARC's beleidsopties zijn heel eenvoudig. U kunt een "geen" beleid publiceren dat alleen maar betekent "stuur mij alstublieft rapporten zonder op e-mail te reageren die de DMARC-controle niet doorstaat". U kunt een "quarantainebeleid" publiceren dat ontvangers naar de spammap stuurt, elke e-mail die niet voldoet aan de DMARC-controle. Als een spammap niet bestaat, zou de ontvanger er alles aan kunnen doen om het bericht met een hogere mate van verdenking te behandelen, zoals het verhogen van de agressiviteit van het scannen van anti-spam.

Het laatste beleid dat kan worden toegepast, is het "reject" -beleid, dat ontvangers aanbeveelt om e-mail die de DMARC-controle niet toelaat te blokkeren of niet te accepteren. Op het scherm zie je iets meer over de pct-tag, en hoe als je deze gebruikt met je hebt een afkeurbeleid hebt ingevoerd, dan zal welk percentage van de e-mail dat niet wordt afgewezen vanwege de percentagetag in plaats daarvan in quarantaine worden geplaatst.

Het laatste, de 2-vormen van feedbackrapporten die DMARC kan bieden, zijn heel verschillend. De op XML gebaseerde verzamelrapporten worden gegenereerd in een 24-uurcyclus en bevatten uitgebreide statistieken over hoe een e-mailontvanger uw domein ziet worden gebruikt - inclusief alle e-mails die volledig zijn overgenomen door DMARC. De 2nd-soort feedback bestaat uit geredigeerde exemplaren van afzonderlijke e-mails die SPF, DKIM of beide hebben overgeslagen. Deze rapporten zijn niet altijd beschikbaar vanwege privacyproblemen, problemen met het volume of de opvatting dat ze DMARC niet correct hoeven in te zetten.

dmarcian verwerkt beide soorten feedback om DMARC eenvoudig te implementeren. Vragen over DMARC of de dmarcian-service zullen graag worden beantwoord.

Ga naar dmarcian.com om aan de slag te gaan met DMARC.

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