Geforwarde Ziggo email komt soms niet aan - DMARC en DKIM

  • 17 september 2019
  • 9 Reacties
  • 677x Bekeken

Reputatie 3
  • Liefhebber
  • 35 reacties
Ziggo heeft een paar maanden geleden voor de beveiliging van emails het DMARC protocol aan gezet. Sindsdien komen emails afkomstig van Ziggo die door een andere mail server worden geforward (=doorgestuurd naar een ander mail adres) soms niet aan.

Een reden waarom dit gebeurt is als je een email adres schrijft met enkele aanhalingstekens. Dus als voorbeeld: 'Piet Puk'
Hier is 'Piet Puk' de mooi geschreven naam van de geadresseerde en het deel tussen < > is het eigenlijke email adres.

Die enkele aanhalingstekens zijn helemaal niet nodig en waarschijnlijk zie je die omdat het adres zo is opgeslagen in het adresboek van jouw mail programma. Je kunt dus ook sturen naar: Piet Puk of alleen: p.puk@mailserver.nl
Waarschijnlijk worden die enkele aanhalingstekens er door een Microsoft email programma in gezet.

Als Piet Puk zijn mails door mailserver.nl laat doorsturen naar zijn andere mail adres piet.puk@eigenmail.nl dan kan die mail door eigenmail.nl worden geweigerd. De verzender van de mail krijgt dan een bericht terug met daarin: "reason: 554 5.2.0 MXIN603 DMARC validation failed".

De verzender kan hier iets aan doen door de enkele aanhalingstekens weg te halen. Doe dat ook in het adresboek want anders gaat het de volgende keer weer fout.

De eigenlijke oorzaak zit bij de mail server die de mail doorstuurt, in het voorbeeld bij mailserver.nl.

Een korte technische verklaring:
Ziggo versleutelt een email voordat die wordt verzonden met een zogenaamde DKIM sleutel. De ontvanger van de email kan daarmee controleren of de email onderweg is gewijzigd. Als dat zo is dan adviseert Ziggo via DMARC dat de ontvanger de email moet weigeren.

De DKIM versleuteling is niet alleen de tekst van de email maar ook een aantal velden in de header van de email. Dat zijn onder andere het Aan en Van adres en het onderwerp van de email.

Wat nu gebeurt in sommige mail servers is dat die om het adres van de email nog een keer dubbele aanhalingstekens zet. Dus dan wordt het adres: " 'Piet Puk' " . Die dubbele aanhalingstekens zijn een wijziging van het adres en dus klopt de DKIM sleutel niet meer. Wordt de mail zo doorgestuurd naar een ander mail adres dan wordt die daar geweigerd.

Overkomt je dit dan moet je gaan klagen bij de mail server provider die jouw email doorstuurt (in het voorbeeld de provider van de fictieve mailserver.nl.) Die moet dan in hun mail server er voor zorgen dat de email niet eerst wordt gewijzigd.

Nog meer techniek:
Misschien gaat je dit te ver maar het kan jouw mail server provider helpen om de oplossing in zijn systeem te vinden.

Veel email providers maken gebruik van het programma "sendmail". Sendmail ontvangt emails, kijkt waar ze naar toe moeten en zet ze in email boxen of stuurt ze door naar andere email providers.

Sendmail controleert of het email adres voldoet aan de afgesproken regels. Die regels staan in document RFC2882. Daar staat in welke letters, cijfers of leestekens mogen voorkomen in een mail adres. Als er een leesteken in de mooi geschreven naam voor het email adres staat die daar niet thuis hoort dan zet sendmail om die naam dubbele aanhalingstekens.

Als je de standaard sendmail instelling gebruikt dan gaat het om de volgende leestekens: @ , ; : \ ( ) [ ] . '
Volgens RFC2882 hoort de laatste daarvan, het enkele aanhalingsteken daar niet thuis. Van RFC2882 mag die er gewoon staan. Dat is ook waarom Ziggo niets doet met die enkele aanhalingstekens en ze gewoon doorstuurt met de email.
Omdat sendmail met de standaard instelling het email adres aanpast komt een doorgestuurde email echter niet meer aan.

