Beantwoord

Mail van een of enkele afzenders komt niet aan. DMARC protocol?

  • 25 januari 2019
  • 36 Reacties
  • 4122x Bekeken


Toon eerste bericht

36 Reacties

Reputatie 2
Als ik eraan toe kom sla ik de RFC's er op na vwb de relay functie. Tot die tijd ga ik er van uit dat je gelijk hebt 🙂 Ik zou het zeker niet zo inrichten, juist omdat je dan de teugels moet laten vieren op dkim en spf.

Het mooie is juist dat als je via Ziggo een mail verstuurd als jan@bedrijf-x.com dat dan de SPF, DKIM en DMARC instellingen van bedrijf-x.com gelden en niet die van Ziggo.
Het is heel normaal voor een mail server om een mail te krijgen van een ander adres en die door te sturen en dat is eigenlijk wat hier ook gebeurt.

Als je via provider x een mail verstuurd als piet@ziggo.nl dan gelden de Ziggo SPF, DMARC en DKIM. SPF is dan fail omdat je niet een Ziggo mail server gebruikt (IP-address). DKIM is fail omdat provider x die niet voor Ziggo kan maken zonder de private key van Ziggo. DMARC is fail omdat zowel SPF en DKIM fail zijn. Nu hangt het af van de mail server van de ontvanger of daar iets mee wordt gedaan. Als dat een goed ingerichte mailserver is dan zal die de mail weigeren. Dit is precies wat Ziggo wil bereiken met al die controles.

Omgekeerd, als je als jan@bedrijf-x.com een mail verstuurd via een ziggo mail server dan gelden de bedrijf-x.com SPF, DKIM en DMARC (als bedrijf-x die heeft ingesteld.) Het is mogelijk dat bedrijf-x die niet heeft of dat DMARC p=none is ingesteld. Dat betekent dat de ontvangende mail server kan besluiten om de mail toch door te laten of misschien in de spam folder te zetten. Ziggo heeft hier verder geen invloed op.
Reputatie 6
Badge +4
en als je wilt weten hoe het met je dkim,spf,dmarc en meer dingen is gesteld, stuur een mail naar check-auth@verifier.port25.com , dan krijg je een automatisch gegenereerde mail terug met info hoe je mail is ingesteld en door de verschillende controles gaat.

Heeft mij vaak kunnen helpen in ons bedrijf qua start analyse bij authenticatieproblemen.
Reputatie 2
en als je wilt weten hoe het met je dkim,spf,dmarc en meer dingen is gesteld, stuur een mail naar check-auth@verifier.port25.com , dan krijg je een automatisch gegenereerde mail terug met info hoe je mail is ingesteld en door de verschillende controles gaat.

Goeie tip!

Ik heb de test gedaan met een email zonder body tekst die nu bij een forward faalt op de DKIM test.
Het blijkt dat de originele email ook al faalt bij check-auth@verifier.port25.com.
De body hash is invalid. Nu zie je dat de body bestaat uit een CR LF. Alle mail records horen te worden afgesloten met CR LF en de vraag is nu of Ziggo een DKIM hash heeft uitgerekend met of zonder CR LF en of de controle daar rekening mee houdt.

Zoals het nu is geeft een lege body dus altijd een DKIM fail. (Actie voor Ziggo?)

Nog niet getest - wat gebeurt er bij sommige langere teksten waar ook de DKIM bij de ontvanger failed. Zou het kunnen zijn dat lange regels (meer dan 1000 characters) onderweg worden afgebroken en daarmee de DKIM fout gaat?
Reputatie 6
Badge +4
Ik had voor mezelf al geconstateerd dat er enkele inconsistenties in het beleid en uitvoering zitten van Ziggo en Dkim, maar ook bij kpn en b.v. planet.nl. Die zag/zie ik hier regelmatig in onze dkim/dmarc quarantaine vliegen.

Het blijft - zeker met een grote hoeveelheid domeinnamen en mailservers - blijkbaar een lastige materie om goed te krijgen en te houden.

Oja, zojuist ook even via de check-auth een mail vanaf werk gestuurd zonder subject of body, dit is wat je dan terug wilt krijgen😉

The Port25 Solutions, Inc. team

==========================================================
Summary of Results
==========================================================
SPF check: pass
"iprev" check: pass
DKIM check: pass
SpamAssassin check: ham

