Ik moest heel hard lachen om de DMARC eis. Blijkbaar weet een ambtenaar nog steeds niet hoe het werkt.

Als ze nou gewoon alle ontvangen e-mails zonder SPF+DKIM+DMARC vernietigen blijven alleen gekaapte domein accounts over.

Jammer dat ze dit nog moeten eisen, dit is toch de minimale basis waar iedere organisatie aan zou moeten voldoen.

En jij weet het wel? We zitten te wachten op je uitleg over DKIM zodat we ook slimmer kunnen worden.

Dan mag jij mij gaan uitleggen wat DMARC record precies inhoud. Reageer alleen als je ook daadwerkelijk verstand hebt van mailbeveiliging ;-)

Ik moet nog harder lachen om een betweterige anonieme puber die het niet snapt.

De eis is dat deze federale instanties SPF/DKIM/DMARC implementeren *op hun eigen domein* .
Zodat burgers wat minder makkelijk bang gemaakt kunnen worden met gespoofte mail van "IRS" of "FBI" , omdat hun provider die goed kan filteren.

Als federale overheidsinstantie sommige email van burgers direct weggooien , wat jij voorstelt , is een eerste klas recept voor een heel groot politiek probleem.

Waar je het vandaan haalt dat 'alle' domeinen SPF/DKIM/DMARC hebben (want je stelt dat alles zonder dat gekaapt moet zijn) is al helemaal raar.

Er staat wel een soort onzin in het originele bericht. Dit wordt vooral veroorzaakt doordat men SPF en DKIM in één zin probeert te beschrijven terwijl het toch twee compleet verschillende dingen zijn.

SPF brengt geen watermerk aan in de mail en bij DKIM is het niet de verzender die de policy bepaald hoe met de mail omgegaan moet worden. Maar deze slordigheden komen meer doordat men de uitleg te beknopt probeert weer te geven.

Concreet staat in de directive dat men binnen 90 dagen een DMARC policy van p=none moet hebben en binnen 1 jaar een DMARC policy van p=reject.

Verder zie ik de eis dat de "aggregate reports" van DMARC ook naar het "National Cybersecurity Coordination and Integration Center" gestuurd worden. Dus is er één centrale plek waar all die rapporten verwerkt kunnen worden.

Gegeven een e-mail adres afzender@example.com:

SPF
Met een SPF record dat toegestane IP-adressen vastlegt, gepubliceerd door example.com, kan een ontvangende mailserver, op basis van het "return path" (of "envelop-from") e-mail adres nagaan of de mail vanaf een geautoriseerd IP-adres wordt aangeboden.

Onder meer omdat het "return path" mag afwijken van "body from" in de body van de e-mail, kunnen phishers een domein als gotcha.xyz registreren, daar een SPF record voor publiceren, en in "return-path" opnemen "whatever@gotcha.xyx". SPF blokkeert geen e-mails met (vervalste) afzender "afzender@example.com" in "body from".

DKIM
Aan de header-regels in de envelop van een e-mail kan een server "onderweg" een regel met DKIM signature toevoegen. In die header-regel staat voor welke onderdelen van die mail de signature geldt. In die header-regel staat effectief ook welke server die handtekening heeft gezet.

Omdat DKIM niet verplicht is, kan een spammer of phisher zo'n DKIM header simpelweg weglaten. Ook kan een spammer een heel andere server dan *.example.com zo'n signature laten toevoegen aan een nepmail, schijnbaar verzonden door afzender@example.com - waarmee de mail een geldige DKIM header heeft.

DMARC
DMARC is het eerste protocol dat naar de domeinnaam in "body from" kijkt, dus de afzender die (helaas niet alle) e-mail programma's tonen. Het wordt gebruikt in combinatie met SPF of DKIM.

De koppeling tussen het "mail-body" afzenderdomein en SPF moet ervoor zorgen dat een e-mail van (in een deel van de mail clients getoonde) afzender@example.com verzonden is vanaf een geautoriseerd IP-adres. De koppeling tussen DMARC en DKIM moet ervoor zorgen dat de mail, in elk geval, een DKIM signature gezet door *.example.com moet hebben.