De email provider kan sendmail makkelijk aanpassen met de parameter: MustQuoteChars
Hiermee kun je opgeven dat een enkele quote niet moet zorgen voor extra dubbele quotes.

9 Reacties

Reputatie 3
Mail provider HCCnet is een van de email providers die het programma sendmail gebruikt en waar dit probleem nu optreedt. In een reactie geven ze Ziggo de schuld van de problemen en ze weigeren vooralsnog om hier actie op te nemen. Dit ondanks een serie overduidelijke mail bestanden die bewijzen waar het probleem zit.

Kan Ziggo hun er toe bewegen om nog een keer goed te kijken naar hun eigen configuratie?
Reputatie 3
In de uitleg hierboven heeft de community een deel van het voorbeeld email adres weggefilterd. Zo wordt het een beetje lastig om te volgen wat er is bedoeld.
Het email adres formaat bestaat uit twee delen. Eerst staat er de mooi geschreven naam: 'Piet Puk' en daar achter tussen < en > het eigenlijke email adres: p.puk@mailserver.nl
Reputatie 3
Update - Ziggo heeft de DMARC reject policy op de domeinen ziggo.nl en upc.nl weer uitgeschakeld. Op quicknet.nl staat de DMARC reject policy nog aan.
Het was dan ook ook wel heel "dapper" van Ziggo om DMARC reject aan te zetten want behalve Yahoo ken ik enkele andere grote publieke mail provider die dat heeft aangedurfd (niet bij kpn, microsoft, gmail).
Voorlopig zijn nu dus de quicknet.nl gebruikers de proefkonijnen die de vervelende gevolgen van deze DMARC reject policy ondervinden, met name emails die niet meer aankomen op hun bestemming.
Hoi @kb1 , dank voor dit inzicht, dat maakt het een stuk duidelijker voor mij en anderen die hier minder van op de hoogte zijn.☺
Reputatie 3
Een variant van een geforwarde email kan voorkomen als je mail verstuurd via de Ziggo mail servers met een niet Ziggo mail adres. Dat doe je bijvoorbeeld omdat jouw eigen Ziggo mail adres aflever problemen heeft vanwege DMARC.

Je hebt een alternatief mail adres piet.puk@mailserver.nl. (mailserver.nl is een fictief voorbeeld). Je stelt jouw mail programma of app in om te verzenden als piet.puk@mailserver.nl via de SMTP mail servers van Ziggo. De Ziggo mail server controleert of je binnen het Ziggo netwerk zit of kijkt naar jouw Ziggo accountnaam en wachtwoord en als dat ok is dan wordt de mail verzonden. Ziggo zet er geen DKIM sleutel op want het Van adres is niet van Ziggo. Dit is op zich een juiste manier om te verzenden maar afhankelijk van de beveiliging van mailserver.nl kunnen er dingen fout gaan (lees verder...). In feite, als mailserver.nl geen beveiliging zoals SPF, DKIM, DMARC gebruikt zal deze manier prima werken.

De mail server van de ontvanger controleert of de mail wordt verzonden van een geauthoriseerde mailserver met SPF. De Ziggo mail servers staan niet op de SPF lijst van mailserver.nl maar waarschijnlijk staat mailserver.nl dat toch toe (net als Ziggo overigens in een vergelijkbaar geval.) Dat heet een "softfail". Er is geen DKIM sleutel dus die controle kan niet worden gedaan (fail). De ontvanger zal nu de mail accepteren, tenzij mailserver.nl via DMARC laat weten dat de mail moet worden geweigerd. (Ziggo DMARC doet dat nu wel bij quicknet.nl maar niet voor ziggo.nl of upc.nl. In dit voorbeeld is echter mailserver.nl bepalend en niet Ziggo.)

Stel nu dat de mail server van de ontvanger toch de mail weigert, vanwege mailserver.nl DMARC of omdat de mail server denkt dat het een SPAM bericht is. Dan wordt de mail gebounced en teruggestuurd naar de verzender. Dat is in dit geval de Ziggo mail server maar met retour adres piet.puk@mailserver.nl. De Ziggo mail server zegt, niet voor mij, en forward (=stuurt) de mail naar mailserver.nl. Ziggo zet er nu wel een DKIM sleutel op want nu is de administratieve postmaster@ziggo.nl de afzender geworden. De DKIM sleutel die Ziggo nu gebruikt (met selector 201808smtpq) heeft echter een (te) korte lengte.

Een DKIM sleutel mag 512 tot 2048 bits lang zijn. Men beschouwt een sleutel van 512 bits echter niet meer als veilig genoeg, het moet nu 1024 of langer zijn. Verschillende mail servers, waaronder gmail, weigeren een email met zo'n korte DKIM sleutel. Als mailserver.nl dat ook doet dan komt het bounce bericht dus nooit aan en zul je niet weten dat de mail van Piet Puk niet is afgeleverd.

@Ziggo, het is hoog tijd om ook deze DKIM sleutel te vervangen.
Reputatie 3

Nog een variant waarom geforwarde emails soms niet aankomen:

Ziggo zet een DKIM sleutel op de mail tekst die vanaf een Ziggo  mail server wordt verzonden met een ziggo.nl, upc.nl, quicknet.nl mail adres. Daarmee wordt beveiligd dat de mail onderweg niet wordt gewijzigd.  Met de DMARC reject policy aan (nu voor quicknet.nl) wordt een mail door de ontvanger geweigerd als er iets in de body tekst of geselecteerde header velden is gewijzigd.

Als de mail door een andere mail server wordt geforward zal die mail server soms toch iets in de mail tekst wijzigen en dan gaat het fout. Dat kan gebeuren als (een deel van) de tekst in de mail is gecodeerd als utf-8. Onopgemaakte tekst (text/plain) in een email gebruikt normaal maar 7 bits van een tekst byte. In utf-8 komen echter ook waardes voor die alle 8 bits gebruiken. Dat zie je bijvoorbeeld bij speciale leestekens zoals ç, ß (diacriten). Als de mail server de tekst codering gaat omzetten naar een 7 bits waarde dan klopt de DKIM sleutel niet meer.

Mail servers (software)  die er om bekend staan dat ze de mail tekst aanpassen zijn onder andere Verizon, Outlook.com, hotmail, Office365, Microsoft SMTP en mail servers die sendmail gebruiken (onder andere HCCnet).

Wat kun je hieraan doen?

  • Klagen bij jouw mail forwarding provider.
  • Mail niet meer doorsturen naar een Ziggo mail adres.
  • Niet meer gebruik maken van jouw mail forwarder.

Deze oplossingen zullen niet altijd praktisch mogelijk zijn...

Hoe ontdek je dat dit gebeurt?

Dat is een lastige. Meestal merk je het doordat sommige mails niet aankomen (de afzender maakt je er op attent.) Dan heb je echter geen vergelijking tussen de verzonden mail en wat er is ge-forward. Je kunt het simuleren door zelf emails te verzenden maar dan moet je wel weten waar je naar kijkt. Je kunt een BCC naar check-auth@verifier.port25.com sturen die je dan een rapport terugstuurt met de details van de DKIM versleuteling inclusief een kopie van de originele mail. Ook leerzaam is de Thunderbird plugin: Dkim-verifier.

Reputatie 3

Ziggo maakt het ons als klant niet gemakkelijk om problemen met emails die niet aankomen te onderzoeken nadat Ziggo DMARC aan heeft gezet.

Iedereen die hier komt kijken zal hebben meegemaakt dat de Ziggo helpdesk botweg weigert om op deze problemen in te gaan (ondanks dat de problemen door een Ziggo actie zijn ontstaan.)

