dmarcian's Service Director Tomki Camp werkt al meer dan twee decennia met technologieën voor e-mailverificatie en ondersteunt DMARC implementatie-inspanningen sinds 2012. In dit artikel vertelt hij over inconsistenties in de manier waarop sommige providers feedback geven DMARC, en in sommige gevallen helemaal geen.

DMARC gegevens die door ontvangers worden verstrekt, zijn enorm nuttig om domeineigenaren te helpen bij het begrijpen en oplossen van problemen met domeinverificatie. Er is echter veel werk en kennis op expertniveau nodig om variaties in "gestandaardiseerde" gegevens die door providers worden verzonden, te begrijpen.

Geen twee aanbieders van vergelijkbare diensten zijn hetzelfde en elke mail- of webhostingomgeving heeft zijn eigen kenmerken met voor- en nadelen die bekend zijn bij zijn abonnees. De tools die door deze bedrijven worden aangeboden, worden echter over het algemeen niet beheerst door protocollen die hun gedrag en presentatie definiëren, en er zijn dus enorme verschillen van elkaar.

Het beoogde gebruik van DMARC is vrij goed gedefinieerd, vanuit het perspectief van "hoe te verifiëren of een bepaald bericht het authenticatieprotocol doorstaat", tot "wat moet ik doen met een bericht dat niet werkt DMARC authenticatie, 'en' hoe moet communicatie over DMARC authenticatiestatistieken worden gepresenteerd op het adres dat is opgegeven door de domeineigenaar. "

Helaas zijn er nog een aantal implementatiedetails die sommige providers negeren of verkeerd doen. Dit artikel is geen uitgebreid overzicht van alle bekende problemen en de meeste eindgebruikers (domeineigenaren) herkennen de meeste van deze problemen zelden. Ze worden echter duidelijk wanneer een bedrijf als dmarcian ontvangt elke dag honderdduizenden individuele XML-gegevensbestanden, wat neerkomt op miljarden e-mailberichten voor tienduizenden klanten. Op deze schaal worden probleemtrends duidelijk en zelfs kleine klachten van klanten hebben zorgen geuit. Dit artikel illustreert enkele van de problemen die zich voordoen dmarcian ontmoetingen in de reis om mensen te helpen hun domeinen beter te beschermen.

Google

Het enige probleem met gegevens die deze ESP levert, is eigenlijk niet in het formaat of de kwaliteit van de gegevens die het verzendt; het probleem is dat het niet voldoet aan de DMARC specificatiebeperking voor naar wie de gegevens niet moeten worden verzonden. Als ik bijvoorbeeld een publiceer DMARC record voor tomki.com waarin staat dat rapporten moeten worden verzonden naar support@gmail.com, we kunnen het erover eens zijn dat dit een slechte zaak is en ongepast.

De auteurs van de specificatie hielden rekening met dit probleem en maakten er een vereiste van DMARC dataproviders (elke entiteit die RUA- en / of RUF-gegevens verzendt) moeten een positieve vergoeding voor dergelijke rapporten vaststellen. EEN DMARC record specificeren dat rapporten moeten worden verzonden naar een adres binnen zijn eigen domein is een goed idee - geen verdere controles nodig. Als een DMARC record specificeert een ontvanger binnen een domein * buiten * van dat domein, dan is er een vereiste dat de DMARC rapportgeneratorcontrole voor een speciaal record op het doeldomein - dat record moet bestaan ​​om de positieve vergoeding te bieden.

Het probleem met het niet uitvoeren van deze controle door Google is dat het een hulpmiddel kan zijn bij een Denial of Service-aanval, aangezien er een potentieel is om een ​​e-mailadres te overspoelen met rapporten.

Yahoo

E-mailberichten kunnen meerdere bevatten DKIM handtekeningen. Aangaande met DMARC alleen authenticatie DKIM handtekeningen binnen hetzelfde domein als de From: header domein zijn relevant. Als een bericht van: alice @dmarcian.com is ondertekend met een DKIM sleutel behorende bij tomki.com, en een bij dmarcian.com, dan alleen de dmarcian.com-handtekening en verificatieresultaat zijn relevant.

Yahoo voert de verificatie correct uit; het meldt het echter niet in de DMARC gegevens. De RUA-informatie die Yahoo verstrekt, bevat alleen het resultaat van één DKIM handtekening: de eerste in de kopteksten van e-mailberichten. Dit leidt tot verwarring omdat het erop lijkt dat de gegevens aangeven DMARC passen op basis van irrelevante handtekeningen.

Cisco IronPort ESA

Dit is een bekend systeem dat een aantal ernstige problemen heeft DMARC rapporten, zowel vanuit de gehoste oplossingsomgeving (IPHMX) als aan de zijkant van hardware-installaties in clientomgevingen.

Een probleem is dat domeinen en subdomeinen niet correct zijn samengevoegd voor rapportage. Een domein DMARC record wordt geërfd door elk subdomein dat niet zijn eigen expliciete heeft DMARC record op zijn niveau. Dit betekent dat XML-gegevens met gedetailleerde e-mailtransacties op alle subdomeinen (die niet hun eigen domein hebben) DMARC record) moeten in hetzelfde rapport staan ​​als voor het hoofddomein. Helaas doet de Cisco ESA dit niet, waardoor er dagelijks (mogelijk duizenden) extra XML-bestanden worden gegenereerd.