==========================================================
Reputatie 2
Zoals ik eerder heb aangegeven wordt een email met een "lege" body die ik verzend via Ziggo voorzien van een ongeldige DKIM handtekening.
Simpele test opzet - verzend een mail zonder body tekst van een Ziggo email adres naar een (ander) Ziggo email adres. De mail komt aan omdat de SFP check ok is. In de ontvangen mail header zie je:
code:
Authentication-Results: mail.iss.as9143.net;
spf=pass (212.54.34.167;quicknet.nl);
dkim=fail header.d=quicknet.nl (signature verification failed);
dmarc=pass header.from=quicknet.nl (p=reject sp=reject dis=pass);


Kijk je naar de ontvangen email dan valt op dat de body tekst bestaat uit drie CR LF's. Waarschijnlijk zet mijn mail programma (Thunderbird) die er in als er geen body tekst wordt ingetikt. Dat is geverifieerd door een mail zonder body te sturen via een niet Ziggo adres.

code:
RFC 6376 3.4.3 The "simple" Body Canonicalization Algorithm

Volgens de RFC moet de DKIM signing en controle bij ontvangst alle lege regels aan het eind van een body weglaten op één CR LF na bij de berekening van de body hash. Een helemaal lege body moet worden gezien als één CR LF.

Er zit dus een probleem in de Ziggo DKIM signing of controle. Waar dat zit kunnen we nagaan door de test mail vanaf Ziggo naar een Microsoft mail adres te sturen. In de headers van de ontvangen email staat:
Authentication-Results: spf=pass (sender IP is 212.54.34.166) smtp.mailfrom=quicknet.nl; hotmail.com; dkim=fail (body hash did not verify) header.d=quicknet.nl;hotmail.com; dmarc=pass action=none

Dat bewijst dus dat de fout zit in het aanmaken van het DKIM record en met name in de body hash van de "lege" body.


@Ziggo - werk aan de winkel 🙂
Reputatie 2
Zo te zien heeft Ziggo gereageerd op de probleem melding hierboven (lege body tekst). ☺

De mail wordt nu ondertekent (DKIM) met c=relaxed/relaxed (in plaats van c=simple/simple.)
Dat betekent dat de body tekst en de headers extra worden genormaliseerd voordat de DKIM wordt uitgerekend. Dat heeft vooral invloed op dubbele spaties en blanco regels. Het is eigenlijk een afspraak hoe precies om te gaan met de body tekst en headers die ook door de ontvangende mail server zo worden uitgevoerd. (dit heet met een moeilijk woord "canonicalization").
De mail zelf wordt niet aangepast, alleen wordt er anders gewerkt met de delen die worden gebruikt voor het aanmaken en het controleren van de DKIM handtekening.

Wat maakt het verder uit? Een email zou onderweg kunnen worden aangepast. Dat kan zijn expres door een smiegt maar ook onbedoeld door een mail server onderweg. Met "simple" is een wijziging van één spatie al genoeg om de verificatie te laten falen. Bij "relaxed" merk je een spatie meer of minder niet en dat zal met name goed kunnen uitpakken als dat onbewust gebeurt in een mail server onderweg.

Mijn test met een "lege" body tekst komt nu goed over waar die tot gisteren nog fout ging met een ongeldige DKIM handtekening. Ik vermoed dat Ziggo nog steeds een probleem heeft met een "simple" ondertekening als er een extra CR LF in de verder lege body tekst staat en dat is een fout volgens de DKIM RFC. De actie om over te stappen naar "relaxed" is echter prima want die kan mogelijk ook problemen oplossen met ongeldige DKIM handtekeningen bij sommige langere teksten. (Ik heb die langs zien komen maar ben niet geslaagd om ze te reproduceren voor een test. Even afwachten dus of we die nog tegen gaan komen.)
Reputatie 2
Badge
Ik snap niet alle technische details, maar ik begrijp wel dat Ziggo configuraties aan het wijzigen is in zijn mailservers en dat hierbij foutjes worden gemaakt of dat er voor klanten onvoorziene effecten ontstaan. Hoe werkt zoiets nou bij grote providers? Hebben die een otap omgeving, of doet Ziggo alleen aan ontwikkel en zijn test acceptatie en productie omgeving gewoon het reguliere systeem en detecteren de deskundigen in de community de bugs en problemen. Mijns inziens zou ziggo @kb1 eigenlijk moeten betalen als testengineer in plaats van gratis mee te surfen op zijn deskundigheid via de community en had dit probleem aan het licht moeten komen in een test of acceptatie omgeving.
Ben wel benieuwd naar de meningen hierover. Is deze werkwijze van Ziggo "normaal" of "niet echt netjes", of sla ik de plank volledig mis?
Reputatie 2
Ik snap niet alle technische details, maar ik begrijp wel dat Ziggo configuraties aan het wijzigen is in zijn mailservers en dat hierbij foutjes worden gemaakt of dat er voor klanten onvoorziene effecten ontstaan. Hoe werkt zoiets nou bij grote providers? Hebben die een otap omgeving, of doet Ziggo alleen aan ontwikkel en zijn test acceptatie en productie omgeving gewoon het reguliere systeem en detecteren de deskundigen in de community de bugs en problemen. Mijns inziens zou ziggo @kb1 eigenlijk moeten betalen als testengineer in plaats van gratis mee te surfen op zijn deskundigheid via de community en had dit probleem aan het licht moeten komen in een test of acceptatie omgeving.
Ben wel benieuwd naar de meningen hierover. Is deze werkwijze van Ziggo "normaal" of "niet echt netjes", of sla ik de plank volledig mis?