Ook doet Ziggo maar half mee aan het DMARC concept. Een heel waardevol deel van DMARC is dat een ontvangende mail server statistische gegevens terugzendt naar de verzendende mail server waardoor die kan nagaan hoeveel mails er wel of niet goed aankomen. Je raadt het al, Ziggo maakt wel graag gebruik van de DMARC rapportages van andere mail servers zoals Gmail, Yahoo en vele anderen maar publiceert zelf geen DMARC rapportages.

Een nieuw ontdekte @Ziggo fout is het volgende - een ontvangende mail server die een email controleert met SPF, DKIM en DMARC kan het resultaat van die beoordeling opnemen in de header van de email. Deze Authentication-Results header or ARH ziet er uit als volgt:

Authentication-Results: mail.iss.as9143.net;
 spf=pass (212.54.xxx.xxx;quicknet.nl);
 dkim=pass header.d=quicknet.nl;
 dmarc=pass header.from=quicknet.nl (p=reject sp=reject dis=pass);

(Drie keer pass is goed, de mail wordt doorgelaten.)

Het formaat van een ARH header is gestandaardiseerd in RFC 7601 en de ARH die Ziggo plaatst voldoet niet aan de standaard in de RFC.

Dat betekent onder andere dat de DKIM verifier app in Thunderbird het resultaat van de ARH niet kan gebruiken om de DMARC status weer te geven. (De volgende update van de app zal rekening kunnen houden met het incorrecte formaat van Ziggo.)

Dan komen we bij de volgende @Ziggo fout. Ziggo valideert de emails die binnenkomen op de mail server en daarna zet Ziggo een aantal extra headers boven in de email, waaronder de ARH. Soms zet Ziggo er echter ook een extra header in die onderdeel uitmaakt van de DKIM handtekening - een nieuwe Message-ID. De mail die aldus is aangepast wordt opgeslagen totdat onze mail programma’s hem ophalen en lezen. Op dat moment is de DKIM handtekening niet meer geldig en de DKIM verifier app geeft dat aan. Dat is natuurlijk vreselijk verwarrend als je op zoek bent waarom verschillende mails niet aankomen en je vindt er een met een ongeldige DKIM handtekening, die toch blijkt te zijn geaccepteerd door Ziggo.

De Message-ID staat bovenaan in de headers voor de DKIM handtekening waaruit je kunt afleiden dat hij later is toegevoegd.

Ziggo zet de Message-ID waarschijnlijk in de email omdat de email oorspronkelijk geen Message-ID had. De DKIM handtekening is inclusief Message-ID, ook als die er helemaal niet is. Wordt er dan later een Message-ID toegevoegd dan gaat de DKIM validatie fout.

De mail standaarden zeggen dat een Message-ID niet verplicht is maar het wordt wel sterk aangeraden. Maar,.. de oorspronkelijke email werd ook verzonden door Ziggo en dus hadden ze toen al de Message-ID moeten toevoegen.

 

Reputatie 3

In aanvulling op het issue met Message-ID in de vorige reactie:

Een email bevat gewoonlijk een Message-ID header als unieke identificatie van een bericht. Als op een bericht wordt geantwoord dan krijgt dat antwoord een eigen Message-ID. De oorspronkelijke Message-ID wordt dan in een ander header veld meegestuurd. Wordt een bericht alleen ge-forward dan houdt die zijn eigen Message-ID. De Message-ID maakt gewoonlijk ook deel uit van de DKIM sleutel zodat je kunt nagaan of iemand onderweg met de unieke Message-ID heeft gerommeld.

De Message-ID wordt normaal aangemaakt door het mail programma die de mail verzendt. De ID bestaat typisch uit een uniek deel gevolgd door @ en de domain naam (bijvoorbeeld quicknet.nl) en staat tussen < en > tekens.

Een Message-ID is niet verplicht maar wel sterk aanbevolen. Het is dan ook niet gek als de mailserver die de mail als eerste ontvangt zelf een Message-ID aanmaakt als die niet door het mail programma wordt gegeven. De mailserver maakt daarna een DKIM sleutel aan voor de email, inclusief Message-ID en stuurt de mail dan door.

Het blijkt nu dat sommige mail programma's inderdaad geen Message-ID aanmaken en één daarvan is de standaard mail app op een Android smartphone. Dit is geconstateerd voor in ieder geval de mail app van recente Samsung smartphones.

Wat er nu fout gaat in de Ziggo omgeving is dat de Ziggo mail server er tijdens het verzenden niet alsnog een Message-ID op zet. In de DKIM sleutel wordt geregistreerd dat er geen Message-ID is. Dit is op zich nog allemaal toegestaan, hoewel het ingaat tegen het sterke advies om een Message-ID op te nemen.

Ontvangt Ziggo echter zo'n email zonder Message-ID dan zet de mail server er nu wel een Message-ID op. Deze ID is echter niet in de DKIM sleutel opgenomen en de DKIM is nu ongeldig geworden. Het is dus niet slim om er nu nog een Message-ID op te zetten. Wordt deze email daarna door Ziggo ge-forward dan zal de ontvanger een ongeldige DKIM detecteren en de mail weigeren.

Ziggo komt er nu nog vaak mee weg omdat ze zelf eerst de DKIM controleren voordat ze de Message-ID toevoegen. Veel mail programma's die daarna de mail ophalen uit de mailbox doen niet zelf een DKIM check en accepteren de zo ongeldig gemaakte email.

Waar je dit wel kunt zien is in mail programma Thunderbird met de DKIM verifier plugin.

Reputatie 3

Mail forwarding met SRS (Sender Rewrite Scheme)
Sommige mail forwarders maken gebruik van SRS met de bedoeling om het breken van de SPF test bij een forward te voorkomen. Dat werkt helaas niet als de afzender gebruik maakt van DMARC.

SRS past het "envelope-from" adres aan van een email voordat die wordt doorgezonden. Het nieuwe "envelope-from" adres krijgt een domain naam van de forwarding provider. Een "envelope-from" adres wordt door de verzendende mail server  toegevoegd. Dit adres is normaal niet zichtbaar in tegenstelling tot het FROM adres dat de verzender er zelf op zet en wat als afzender zichtbaar is voor de ontvanger.

De SPF check werkt op basis van de domain naam van het "envelope-from" adres. Als voorbeeld p.puk@mailserver.nl, SPF controleert of het ip-address van de mailserver bekend is bij “mailserver.nl”.

Bij het forwarden wordt het ip-address van de forwarding mail server gebruikt en zonder SRS zal dat nieuwe ip-address niet door de SPF check komen. Met SRS zet de forwarding server er een ander adres op. Als voorbeeld SRS0=Hvqw=2B=mailserver.nl=p.puk@forwarder.nl. De forwarder kan het originele adres hier uit afleiden. De SPF check wordt nu gedaan voor “forwarder.nl” en zo vind je of het ip-address van de forwarder hier mee overeen komt. Dan moet forwarder.nl wel een eigen SPF DNS record publiceren want anders is het SPF resultaat niet "pass" maar "none".

Als de originele mail server gebruik maakt van DMARC worden er nog aanvullende tests gedaan. De tests van DMARC zijn gebaseerd op het FROM adres (p.puk@mailserver.nl). Zo wordt het FROM adres vergeleken met het "envelope-from" adres waarmee de SPF test is gedaan en die komen nu niet meer overeen waardoor de SPF test voor DMARC een "fail" status zal geven.

Naast SPF kijkt DMARC ook naar DKIM. Als de email niet is gewijzigd door de forwarding mail server dan zal een DKIM test (indien aanwezig) slagen. DMARC vergelijkt daarna het FROM adres domain met het domain waarmee de mail is ondertekend door de verzendende mail server en die zullen dan overeen komen waardoor DKIM voor DMARC een "pass" is en de mail kan worden geaccepteerd (minimaal één van SPF of DKIM moet “pass” zijn).

Is er geen DKIM aanwezig of is de mail gewijzigd dan zal DKIM falen en omdat de SPF ondanks SRS ook heeft gefaald wordt de email geweigerd.

Reageer