Helaas gaat DMARC lettetlijk uit van "of" in "SPF of DKIM". Voor zover ik weet kun je, met DMARC, niet opgeven dat zowel SPF als DKIM in een mail moeten kloppen. Dus als het een spammer of phisher lukt om vanaf een geautoriseerd IP-adres een mail aan een ontvangende mailserver aan te bieden, hoeft hij geen DKIM signature toe te voegen. En andersom, als het hem lukt om een vervalste DKIM signature (wel namens *.example.com) toe te voegen, kan vanaf elk willekeurig IP-adres worden verzonden - om DMARC te laten "kloppen".

Meer issues
Aangezien een spammer zelf kan bepalen of hij een DKIM header toevoegt of niet (terwijl hij geen invloed heeft op SPF), neig ik ernaar om SPF + DMARC voldoende te vinden. Een probleem met DKIM is bovendien dat sommige mailservers onbedoeld wijzigingen in headers en mails kunnen aanbrengen, waardoor een geldige signature tijdens of na ontvangst niet meer klopt.

Een groot nadeel van SPF is dat het mailforwarding onmogelijk maakt. Dit probleem kan niet door example.com worden opgelost, maar wel door de doorsturende mailserver: deze moet het "return path" aanpassen en zelf de terugweg onthouden voor het geval de mail later niet blijkt te kunnen worden afgeleverd (wat weer allerlei problemen kan opleveren - en daar houden beheerders niet zo van). Dat doorsturen werkt, is dus allesbehalve gegarandeerd. Om die reden zie je veel zendende mailservers bij SPF een ~ (kringeltje) voor "optioneel" in plaats van een - (minteken) voor "verplicht naleven" gebruiken (o.a. gmail doet dat, althans de laatste keer dat ik keek). Met als gevolg dat een ontvangende mailserver een nepmail niet verplicht hoeft te droppen.

Daarnaast kunnen ontvangende mailservers sowieso lekker hun eigen zin doen. Niemand verplicht ze om op SPF, DKIM en/of DMARC te checken en zo ja, gehoor te geven aan de gevraagde configuratie.

Last but not least: hoewel de meeste Amerikaanse staten ".gov" als TLD (Top Level Domain) gebruiken, zijn er ook staten met een ".us" TLD en daar kan een spammer wellicht eenvoudiger een "klinkt-als" domeinnaam voor kopen. Aangezien wij in Nederland geen .gov.nl subdomein kennen, zijn klinkt-als nepdomeinen hier veel eenvoudiger te registreren (zoals belasting-dienst.nl, belastindienst.nl, belasdingdienst.nl, belastingdienst-inbeeld.nl, bdienst.nl, belastingdienst.nl.eu of belastindienst.ni etc). Protocollen als SPF, DKIM, DMARC, DNSSEC helpen geen zier tegen phishing als de ontvanger niet precies weet hoe het afzenderdomein exact gespeld hoort te zijn.

Klopt. Wat ik nog mis in je opsomming, zijn de samengestelde rapporten die DMARC genereert. Deze houden geen spam tegen, maar maakt wel snel inzichtelijk voor de domein eigenaar dat er een spam campagne plaats heeft in zijn naam. Met name als je een verhoging van foute of ontbrekende DKIM registraties ziet, zal er iets mis zijn.
Voor de goede werking moet je er wel voor zorgen dat alle bedrijfsmail ook via de bedrijfsserver verstuurd wordt. Het komt wel eens voor dat mensen op hun telefoon of laptop een andere smtp server instellen.

Ik gebruik DMARC nu zo'n 2 jaar en kijk eigenlijk alleen na een mailing in die rapporten. Mij valt op dat bijna een derde van de mailtjes een SPF error geeft. Dat is dan steeds de geforwarde mail. Forwarding met behoud van originele afzender is blijkbaar populair.


Die optie is er inderdaad niet. Eisen dat beide klopt zal niet kunnen vanwege het toelaten van forwards. DKIM heb ik nog maar 1x fout zien gaan in mijn mailings. Via de rapporten kon ik dan direct zien vanaf welk domein die foutief geforwarde mail verstuurd was. (En even telefonisch contact opgenomen om de precieze oorzaak te traceren)


Maar dan gaat dus de legitiem geforwarde mail de mist is. Het is dus een goede keus om te eisen dat of SPF of DKIM moet kloppen.

Had men niet ook al de verplichting iets met IPv6 en DNSSEC te doen ?

Klopt, maar ik kreeg de laatste tijd veel kritiek over de lengte van mijn bijdragen. Dank voor de aanvulling!

En vermoedelijk daarom zie je SPF vaak wel gebruikt worden maar met een kringeltje. Waardoor spammers headers soms zo manipuleren dat het op een automatisch geforwarde mail lijkt.

Je hebt gelijk! Wel jammer dat je zoveel moeite moet doen met certificaten (een slecht begrepen onderwerp) indien DMARC, zodra SPF klopt, niet meer zeurt over een niet kloppende -of geheel ontbrekende- DKIM signature.

Dat, gekombineerd met de complexiteit en het risico dat mails van/voor jouw gebruikers onterecht worden geblokkeerd, ofwel in spam folders terechtkomen of spoorloos verdwijnen, en dat zelfs de combinatie van SPF+DKIM+DMARC niet helpt tegen typo-squatting, is niet bepaald motiverend om deze functionaliteit in te zetten. Vooral niet als er geen klachten zijn over mails die juist als spam worden behandeld omdat SPF, DKIM en/of DMARC ontbreken van de zendende mailserver.

Erg geloofwaardig is het allemaal ook niet meer. Eerst werd aangeraden om SPF tegen spam in te zetten, maar daar was het aanvankelijk helemaal niet voor bedoeld. Toen werd ook DKIM aangeraden maar ook dat hielp niet. Nu weer DMARC maar ook daar zitten weer haken en ogen aan zoals hierboven beschreven.

En zolang beheerders van ontvangende mailservers zich meer zorgen maken over spam (en daar krachtige spamfilters voor inzetten) dan over afzender-identiteitsfraude, verwacht ik dat SPF, DKIM en DMARC deels werkende lapmiddelen zullen blijven.

SPF helpt goed tegen spam die via botnets verstuurd wordt. Dan heb je al een flink deel te pakken. Dat DKIM tegen spam helpt is een illusie.

DKIM is wel de beste manier om te zien of de afzender inderdaad legitiem is. Het is echter alleen iets dat de mailserver betrouwbaar kan controleren. Als er bij het ophalen van je mail nog iets veranderd, kan hij ten onrechte als fout bestempeld worden. Dat zal de reden zijn dat dit nog niet veel via mail cliënten getoond wordt.

Het grootste probleem is de mens zelf, die niet goed naar de spelling van een domein kijkt en daardoor intrapt op gelijkende namen. Of helemaal niet naar de afzender kijkt. Maar daar helpt geen techniek tegen, behalve dat je mensen moet afleren om überhaupt via linkjes in een mail te reageren.

Het spoofen van een afzender is simpel, toch wordt dit meestal niet gedaan. Waarschijnlijk omdat de bescherming van een domeinnaam via SPF en DMARC toch wel werken bij het tegenhouden.

Alleen als spamfilters een SPF failure met ~ meewegen. Maar dan kan ook automatisch doorgestuurde mail weer als spam worden getagged.

Eens. Maar zo zijn DKIM en Domain Keys destijds wel in de markt gezet.

Zie https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM) voor een DKIM header toegevoegd door een andere server dan het domein in "body from".

Of de mens die niet weet dat een afzenderdomein niet van de kennelijke afzender is. Daarom word ik zo pissig van domeinnamen als "belastingdienst-in-beeld.nl". De praktijk is dat bedrijven en organisaties allerlei verschillende afzenderdomeinen gebruiken, als ontvanger van een e-mail is het dan onmogelijk om nep van echt te onderscheiden.

Voorbeeld uit mijn inbox:
De DKIM plugin in Thunderbird meldt:
En nu?

Nb. van ledenvoordeel.fnv.nl kan ik uitleggen dat dit domein onderdeel is van fnv.nl (kan alleen maar met diens toestemming zijn aangemaakt), van ledenvoordeelfnv.nl kan ik dat niet. Weten dat fnv.nl van de vakbond FNV is, helpt je namelijk geen zier om te weten of ledenvoordeelfnv.nl van FNV is of niet.

Jawel, we moeten met z'n allen e-mail digitaal gaan ondertekenen, en er is een systeem nodig waarmee clients aangeven hoe zeker het is dat de afzender is wie zij zegt dat zij is.

Bijna alle, zo niet alle, spam die ik krijg (ik gebruik opzettelijk geen spamfilter) heeft een vervalst afzenderadres (tenzij het account van de betreffende persoon gehacked is, maar dan houden alle technische maatregelen al snel op).

Bijv. deze gisteren, met malware bijlage:
De apestaart tussen Harley en xs4all heb ik vervangen door een underscore, en uit xs4all.nl heb ik .nl verwijderd. Het zou mij zeer verbazen als dat e-mail adres niet bestaat (maar het is natuurlijk niet de afzender).

Het IP-adres 46.225.194.57 bevindt zich in Iran, daar staan -bij mijn weten- geen mail servers van xs4all. Bovendien maakt dat IP-adres, volgens https://www.abuseat.org/lookup.cgi, onderdeel uit van het necurs botnet (waar ik veel spam van krijg) en is daarom geblacklist.

Dat is weer voor de expert die moet beoordelen of tripolis.com een goede afzender is. (En dat zijn ze). Bij die thunderbird plugin kun je in de settings aangeven dat je in toekomst "td35.tripolis.com" als een betrouwbare ondertekenaar van "ledenvoordeelfnv.nl" accepteert. Ik vraag me wel af hoeveel mensen zo diep in de settings duiken.

Ziggo doet het sinds twee jaar wel beter. Hun mailtjes worden door "mailplus.nl" ondertekent, maar daarnaast komt ook nog hun eigen DKIM ondertekening met "ziggo.nl". De thunderbird plugin laat hier steekjes vallen omdat hij alleen de eerste de beste toont en niet alle DKIM ondertekeningen.


Wat betreft de <Harley_xs4all>.
xs4all heeft wel een SFP policy, maar vreemd genoeg nog geen MARC policy.


Vooral het ontbreken van DMARC verbaast me eigenlijk omdat ze wel DMARC kontroleren en mij ook regelmatig een raport sturen van mijn mail naar een xs4all adres.

Zelfs Ziggo publiceert een DMARC record.

Maar met een SFP policy die alleen ~all eist, is zo'n xs4all naam nog steeds simpel te spoofen. Als ze de policy op "-all" zouden zetten was de bescherming beter, maar krijgen diverse klanten van hen problemen met forwards. Ik zou zeggen een probleem van de klant. Moeten ze maar forwarden met een nieuwe afzender en niet doen als of de forward een origineel bericht is.

Ja.

Overigens geldt in ons eigen land iets soortgelijks voor overheden. Zij zijn gehouden aan de pas-toe-of-leg-uit lijst, waar alle hier genoemde standaarden op staan:

https://www.forumstandaardisatie.nl/lijst-open-standaarden/in_lijst/verplicht-pas-toe-leg-uit

Verder is er een mooie site, waar je snel kunt testen of een domeinnaam aan de genoemde standaarden (IPv6, DNSSEC, TLS, DKIM, DMARC, SPF) voldoet:

https://internet.nl/

Er is trouwens ook een nieuwe standaard in ontwikkeling: ARC, dat een aantal tekortkomingen van DMARC/SPF/DKIM beoogt op te lossen. Gmail werkt er al mee (kijk maar eens in de mailheaders).

http://arc-spec.org/

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol