1
Vraag
2
Reacties
SixtySpecial

Level 1
  • 12Posts
  • 0Oplossingen
  • 2Likes

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

Goedemorgen community,

Laat ik beginnen met zeggen dat ik gewoon mail kan verzenden en ontvangen. Ik krijg geen foutmeldingen en (de meeste) berichten die naar mij verzonden worden krijg ik binnen.

Waarom dan toch een bericht hier? Nou, per toeval kom ik er achter dat sommige berichten mijn mailbox NIET bereiken. Had onlangs contact met iemand en die zou me mailen, maar niks ontvangen. Dus even gebeld. 'Ja, toch echt verstuurd naar je.' Mailadres was juist getypt, mail stond ook bij verzonden items en er was geen bouncemelding ontvangen.

Deze mevrouw heeft toen navraag gedaan bij haar provider en daar hebben ze het DMARC-protocol uitgezet voor haar. Sindsdien komen haar berichten weer binnen bij me.

Ik zou er niet wakker van gelegen hebben als ik niet van iemand waar ik heel regelmatig mail van ontving, plots ook geen berichten meer kreeg. Bij navraag daar, blijkt dat zij wel berichten verzonden hadden... Nu maak ik me ongerust. Hoeveel mail loop ik inmiddels mis?

Is iemand bekend met het DMARC-protocol (heb er wel wat over gelezen. Is een soort van extra beveiliging voor email) en kan het zijn dat dit er voor zorgt dat berichten mij niet meer bereiken?

Voor de volledigheid: ik heb enkele email-aliassen die ik laat verwijzen naar mijn ziggo mailbox. Dat werkt eigenlijk prima en ik zoek dus eigenlijk ook geen oplossing waarbij ik die aliassen zou moeten opgeven.

Benieuwd naar reacties en (hopelijk) goede oplossingen.

Vriendelijk dank,
Renato.
Uitgelicht
Mark
Oud Community Moderator
Oud Community Moderator
  • 5774Reacties
  • 655Oplossingen
  • 1963Likes
Hey kb1 (en efok en RobHotton), Ik heb een zeer uitgebreide reactie gekregen over de werking van SPF, DKIM, DMARC en ons security beleid (onder "Lees meer").

Hierin wellicht het meest van belang voor jou vraagstuk, een –all (hardfail) is geen advies om een email de droppen, maar om te kijken naar DMARC. Als beide DKIM checks slagen (ook al geeft SPF een fail) geeft DMARC een success.

Het is een bewuste keuze om –all op al onze domeinen toe te passen (in de nabije toekomst).
En dat de maatregel ook al deels teruggedraaid is kan verklaren waarom het bij jou ineens weer werkt RobHotton.
Wat is er aangepast:
SPF van een ~all naar –all statement.
DMARC van Monitoring afgehaald en naar Reject gezet.
Alle domeinen worden DKIM signed die door onze mailserver verloopt.
* Dit is nog niet op alle domeinen van toepassing en is op dit moment deels teruggedraaid vanwege de feedback (DMARC rapportage) die we kregen. Het streven is om al onze domeinen uiteindelijk naar –all om te zetten.
* Bij Ziggo.nl staat een ~all omdat we ook derde partijen hebben die mails versturen vanaf dit domein en nog geen gebruik maken van DKIM. Deze derde partijen zullen in de toekomst vanaf ziggo.com mailen waarna op ziggo.nl ook een –all geplaatst kan worden.

Wie mag er mailen met de domeinen van Ziggo?
Dat zijn de mail servers van Ziggo zelf smtp.ziggo.nl