Ik neem aan dat Ziggo een test en acceptatie omgeving heeft. Je kunt echter niet alles in zo'n test/acceptatie omgeving controleren. De DKIM, SPF en DMARC records moeten in de DNS van het domein worden geplaatst van bijvoorbeeld quicknet.nl en dat kun je niet testen maar het is direct geldig. Je zou dat kunnen testen met een alternatief domein, iets van "ziggo-test.nl" maar dan kom je dus niet alle variaties tegen die de miljoenen klanten aan maken.

Voor SPF , DKIM en DMARC heb je daarom een soort droogzwem instelling waarbij alles wordt meegestuurd maar waarbij je tegen de ontvangende mail server zegt - ik ben nog aan het uitproberen, laat deze mail maar gewoon door. Tijdens het droogzwemmen krijgt Ziggo rapportages van aantallen wel en niet goed ontvangen emails. Als daar een groot deel van fout gaat moet je dat eerst uitzoeken. Als er echter maar een paar procent fout overblijft en je weet dat je ondanks alle goede bedoelingen het nooit helemaal waterdicht krijgt dan kun je besluiten om de schakelaar om te zetten en te gaan voor echt. Dat heeft Ziggo ook allemaal gedaan en nu ze in productie zijn komen ze nog dingen tegen die in de droogzwem periode niet zijn opgevallen.

Dat lijken ze nu wel goed op te pakken, hoewel je als gebruiker bij de helpdesk geen gehoor krijgt.

SPF, DKIM en DMARC gebruiken is een goed idee maar je kunt het nooit 100% waterdicht maken. Dat kan Ziggo niet maar ook andere providers niet en dat heeft te maken met de beperkingen van het concept. Zoals ik eerder aangaf is het voor ons als klant belangrijker als onze mails goed aankomen. Voor de bijvoorbeeld de rijksoverheid is het aspect dat je niet ten onrechte namens hun kunt mailen belangrijker. Dat moet je meenemen in de keuzes die je maakt in de instellingen van SPF, DKIM, DMARC.

Wat betreft mij betalen als testengineer - dat lijkt mij een goed idee. Ik heb hier de afgelopen week aardig wat uurtjes ingestoken en het zou wel fijn zijn om hier wat waardering voor terug te krijgen. Mijn bankrekening nummer is bij Ziggo bekend... 😉
Reputatie 2
Sinds Ziggo de DKIM policy op relaxed heeft gezet heb ik minder last van bounces maar ze komen toch nog voor.
Het gaat met name fout bij mails die door een andere mail server worden geforward naar een Ziggo adres. De oorspronkelijke verzendende mail server (in dit geval ook Ziggo maar het kan ook met andere mail servers gebeuren) zet een DKIM handtekening in de verzonden email en bewaakt daarmee wijzigingen in de email tekst en in een aantal geselecteerde mail header velden.
Bij aankomst in de Ziggo mail server wordt gecontroleerd of de mail van een geautoriseerde mail server afkomstig is met behulp van SPF. Bij een geforwarde mail zal die controle falen omdat de mail nu opnieuw door een andere server wordt verzonden.
De DKIM check zou echter nog steeds moeten werken, tenzij de email onderweg is gewijzigd.
Het blijkt dat de mail server die de forward doet inderdaad iets aan een mail header wijzigt.
Een (TO) mail adres in de vorm: 'piet puk' wordt gewijzigd in "'piet puk'" .
Het gaat dus fout als de "display name" van het mail adres oorspronkelijk binnen enkele aanhalingstekens staat. De forwarding mail server zet hier dubbele aanhalingstekens omheen en daarmee is het header veld gewijzigd en faalt de DKIM check.
De ontvangende Ziggo mail server besluit daarom volgens de DMARC policy om de mail te weigeren. Om te slagen voor DMARC moet SPF of DKIM slagen.

Wat kun je daar aan doen?
  1. Haal de enkele aanhalingstekens rond de display naam weg voordat je de mail verzendt. Daar heb je echter geen controle over als je de mail niet zelf verstuurd.
  2. Klaag bij de eigenaar van de mail server die de forward doet. Dat staat in mijn geval nu open en ik ben benieuwd...

Alleen daarmee ontneem je argeloze gebruikers ook de kans om met email adressen met als afzender quicknet mail te verzenden via een andere smtp server dan die van ziggo.Neuh, da's niet goed. Je FROM adres moet je FROM adres zijn. Dus horen bij het domein van de mailserver die je gebruikt om je mail te versturen.
Dus Stel, onze argeloze gebruiker "piet.puk@quicknet.nl" wil graag dat je antwoord stuurt aan "pukpiet@gmail.com"
En als hij dan zijn from herschrijft naar pukpiet@gmail.com en verstuurt het bericht via z'n quicknet server, dan is hij simpelweg niet argeloos, maar doet iets wat niet mag. Geen enkele mail host (behalve open relay hosts) zal dit accepteren.

De juiste wijze voor onze Piet is dat hij het bericht verstuurt aan zijn quicknet server met
FROM:piet.puk@quicknet.nl
REPLY TO: pukpiet@gmail.com
...alleen zo gaat het lukken.

Groet van Hoot


Ik schreef ook niet dat het zou moeten kunnen. Ik schreef over argeloze gebruikers. En daarmee bedoel ik gewone gebruikers die geen idee hebben waar dit allemaal over gaat, en ooit bv de Gmail smtp (wellicht per ongeluk) hebben ingesteld, voor hun ziggo adres.

Ik juich de veranderingen die we zien toe, maar vind dat Ziggo zijn gebruikers er wel actief op moet wijzen dat ze met dit soort zaken bezig zijn, en dat dit consequenties kan hebben voor je instellingen in je mailprogramma. Andersom geldt dit ook. In het verleden werd vaak gezegd dat je voor uitgaande mail de SMTP van je internetprovider moest gebruiken. Met SPF en DKIM moet je dat juist niet doen voor domeinen die niet van je provider zijn.

Ik ben het dus helemaal met je eens, maar denk dat veel gebruikers erop vast kunnen lopen, door onwetendheid. Dat klinkt alsof ze dom zijn, en daarom sprak ik over “argeloos”. De voorlichting mag wel wat beter.
Reputatie 2
In het verleden werd vaak gezegd dat je voor uitgaande mail de SMTP van je internetprovider moest gebruiken. Met SPF en DKIM moet je dat juist niet doen voor domeinen die niet van je provider zijn.

In het verleden verstuurde je een email zonder daarbij een accountnaam en wachtwoord van jouw provider op te geven. De provider legde een beperking op waardoor je alleen via het eigen netwerk kon verzenden. Als ze dat niet deden kon iedereen zonder beperking mail verzenden (een "open relay") en dat is geen goede zaak. Gelukkig komen open relays praktisch niet voor. Je kon wel mail verzenden met een andere afzender dan van de provider. Dus van piet.puk@mail.nl via het netwerk van bijvoorbeeld Ziggo. De beperking op netwerk gold alleen voor toegang tot de verzendende mail server. Soms is deze methode nog steeds mogelijk, inclusief de netwerk beperking.

Tegenwoordig moet je bij het verzenden van een mail een accountnaam en wachtwoord van jouw provider opgeven. Dan wordt ook de verbinding ge-encrypt zodat je niet stiekum het wachtwoord kunt onderscheppen. De beperking op netwerk is dan niet meer nodig. Zo kun je op jouw vakantie adres met de lokale provider een mail verzenden via de mail server van Ziggo. Nog steeds kun je daarbij ook een ander mail adres gebruiken zoals piet.puk@mail.nl.

Nu komen we bij SPF en DKIM. Jouw mail provider (Ziggo.nl of "mail.nl") kan zijn mail verzending gaan beveiligen. Met SPF beveilig je dat een mail wordt verzonden vanaf een mail server die hoort bij jouw mail provider. Dus als je van jouw vakantie adres met de lokale provider contact legt met de Ziggo mail server (zoals je als het goed is ooit in jouw mobiel hebt ingevoerd, inclusief jouw Ziggo accountnaam en wachtwoord) dan zal die Ziggo mail server jouw mail versturen en geeft de SPF aan dat je van de juiste mailserver komt. Stuur je als piet.puk@mail.nl een mail via die Ziggo mail server dan hangt het er van af of mail.nl ook aan SPF doet. Als ze dat niet doen is er niets aan de hand. Als ze het wel doen dan zal de SPF controle fout gaan. Zie verderop wat dat kan betekenen.

Stuur je vanuit dat verre land die mail met de Ziggo mail server dan zal Ziggo er ook een DKIM handtekening op zetten. Dat kan alleen Ziggo doen voor een Ziggo mail adres met hun privé sleutel. De ontvanger kan de DKIM handtekening controleren met de publieke sleutel van Ziggo en zo nagaan of de mail onderweg is gewijzigd. Stuur je via Ziggo een mail van piet.puk@mail.nl dan zet Ziggo er geen DKIM handtekening op. Dat kan namelijk alleen de mail.nl mail server, als die gebruik maakt van DKIM. De ontvanger controleert of er een DKIM handtekening op staat en of die klopt. Gebruikt mail.nl geen DKIM dan is er weer niets aan de hand.

Ziggo maakt ook gebruik van DMARC. Dit geeft aan wat de ontvanger moet doen met SPF en/of DKIM. DMARC controleert ook nog extra of het adres van de verzender klopt met de gebruikte mail server en dus eindigt op @ziggo.nl of @quicknet.nl. Een paar maanden geleden stond DMARC in de test stand. Dat betekende dat de ontvanger de mail gewoon mocht accepteren, ook als SPF en DKIM fout waren. Nu staat DMARC echter echt aan en de ontvanger mag de mail alleen accepteren als SFP of DKIM ok zijn. Zijn beiden fout dan adviseert DMARC om de mail te weigeren.

Voor de mail die je via de Ziggo mail server verstuurt van piet.puk@mail.nl hangt het er vanaf of mail.nl ook aan SPF, DKIM en DMARC doet en wat hun DMARC advies is. Als mail.nl niet aan SPF, DKIM of DMARC doet komt die gewoon aan, ook als je die via een Ziggo mail server verstuurt. Gebruikt mail.nl echter wel SPF, DKIM en DMARC dan geldt de instelling daarvan van mail.nl De piet.puk@mail.nl mail die je dan verstuurt via de Ziggo mail servers krijgt geen DKIM handtekening (DKIM fout) en komt ook niet van een mail.nl mail server (SPF fout). Als de mail.nl DMARC dan in de test stand heeft staan komt de mail waarschijnlijk nog wel aan. Staat de mail.nl DMARC echter echt aan dan wordt de mail door de ontvangende mail server geweigerd. Hij kan dan nog alleen goed aankomen als je de mail verzendt via een mail.nl mail server.

Je kunt dus wel mails verzenden vanaf een mail server die niet hoort bij jouw email adres. Daar moet je je aanmelden met een accountnaam en wachtwoord die hoort bij die mail server. Dit gaat echter fout als de mail provider die hoort bij jouw email adres SPF, DKIM en DMARC heeft ingeschakeld. Dan wordt de mail door de ontvangende mail server geweigerd.

Het wrange is dat je als klant van Ziggo extra mail aflever problemen kunt krijgen omdat Ziggo de beveiliging tegen vervalsen van emails heeft ingevoerd. Gebruik je een email adres waar dat (nog) niet is gedaan dan is de kans groter dat jouw emails goed aankomen.

Zoals we nu zien is het risico van mails die niet aankomen extra groot als die onderweg wordt geforward. Dat kun je bijvoorbeeld doen omdat je van email bent veranderd (en jouw oude email adres stuurt automatisch door naar jouw nieuwe adres. Het kan ook zijn dat je een email adres wilt houden terwijl je nu bij een andere provider zit en daarom mails laat doorsturen.

Heb je aflever problemen met een email adres die wordt beveiligd met SFP, DKIM en DMARC en je hebt ook een ander email adres die dat (nog) niet heeft dan kun je naar dat andere email adres overstappen en eventueel de mails vanaf het adres met DMARC daarnaar laten forwarden. Dit zou wel eens een tijdelijke oplossing kunnen zijn want het ligt voor de hand dat uiteindelijk alle belangrijke mail providers over gaan op DMARC.

Reageer