Een ander, complexer probleem is de timing van de Cisco Email Security Appliance DMARC gegevensgeneratie en de tijd van gegevens in de rapporten. De DMARC specificatie stelt dat dagelijkse gegevens die worden gegenereerd en naar recordadressen worden verzonden, moeten voldoen aan een 24-uursvenster op basis van een UTC-tijdsbestek van middernacht tot middernacht. Met andere woorden, van 00:00 tot 23:59:59 van diezelfde dag in UTC-tijd. Hierdoor kunnen meldingen van e-mailverkeer wereldwijd goed gecoördineerd worden door de domeineigenaar. Het probleem met Cisco ESA is dat er geen mogelijkheid is om uit te lijnen DMARC rapporteert aan UTC-tijd; alle rapportgegevens zijn in tijdsframes die alleen relevant zijn voor de tijd die is ingesteld voor die specifieke ESA-instantie.

Om een ​​voorbeeld verder uit te leggen in een voorbeeld: een frauduleuze campagne misbruikt een e-maildomein van een internationaal bedrijf door 500 berichten te verzenden naar omgevingen in de Verenigde Staten, 200 naar omgevingen in de EU en nog eens 300 naar India. Laten we aannemen dat deze berichten allemaal zijn ontvangen in door Cisco ESA gehoste omgevingen met lokale tijdinstellingen, wat normaal is.

De 200 in de EU ontvangen berichten zullen het meest op UTC-tijd rapporteren.

De 500 berichten die in de VS zijn ontvangen, rapporteren op tijden van -5 tot -8 UTC.

De 300 berichten die in India zijn ontvangen, rapporteren op tijd van +5: 30 UTC.

Het resultaat is dat, hoewel de frauduleuze e-mailcampagne minder dan 10 minuten duurde, volgens berichten van DMARC verslaggevers die niet voldoen aan de vereiste UTC-tijdsbestek, lijkt het erop dat de campagne ongeveer 24 uur besloeg, verdeeld over twee afzonderlijke dagen. De beheerder van het misbruikte domein zou moeilijk kunnen zeggen of de frauduleuze campagne op een of andere dag plaatsvond, of dat deze de hele periode besloeg, op basis van ontvangen rapporten voor het domein.

Ontvangers verzenden onjuiste gegevens

Vaker dan u misschien denkt, zien we DMARC rapporten uit omgevingen waar de gegevensweergave feitelijk onjuist of logisch onjuist is. Bijvoorbeeld wanneer een SPF resultaat is "mislukken" maar de DMARC-SPF het beleidsresultaat is "geslaagd". Per definitie de enige manier waarop a DMARC-policy resultaat kan ooit "pass" zijn als de SPF resultaat is "pass."

Langs deze lijnen zijn er verschillende problemen, van de hierboven getoonde logische fout tot blanco of ontbrekende delen van vereiste gegevens. Om gebruikers te kunnen begeleiden bij hun inspanningen om authenticatie te versterken, dmarcian werkt samen met deze verslaggevers om hun implementatie te verhelpen. In sommige gevallen waar we er niet doorheen komen of een rapportageprobleem niet kan worden opgelost, wordt de gegevensimport uit een bron volledig stopgezet.

Ontvangers die geen gegevens genereren

Een laatste klasse van ontvangbare ontvangers heeft niet te maken met problemen in gegevens of met het genereren van gegevens, maar eerder met het ontbreken daarvan.

DMARC is een openbare standaard (RFC 7489) waar letterlijk miljoenen domeineigenaren van hebben geprofiteerd om de authenticatie voor het e-mailverkeer van hun domeinen te verbeteren. In veel gevallen hebben dezelfde domeineigenaren stappen ondernomen DMARC om beleidsbeperkingen tegen frauduleus gebruik van hun domeinen te publiceren. Deze inspanningen bieden enorme voordelen voor elke omgeving die e-mail ontvangt die beweert afkomstig te zijn van dat domein; een levensvatbare geschiedenis van e-mailverificatie en, nog beter, een gepubliceerd handhavingsbeleid stelt een ontvanger in staat om legitiem e-mailverkeer veel betrouwbaarder te scheiden van frauduleus.

Het werk dat domeineigenaren hebben gestoken in het opzetten en corrigeren van e-mailverificatiestandaarden (SPF, DKIM, DMARC) wordt toegepast op hun e-mailverkeer is enorm afhankelijk van DMARC feedback van ontvangeromgevingen. Bekende grillen terzijde, de feedback van onder meer Google, Yahoo, alle Cisco ESA-omgevingen, Rackspace, Comcast, Mail.ru en anderen is van onschatbare waarde bij deze inspanningen. Hoe meer ontvangers deelnemen, hoe beter e-mail voor iedereen wordt. Sommigen profiteren echter van deze authenticatiestandaarden en bieden authenticatiediensten voor hun eigen omgeving zonder bij te dragen aan het ecosysteem.

De grootste voorbeelden van dit niet-meewerkende gedrag zijn Microsoft Office 365, Proofpoint, MIMECast en Symantec.cloud. Elk van die omgevingen biedt DMARC verificatieservices voor berichten die inkomend naar hun omgeving worden verzonden, maar vervolgens niet worden verzonden DMARC rapporteert aan domeineigenaren. Zonder DMARC rapporten met betrekking tot DMARC authenticatie die beweert te worden gehandhaafd in die omgevingen, kan een domeineigenaar niet eens zeker zijn dat hij verificatie- of handhavingsacties correct uitvoert.

Als u een klant bent van een van deze services, neem dan contact met hen op om hen te vragen DMARC rapporten voor domeinen die erom vragen.

dmarcian streeft ernaar e-mail veiliger te maken door de kennis en het bewustzijn van te vergroten DMARC. Als u hulp nodig hebt met uw DMARC project, laat het ons weten. Als u nog niet met uw DMARC-project bent begonnen, kunt u zich hier.

Wilt u het gesprek voortzetten? Ga naar het dmarcian- forum