Welke beveiligingsmethodes zijn er?
SPF, DKIM, DMARC, DANE, etc.
Ik ga in op SPF, DKIM, DMARC is het advies wat wij geven aan ontvangende mail servers. De ontvangende mail server bepaalt zelf hoe hij omgaat met de ontvangen mail.
Ze kunnen ervoor kiezen om te droppen (discarden), markeren als spam in onderwerp, verplaatsen naar spam folder, niks ermee doen gewoon in de inbox en vele andere mogelijkheden.
Dus ook al zou Ziggo advies geven om iets te rejecten kan het zijn dat de mail gewoon aankomt in de inbox omdat de beheerder van de ontvangende mail server hiervoor kiest.
Ziggo krijgt, doordat we op alle domeinen DMARC rapportage aan hebben staan, informatie over een deel van het mail verkeer. Hierin zien we ook wat het advies is van Ziggo vanuit de checks en wat de ontvangende mail servers bepalen om te doen met de mail.
Bij afwijkingen zien wij dat en kunnen contact dan opnemen met deze partijen mochten we dat willen.

Waarom past Ziggo instellingen aan?
Ziggo werkt continue aan de beveiliging van onze domeinen. De regels over gebruik zijn niet veranderd, maar worden door deze wijzigingen strenger gecontroleerd.
Dit is nodig om de stijgende spam, phishing, fraude over de hele wereld tegen te gaan.
Dit is nodig om de klant zijn email te beschermen en ook dat we buiten ons mail platform de klant beschermen. Voorbeeld: als iemand in Rusland een mailtje stuurt naar Tokyo met de klant zijn email adres (wat geheel buiten ons platform om loopt) hebben we nog steeds invloed op om deze te laten droppen bij de ontvangende mailserver.
Helaas zorgt dit ervoor dat sommige configuraties die voorheen gewoon gewerkt hebben nu niet meer werken. De wijze van gebruik is niet veranderd, maar sommige ontvangende mailservers lieten toch de mail door omdat sommige veiligheidsinstellingen (SPF, DMARC) niet scherp stonden.

Verschil tussen ~all en –all
v=spf1 include:smtp.spf.ziggo.nl ~all = softfail. For SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
Hier staat alleen de mailservers van Ziggo mogen mailen namens het domein. Alleen als het van een andere bron komt markeer de mail of voer zelf extra checks op de mail.
v=spf1 include:smtp.spf.ziggo.nl –all = hardfail.
Deze mailserver mag niet mailen met dit domein. FAIL. Echter we adviseren niet direct om de mail te droppen (wat veel mensen denken), maar echter om te kijken naar DMARC. Dat is het advies, aangezien DMARC gebruikt wordt.
Echter sommige partijen rejecten op basis van SPF Fail al. Dat hebben we niet in de hand.

Als mensen hun email forwarden gaat SPF altijd stuk tenzij met SRS (Sender Rewrite Scheme) gebruiken. SRS was devised in order to forward email without breaking the Sender Policy Framework (SPF)
Hier maken niet veel partijen gebruik van. Ziggo momenteel ook niet.

Dus Ziggo klant
voorbeeld@quicknet.nlmailt
pietje@eigendomein.nldaar staat een forward naar
pietje@hotmail.com.
In deze situatie ziet de ontvangende mail server (Hotmail) dat de mail afkomstig is van een mailserver bij eigendomein. Eigendomein staat niet in de SPF record van quicknet.nl en mag die mail niet versturen volgens SPF dus HARD FAIL.
Hier komt de term DKIM survival naar voren. Als de mail niet zodanig aangepast wordt overleeft de DKIM signature icm het from domein. Waardoor DKIM slaagt. Waardoor DMARC slaagt als beide DMARC DKIM checks ook slagen.

DKIM:
Versleutelen van de mail met public en private key.
Public key staat in de DNS van het verzendende domein die de ontvangende mail server opvraagt.

DMARC: (Meest belangrijke)
DMARC is bedacht om de huidige veiligheidschecks aan te vullen. Aangezien ze gevoelig waren om makkelijk te misleiden door creatief de misbruikende mail server te configureren waardoor de veiligheidschecks slaagde, maar vanuit een verdacht bron kwamen.
DMARC voert 4 checks uit. 1) SPF basic 2) SPF DMARC Alignment 3) DKIM Basic 4) DKIM DMARC Alignment
Als beide SPF checks of beide DKIM check succesvol uitgevoerd worden geeft DMARC een success. (Dus 1 & 2 OF 3 & 4)
DMARC basic checks worden gedaan door SPF en DKIM correct te configureren en te gebruiken.
DMARC controleert alleen check 1 & 3 en voert zelf 2 & 4 uit.

SPF: Kijkt naar het domein in de return-path
DKIM:kijkt naar het domein waarmee gesigned is in de DKIM handtekening
DMARC:Check 2 vergelijkt het domein op afwijkende domeinnamen in de mail. Return-Path VS FROM domein
DMARC:Check 4 vergelijkt DKIM signature domein met FROM domein.
Hierdoor vult DMARC de huidige protocollen aan met twee extra checks.
36 Reacties 36
RobHotton

Level 1
  • 5Posts
  • 1Oplossingen
  • 1Likes
Ik had hetzelfde probleem tot 5 minuten geleden. Yourhosting zei dat het bij Ziggo ligt,en Ziggo zei dat het bij Yourhosting ligt. Ze probeerden me beide wel te helpen,maar er kwam geen echte oplossing. Uiteindelijk was er iemand bij yourhosting die zei dat ik het SPF record bij Ziggo moest opvragen en dat zij dit dan zouden toevoegen aan mijn DNS.
Ik ben toen mijn DNS eens gaan bekijken en toen ik de reset knop zag dacht ik *stel je voor* 🙂 En inderdaad na de reset werkt het verzenden weer normaal. Krijg geen berichten meer dat de mail onbestelbaar is. En ik heb bij de afzenders gecheckt of de mail binnen was,en dat was het geval. Dus wie weet een heel simpele oplossing.
Mark
Oud Community Moderator
Oud Community Moderator
  • 5774Posts
  • 655Oplossingen
  • 1963Likes
Hey kb1 (en efok en RobHotton), Ik heb een zeer uitgebreide reactie gekregen over de werking van SPF, DKIM, DMARC en ons security beleid (onder "Lees meer").

Hierin wellicht het meest van belang voor jou vraagstuk, een –all (hardfail) is geen advies om een email de droppen, maar om te kijken naar DMARC. Als beide DKIM checks slagen (ook al geeft SPF een fail) geeft DMARC een success.

Het is een bewuste keuze om –all op al onze domeinen toe te passen (in de nabije toekomst).
En dat de maatregel ook al deels teruggedraaid is kan verklaren waarom het bij jou ineens weer werkt RobHotton.
Wat is er aangepast:
SPF van een ~all naar –all statement.
DMARC van Monitoring afgehaald en naar Reject gezet.
Alle domeinen worden DKIM signed die door onze mailserver verloopt.
* Dit is nog niet op alle domeinen van toepassing en is op dit moment deels teruggedraaid vanwege de feedback (DMARC rapportage) die we kregen. Het streven is om al onze domeinen uiteindelijk naar –all om te zetten.
* Bij Ziggo.nl staat een ~all omdat we ook derde partijen hebben die mails versturen vanaf dit domein en nog geen gebruik maken van DKIM. Deze derde partijen zullen in de toekomst vanaf ziggo.com mailen waarna op ziggo.nl ook een –all geplaatst kan worden.

Wie mag er mailen met de domeinen van Ziggo?
Dat zijn de mail servers van Ziggo zelf smtp.ziggo.nl

Welke beveiligingsmethodes zijn er?
SPF, DKIM, DMARC, DANE, etc.
Ik ga in op SPF, DKIM, DMARC is het advies wat wij geven aan ontvangende mail servers. De ontvangende mail server bepaalt zelf hoe hij omgaat met de ontvangen mail.
Ze kunnen ervoor kiezen om te droppen (discarden), markeren als spam in onderwerp, verplaatsen naar spam folder, niks ermee doen gewoon in de inbox en vele andere mogelijkheden.
Dus ook al zou Ziggo advies geven om iets te rejecten kan het zijn dat de mail gewoon aankomt in de inbox omdat de beheerder van de ontvangende mail server hiervoor kiest.
Ziggo krijgt, doordat we op alle domeinen DMARC rapportage aan hebben staan, informatie over een deel van het mail verkeer. Hierin zien we ook wat het advies is van Ziggo vanuit de checks en wat de ontvangende mail servers bepalen om te doen met de mail.
Bij afwijkingen zien wij dat en kunnen contact dan opnemen met deze partijen mochten we dat willen.

Waarom past Ziggo instellingen aan?
Ziggo werkt continue aan de beveiliging van onze domeinen. De regels over gebruik zijn niet veranderd, maar worden door deze wijzigingen strenger gecontroleerd.
Dit is nodig om de stijgende spam, phishing, fraude over de hele wereld tegen te gaan.
Dit is nodig om de klant zijn email te beschermen en ook dat we buiten ons mail platform de klant beschermen. Voorbeeld: als iemand in Rusland een mailtje stuurt naar Tokyo met de klant zijn email adres (wat geheel buiten ons platform om loopt) hebben we nog steeds invloed op om deze te laten droppen bij de ontvangende mailserver.
Helaas zorgt dit ervoor dat sommige configuraties die voorheen gewoon gewerkt hebben nu niet meer werken. De wijze van gebruik is niet veranderd, maar sommige ontvangende mailservers lieten toch de mail door omdat sommige veiligheidsinstellingen (SPF, DMARC) niet scherp stonden.

Verschil tussen ~all en –all
v=spf1 include:smtp.spf.ziggo.nl ~all = softfail. For SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
Hier staat alleen de mailservers van Ziggo mogen mailen namens het domein. Alleen als het van een andere bron komt markeer de mail of voer zelf extra checks op de mail.
v=spf1 include:smtp.spf.ziggo.nl –all = hardfail.
Deze mailserver mag niet mailen met dit domein. FAIL. Echter we adviseren niet direct om de mail te droppen (wat veel mensen denken), maar echter om te kijken naar DMARC. Dat is het advies, aangezien DMARC gebruikt wordt.
Echter sommige partijen rejecten op basis van SPF Fail al. Dat hebben we niet in de hand.

Als mensen hun email forwarden gaat SPF altijd stuk tenzij met SRS (Sender Rewrite Scheme) gebruiken. SRS was devised in order to forward email without breaking the Sender Policy Framework (SPF)
Hier maken niet veel partijen gebruik van. Ziggo momenteel ook niet.

Dus Ziggo klant
voorbeeld@quicknet.nlmailt
pietje@eigendomein.nldaar staat een forward naar
pietje@hotmail.com.
In deze situatie ziet de ontvangende mail server (Hotmail) dat de mail afkomstig is van een mailserver bij eigendomein. Eigendomein staat niet in de SPF record van quicknet.nl en mag die mail niet versturen volgens SPF dus HARD FAIL.
Hier komt de term DKIM survival naar voren. Als de mail niet zodanig aangepast wordt overleeft de DKIM signature icm het from domein. Waardoor DKIM slaagt. Waardoor DMARC slaagt als beide DMARC DKIM checks ook slagen.

DKIM:
Versleutelen van de mail met public en private key.
Public key staat in de DNS van het verzendende domein die de ontvangende mail server opvraagt.

DMARC: (Meest belangrijke)
DMARC is bedacht om de huidige veiligheidschecks aan te vullen. Aangezien ze gevoelig waren om makkelijk te misleiden door creatief de misbruikende mail server te configureren waardoor de veiligheidschecks slaagde, maar vanuit een verdacht bron kwamen.
DMARC voert 4 checks uit. 1) SPF basic 2) SPF DMARC Alignment 3) DKIM Basic 4) DKIM DMARC Alignment
Als beide SPF checks of beide DKIM check succesvol uitgevoerd worden geeft DMARC een success. (Dus 1 & 2 OF 3 & 4)
DMARC basic checks worden gedaan door SPF en DKIM correct te configureren en te gebruiken.
DMARC controleert alleen check 1 & 3 en voert zelf 2 & 4 uit.

SPF: Kijkt naar het domein in de return-path
DKIM:kijkt naar het domein waarmee gesigned is in de DKIM handtekening
DMARC:Check 2 vergelijkt het domein op afwijkende domeinnamen in de mail. Return-Path VS FROM domein
DMARC:Check 4 vergelijkt DKIM signature domein met FROM domein.
Hierdoor vult DMARC de huidige protocollen aan met twee extra checks.
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
Even een samenvatting van de goede uitleg van Ziggo hierboven:
Ziggo wil spammers en andere smiegten zo veel mogelijk afknijpen en maakt de email controles strenger.

Drie controle punten:
SPF - controleert of een email verzonden namens een Ziggo mail adres (ziggo.nl, quicknet.nl) ook daadwerkelijk wordt verzonden vanaf een Ziggo mail server (ip-address). Dat gaat goed als je verzendt via Ziggo maar een mail die wordt geforward komt in principe vanaf een andere mail server (ip-address) en de SPF controle geeft een fail (of in het beste geval een softfail met ~all).

DKIM - Ziggo berekent voor emails die worden verzonden via de Ziggo mail servers een checksum over de mail headers en over de mail tekst. De ontvangende mail server berekent checksum opnieuw met gebruik van de publieke sleutel die in de Ziggo DNS is opgeslagen. De berekende checksum wordt vergeleken met de waarde die met de mail is verzonden. Als de mail tekst of headers zijn gewijzigd is er een DKIM fail. Een DKIM wordt meegestuurd als een mail wordt geforward en moet daarna ook nog kloppen, tenzij de mail onderweg is gewijzigd.

DMARC - geeft in meer detail aan wat het advies aan de ontvangende mail server is.
v=DMARC1; p=reject; rua=mailto:x.dmarcian.eu; ruf=mailto:x@dmarcian.eu; fo=1; adkim=s; aspf=s;

Dit is het DMARC record op dit moment van quicknet.nl (mail adressen zijn aangepast...)
p=reject - een mail die niet passed weigeren. Ook mogelijk is p=none (vrijblijvend) of p=quarantine (zet in de spam folder).
rua= en ruf= is waar andere mail providers hun evaluaties naar toe sturen zodat Ziggo kan kijken of en waarom DMARC goed werkt. fo=1 vraagt hierbij om extra details.
adkim=s - strict - het domein van DKIM moet exact overeenkomen. Ook mogelijk is r - relaxed die meer afwijkingen toelaat.
aspf=s - strict - - het domein van SPF moet exact overeen komen. Ook mogelijk is r - relaxed.

DMARC doet naast het resultaat van de standaard SPF en DKIM controles ook zelf nog een tweetal controles vergelijkbaar met SPF en DKIM die potentieel van een ander email adres in de mail header kunnen uitgaan.

DMARC geeft een pass als de SPF of de DKIM testen een pass geven.

Bij een forward zal de SPF test falen maar de mail kan alsnog passeren als de DKIM test slaagt. Daarvoor is het nodig dat de mail server die de mail doorstuurt geen aanpassingen maakt in de mail tekst of in de mail headers die zijn opgenomen in de DKIM checksum.
Soms gebeurt dat echter toch. Dat kan bijvoorbeeld als de email een 8bit encoding gebruikt en er onderweg een mail server is die alleen 7bit encoding aan kan. Dan wordt de tekst geconverteerd naar 7bit en klopt de checksum niet meer. Het is ook mogelijk dat een mail server onderweg iets aanpast in een header die is opgenomen in de DKIM checksum, bijvoorbeeld de datum/tijd.

Mijn mails worden verzonden vanaf quicknet.nl naar mail server 2 en die doet een forward naar mail server 3.
Als ik nu een mail stuur zonder tekst wordt de mail geweigerd door mail server 3 (DMARC).
Als ik een mail stuur met een triviale tekst "aaa" komt de mail goed aan.
Sommige mails met meer tekst worden echter geweigerd.
Ik kan niet precies zien waarom de mails worden geweigerd want in de delivery notifications staat alleen DMARC failed en niet op welke test.

Ik heb daarom een delivery notification laten analyseren op mxtoolbox.com en die zegt:
SPF Alignment fail
SPF Authenticated fail
DKIM Alignment pass
DKIM Authenticated fail
Ik verwacht dat SFP failed voor een geforwarde email. De DKIM (Alignment) test is pass maar waarom is dan de DKIM Authentication fail?

Nog een tip - in mail programma Thunderbird kun je de DKIM verifier plugin installeren. Die vertelt je voor elke ontvangen email of er een DKIM aanwezig is en van welk domein en of die passed of failed.

Ziggo krijgt van de ontvangende mail servers een DMARC rapport waaraan ze kunnen zien welke mails failen en waarom. Dat zijn helaas niet alle mail servers, Google en Yahoo doen het wel maar Microsoft doet het niet en ook Ziggo zelf en KPN geven geen DMARC rapportages aan andere verzendende mail servers.

Nog even een noot over het strenger maken van de mail controles. Voor een organisatie zoals onze overheid of grote bedrijven is het belangrijk dat hun mail betrouwbaar overkomt en daar wil je de controles zo streng mogelijk maken.
Ziggo is echter naast een bedrijf die zelf email verzendt ook een service provider die namens al hun klanten mail verzendt. Het is voor de particuliere klanten van Ziggo veel belangrijker dat hun mail goed aankomt dan dat wordt voorkomen dat een smiegt misbruik maakt van hun prive Ziggo mail adres. De balans ligt dus anders dan bij bijvoorbeeld de rijksoverheid.
Hoot_Posthorn

Level 7
  • 158Posts
  • 12Oplossingen
  • 109Likes
efok wrote:
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
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes


Hoot_Posthorn wrote:

Neuh, da's niet goed. Je FROM adres moet je FROM adres zijn. Dus horen bij het domein van de mailser...Dus Stel, onze argeloze gebruiker "piet.puk@quicknet.nl" wil graag dat je antwoord stuurt aan "pukpi...En als hij dan zijn from herschrijft naar pukpiet@gmail.com en verstuurt het bericht via z'n quickne...


Je moet eerst aanmelden met je userid en password voordat je via Ziggo mail servers kunt mailen. Vroeger had je nog wel mail servers waar je anoniem kon mailen maar die keken wel of je binnen kwam via het netwerk van de provider. Mail servers die helemaal nergens naar kijken (open relay servers) werden altijd al fout gevonden.

Je kunt prima een mail verzenden via Ziggo mail servers met een ander domein bijvoorbeeld jan@bedrijf-x.com. Ziggo zal er dan geen DKIM op zetten en de SPF en DMARC controles hangen af van de DNS instellingen van bedrijf-x.com en niet van Ziggo. Ziggo zet wel jouw eigen Ziggo of quicknet email adres als X-authenticated-sender in de mail headers zodat zichtbaar is waar je vandaan kwam.
Hoot_Posthorn

Level 7
  • 158Posts
  • 12Oplossingen
  • 109Likes
Aanmelden heb je gelijk in. Vroegah kon je op multikabel zonder aanmelden versturen, omdat je in het 'trusted' netwerk zat. Dan is aanmelden de betere optie.


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.

Thanks kb1
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
Hoot_Posthorn wrote:
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.
Babbel

Level 6
  • 230Posts
  • 5Oplossingen
  • 141Likes
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.
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
Babbel wrote:
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?
Babbel

Level 6
  • 230Posts
  • 5Oplossingen
  • 141Likes
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:wink:

The Port25 Solutions, Inc. team

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

==========================================================
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
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:
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.

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 :slight_smile:
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
Zo te zien heeft Ziggo gereageerd op de probleem melding hierboven (lege body tekst). :relaxed:

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.)
Wlmpie

Level 11
  • 532Posts
  • 11Oplossingen
  • 174Likes
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?
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
Wlmpie wrote:
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... :wink:
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
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?

  • 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.
  • Klaag bij de eigenaar van de mail server die de forward doet. Dat staat in mijn geval nu open en ik ben benieuwd...
efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes
Hoot_Posthorn wrote:

efok wrote:
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.
kb1

Level 7
  • 143Posts
  • 5Oplossingen
  • 96Likes
efok wrote:
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.
E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic