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.
SixtySpecial
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes
1 Geaccepteerde oplossing

Ik zal het proberen uit te leggen, dit is complexe materie.
Omdat de spam tegenwoordig de spuigaten uitloopt zijn technieken bedacht om te identificeren of de afzender van een e-mail wel legitiem is. Spammers verzonden immers vaak mail zogenaamd afkomstig van bijvoorbeeld je bank.

De eerste methode is een zogenaamd SPF record aan je domein toevoegen. Hierin word bepaald welke mailservers mail mogen versturen voor een bepaald domein (bijv pietje.nl). Mailservers die niet op de SPF lijst staan mogen geen mail verzenden van pietje.nl. Gebeurt dat toch, dan kan deze mail dus gefilterd worden. Deze records staan op de DNS server voor dat domein, en zijn dus door iedereen op te vragen.

De tweede methode is DKIM. Daarmee wordt een digitale handtekening/sleutel aan je mail gehangen, waarvan de echtheid valt te controleren. De digitale handekening wordt eveneens gevalideerd aan de hand van een DNS record van je domein. Deze handtekening kan alleen door de echte mailserver voor bv pietje.nl juist worden gegenereerd.

Deze 2 methodes zijn relatief jonge toevoegingen aan het mailprotocol. Wat is dan DMARC? DMARC is een policy, zeg maar een beslisregel. Het verzendede domein bepaalt hier mee wat de ontvanger met de mail moet die niet aan SPF/DKIM voldoet. Verder kan DMARC een check doen op zogenaamde alignment. https://en.m.wikipedia.org/wiki/DMARC

DMARC zou kunnen bepalen dat een ontvangende mailserver een mail die niet aan de voorwaarden voldoet in quarantaine plaatst (policy=quarantaine) Daarop volgt geen bounce-bericht, want de mail is immers geaccepteerd door de ontvangende server. De ontvangende partij isoleert bij quarantaine de mail voor de ontvanger, totdat bijvoorbeeld de beheerder van de mailserver besluit deze alsnog vrij te geven, of in het geval van spam, te deleten.

DMARC kan ook definiëren om een mail domweg door de te laten die niet aan de voorwaarden voldoet (policy=none), of juist om zo’n mail te verwerpen (policy=reject). In het laatste geval hoeft ook niet altijd een bounce bericht te komen. Immers als de mail niet aan de voorwaarden voldoet, zal het afzender adres wel fake zijn. Het heeft geen nut daar naar toe te bouncen, omdat de bounce dan bij iemand terecht kan komen, die de spam mail niet zelf heeft verstuurd. Het verzendende domein geeft met zijn DMARC policy dus aan wat de ontvanger het beste met mail die niet aan de voorwaarden voldoet kan doen.

Hoe zorg je nu dat je mail door deze filtering heen komt? door de te zorgen dat je SPF en DKIM goed zijn geconfigureerd voor het domein waarvandaan je verzendt. Is het je eigen domein, dan is dat je eigen verantwoordelijkheid of die van je hoster. Verstuur je met @ziggo.nl via de ziggo mailserver dan is dat de verantwoordelijkheid van Ziggo. Ziggo doet dat sinds enige tijd netjes, dus ik vermoed dat we hier niet over een ziggo mail adres praten. Misschien kan SixtySpecial nog toelichten hoe dat zit.

Het verzenden van een @pietje.nl mail via de smtp van ziggo kan bijvoorbeeld voor problemen zorgen als pietje.nl de ziggo mail server niet in zijn SPF record heeft geautoriseerd.

Je kan je DMARC natuurlijk minder streng afregelen maar daarmee verliest het zijn kracht. Je moet gewoon zorgen dat je verzonden mail via de juiste server, met de juiste configuratie wordt verzonden.

Bekijk in context

efok
Expert
Expert
  • 2946Reacties
  • 151Oplossingen
  • 933Likes
36 Reacties 36

Even los van DMARC details. Er moet een Bounce komen als om wat voor reden dan ook aflevering niet kan plaatsvinden. Dat klopt dus niet. En het is buitengewoon vervelend te moeten constateren dat er zomaar berichten in een afvalputje terecht kunnen komen., zonder dat iemand daar iets van merkt.
Gr Han
hanh
Oud Community-lid
  • 17054Reacties
  • 660Oplossingen
  • 3441Likes

Hallo Hanh,

Dank voor je reactie. Ik ben niet zo'n techneut, maar weet wel dat er eigenlijk altijd wel iets van een bounce melding hoort te komen. Heb die vraag ook gesteld aan de afzenders. Maar tot nu toe lijkt het niet zo te zijn. En ja, dat maakt me inderdaad bezorgt, want hoe kan ik er nu nog van overtuigd zijn dat alle mail die aan mij gestuurd wordt, ook daadwerkelijk aan komt...
SixtySpecial
topicstarter
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes

SixtySpecial wrote:


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.


Renato.


Welke provider is dit, daar zullen hun klanten toch wel meer problemen mee ervaren.


"want hoe kan ik er nu nog van overtuigd zijn dat alle mail die aan mij gestuurd wordt, ook daadwerkelijk aan komt... "

Tsja, als een provider het tegenhoudt dan stopt het, Dan moet je iedereen een brief per snail mail versturen dat je een email verstuurd hebt.
Ze moeten natuurlijk aangeven aan de verzender dat mail niet verstuurd wordt .
Steefb
Expert
Expert
  • 7716Reacties
  • 1341Oplossingen
  • 2147Likes

Hoi Steefb,

Dank voor je reactie. Op zich klopt het wel wat je zegt, maar als je in de overtuiging leeft dat jouw mails wél zijn verstuurd en dat dat wordt ondersteund door het feit dat de mail bij anderen wel aankomt (omdat die antwoorden bijv.) dan wordt het lastig.

Ik ben met name benieuwd naar dat extra beveiligingsprotocol en of iemand kan bevestigen dat dit problemen veroorzaakt of kan veroorzaken. Nu lijkt het er op dat het probleem bij mij zit, maar ik weet niet waar ik moet zoeken.
SixtySpecial
topicstarter
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes

Ben geen specialist op dit terrein. DMARC wordt gebruikt om te bepalen
of de afzender nog klopt met het domain waar een Email van afkomstig is.
SPAMMers herschrijven dat adres om anoniem te kunnen blijven.
Daar is het een remedie tegen.
Volgens mij is Ziggo verantwoordelijk voor de controle en de beslissing wat te doen
als een bericht niet aan de eisen zou voldoen.
Er kunnen fouten in de controle sluipen.
Die fout hoeft niet per se bij Ziggo te liggen maar kan ook aan een niet correct DNS record liggen dat voor DMARC wordt onderhouden door de verzendende partij.
Je hebt de Email Header nodig om meer te weten over hoe het gegaan is, maar daar heb je het bericht voor nodig. Dat is weg.

Hoe dan ook: Ziggo zou vlgs mij een Bounce moeten geven.
Correct me if I'm wrong.

Het probleem ligt niet aan jou.
Gr Han

https://en.wikipedia.org/wiki/DMARC
hanh
Oud Community-lid
  • 17054Reacties
  • 660Oplossingen
  • 3441Likes

hanh Volgens mij heeft TS het niet over Ziggo als verzendende provider

"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. "
Steefb
Expert
Expert
  • 7716Reacties
  • 1341Oplossingen
  • 2147Likes

Steefb wrote:
hanh Volgens mij heeft TS het niet over Ziggo als verzendende provider

"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. "

Dat klopt en dat weet ik.
In wat ik schreef gaat het over Ziggo als ontvangende partij, die controle uitvoert op een binnengekomen bericht voor een klant en na controle niet aflevert en ook geen Bounce geeft, wat m.i wel zou moeten.
Gr Han
hanh
Oud Community-lid
  • 17054Reacties
  • 660Oplossingen
  • 3441Likes

Dank heren, voor de inmenging...

Ik heb wel het originele bounce-rapport kunnen krijgen van de dame in kwestie. Ik maak er uit op dat inderdaad het DMARC protocol er mee te maken heeft, maar kan er verder geen zinnig antwoord uit destilleren. Jullie misschien?

--
This is the mail system at host outbound1.mail.transip.nl.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own text from the attached returned message.

The mail system

: host mx.mnd.mail.iss.as9143.net[212.54.34.8] said: 554
5.2.0 MXIN603 DMARC validation failed.
;id=aFAfgERxOaZUbaFAfgMYxM;sid=aFAfgERxOaZUb;mta=mx1.mnd;d=20181221;t=082433[CET];ipsrc=149.210.149.72;
(in reply to end of DATA command)
--
(Die ### heb ik er neergezet. Geloof niet dat mijn mailadres van belang is voor het bedenken van een mogelijke oplossing 😉
SixtySpecial
topicstarter
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes

Hm. Niet helemaal goed.
en ook geen Bounce geeft, wat m.i wel zou moeten.


Dat kan moeilijk op een afzendadres dat vlgs Ziggo al dan niet terecht niet kan kloppen.
Hoe voorziet DMARC hierin. Geen idee.
efok
Werp 'ns wat licht in de duisternis, alsjeblieft.

Gr Han
hanh
Oud Community-lid
  • 17054Reacties
  • 660Oplossingen
  • 3441Likes

Ik meen hier net de bounce melding gepost te hebben, maar zie die niet terug. Het deel waarin ik beweerde dat er geen bounce melding volgde klopt dus bij nader inzien niet. Maar dat een bounce volgt als gevolg van DMARC is denk ik voor velen nog onbekende materie.

Mag je hier overigens wel bounce meldingen plakken?
SixtySpecial
topicstarter
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes

Ik zal het proberen uit te leggen, dit is complexe materie.
Omdat de spam tegenwoordig de spuigaten uitloopt zijn technieken bedacht om te identificeren of de afzender van een e-mail wel legitiem is. Spammers verzonden immers vaak mail zogenaamd afkomstig van bijvoorbeeld je bank.

De eerste methode is een zogenaamd SPF record aan je domein toevoegen. Hierin word bepaald welke mailservers mail mogen versturen voor een bepaald domein (bijv pietje.nl). Mailservers die niet op de SPF lijst staan mogen geen mail verzenden van pietje.nl. Gebeurt dat toch, dan kan deze mail dus gefilterd worden. Deze records staan op de DNS server voor dat domein, en zijn dus door iedereen op te vragen.

De tweede methode is DKIM. Daarmee wordt een digitale handtekening/sleutel aan je mail gehangen, waarvan de echtheid valt te controleren. De digitale handekening wordt eveneens gevalideerd aan de hand van een DNS record van je domein. Deze handtekening kan alleen door de echte mailserver voor bv pietje.nl juist worden gegenereerd.

Deze 2 methodes zijn relatief jonge toevoegingen aan het mailprotocol. Wat is dan DMARC? DMARC is een policy, zeg maar een beslisregel. Het verzendede domein bepaalt hier mee wat de ontvanger met de mail moet die niet aan SPF/DKIM voldoet. Verder kan DMARC een check doen op zogenaamde alignment. https://en.m.wikipedia.org/wiki/DMARC

DMARC zou kunnen bepalen dat een ontvangende mailserver een mail die niet aan de voorwaarden voldoet in quarantaine plaatst (policy=quarantaine) Daarop volgt geen bounce-bericht, want de mail is immers geaccepteerd door de ontvangende server. De ontvangende partij isoleert bij quarantaine de mail voor de ontvanger, totdat bijvoorbeeld de beheerder van de mailserver besluit deze alsnog vrij te geven, of in het geval van spam, te deleten.

DMARC kan ook definiëren om een mail domweg door de te laten die niet aan de voorwaarden voldoet (policy=none), of juist om zo’n mail te verwerpen (policy=reject). In het laatste geval hoeft ook niet altijd een bounce bericht te komen. Immers als de mail niet aan de voorwaarden voldoet, zal het afzender adres wel fake zijn. Het heeft geen nut daar naar toe te bouncen, omdat de bounce dan bij iemand terecht kan komen, die de spam mail niet zelf heeft verstuurd. Het verzendende domein geeft met zijn DMARC policy dus aan wat de ontvanger het beste met mail die niet aan de voorwaarden voldoet kan doen.

Hoe zorg je nu dat je mail door deze filtering heen komt? door de te zorgen dat je SPF en DKIM goed zijn geconfigureerd voor het domein waarvandaan je verzendt. Is het je eigen domein, dan is dat je eigen verantwoordelijkheid of die van je hoster. Verstuur je met @ziggo.nl via de ziggo mailserver dan is dat de verantwoordelijkheid van Ziggo. Ziggo doet dat sinds enige tijd netjes, dus ik vermoed dat we hier niet over een ziggo mail adres praten. Misschien kan SixtySpecial nog toelichten hoe dat zit.

Het verzenden van een @pietje.nl mail via de smtp van ziggo kan bijvoorbeeld voor problemen zorgen als pietje.nl de ziggo mail server niet in zijn SPF record heeft geautoriseerd.

Je kan je DMARC natuurlijk minder streng afregelen maar daarmee verliest het zijn kracht. Je moet gewoon zorgen dat je verzonden mail via de juiste server, met de juiste configuratie wordt verzonden.

Bekijk in context

efok
Expert
Expert
  • 2946Reacties
  • 151Oplossingen
  • 933Likes

efok, dank voor je uitgebreide en heldere toelichting. Op deze manier is het voor mij ook duidelijk wat er gebeurt. Zoals ik in m'n oorspronkelijke bericht aangaf gebruik ik een paar email aliassen op een eigen domeinnaam. Deze laat ik mail afvangen en doorsturen naar mijn @ziggo.nl mailbox. Dat werkt voor mij prettig en leverde tot voor kort geen problemen. Ik snap dat dit met toenemende spam en fake adressen tricky begint te worden. Wil uiteindelijk van de aliassen ook wel mailboxen maken, maar zover is het nog niet. Tot die tijd hoop ik met de huidige configuratie te kunnen blijven werken.

Inmiddels heb ik ook mijn eigen host om advies gevraagd en zij hebben me enkele regels aan m'n dns laten toevoegen, waarmee ook de doorgestuurde mails richting Ziggo als het goed is nu als veilig, geverifieerd, bestaand (of wat ze dan ook communiceren) worden bestempeld. Het is even afwachten of daarmee mijn problemen verholpen zijn. DNS records hebben even tijd nodig om te vernieuwen en daarnaast verwacht ik vandaag geen mail meer van de adressen waarmee de 'ellende' begon. Tot zover dank allen!
SixtySpecial
topicstarter
Meedenker
  • 12Reacties
  • 0Oplossingen
  • 0Likes

efok Thanks! Han

Noot het was voor mij de moeite waard. Maar zeker ook voor TS die met Email dingen bezig blijkt te zijn, waar we nog niks over wisten op grond van de eerste probleemstelling. Dat was ook niet nodig. Dit is simpelweg toeval.
hanh
Oud Community-lid
  • 17054Reacties
  • 660Oplossingen
  • 3441Likes

Het probleem wordt veroorzaakt door de SPF instelling van Ziggo voor quicknet.nl.:
v=spf1 include:smtp.spf.ziggo.nl -all

Een ontvangende mail server controleert of de mail is verzonden door een server die is geauthoriseerd door Ziggo. Dat staat in de include: smtp.spf.ziggo.nl:
v=spf1 ip4:212.54.32.0/19 ~all

Dus een mail server met een IP adres in de reeks 212.54.nnn.nnn mag namens Ziggo mail verzenden. Als het verzendende IP adres anders is dan geeft ~all aan dat de ontvangende mail server zelf moet kijken of hij de mail accepteert maar eventueel extra spam controles moet doen.
Het resultaat van de include is dan geen "pass" maar een "misschien". Normaal wordt de mail dan nog wel afgeleverd.
Maar omdat de include geen pass geeft wordt de -all ook bekeken en de min betekent als er geen correct IP adres is gebruikt dan wordt de ontvangende mail server geadviseerd om de mail te weigeren.
Het DMARC record van Ziggo zegt nog een keer expliciet dat je een mail zou moeten weigeren als de SPF controle niet goed gaat en daarom zie je in de geweigerde mail iets over DMARC failed.

Het is de vraag of Ziggo het zo bedoeld heeft. Als je namelijk het SPF record van ziggo.nl bekijkt dan eindigt die op ~all, ofwel kijk goed maar je mag wel afleveren. Alleen bij quicknet.nl eindig je in -all. Het is ook raar om een include te doen die eindigt op ~all want die is nu niet de laatste test van de SPF.

Dit gaat dus niet fout als je een mail rechtstreeks verstuurt vanaf een quicknet.nl adres maar wel als die mail door een ander mail systeem wordt doorgestuurd. De mail server die daar weer achter zit krijgt dan een mail van de tussenliggende mail server en die verstuurt vanaf een niet Ziggo IP adres. Het gaat ook niet fout met een ziggo.nl adres omdat de SPF daar wel goed staat.

De oplossing is dus als Ziggo het SPF record voor quicknet.nl weer laat eindigen in ~all.

Verdrietig wordt je pas als je dit aanmeldt bij de Ziggo helpdesk. Je krijgt dan als antwoord dat de helpdesk dit niet ondersteund. (Huh, waar is een helpdesk dan voor?)
Je krijgt niet eens de gelegenheid om door te geven waar Ziggo een fout heeft gemaakt in hun configuratie.

Helaas moet ik zeggen uit eigen ervaring dat dit gedrag standaard is bij de Ziggo ondersteuning. Bij een overduidelijk probleem in het Ziggo netwerk waarbij een kleine groep gebruikers een storing heeft walsen ze over je heen en krijg je een eindeloze stroom monteurs die bij jou het modem vervangen, filtertje er in, filtertje er uit, kastje aan de weg vervangen, enzovoort maar niemand komt op het idee om de flap list te controleren en in het Head End iets bij te regelen.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

Hi kb1, lekkere binnenkomer heb je, welkom op onze Community en wat ben ik blij dat je je weg hierheen hebt gevonden!

Ik zet dit door naar de verantwoordelijke afdeling om jouw bevindingen te controleren en corrigeren (als dit inderdaad een fout is).
Mark Z
Community Moderator
Community Moderator
  • 5167Reacties
  • 588Oplossingen
  • 1864Likes

Goed gevonden.
Het is strikt genomen geen "fout". -all kan een bewuste keuze zijn. Lekker streng, waarmee je spammers de optie ontneemt om fake een quicknet adres te gebruiken. 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.

Het zal lastig worden al je gebruikers zodanig op te voeden dat ze alleen via de ziggo-servers verzenden, al zou dat wel het beste zijn. DKIM is dan ook mogelijk. Legio gebruikers verzenden waarschijnlijk via de Google smtp of weet ik wat, en dan wordt die mail er nu dus uit gefilterd. ~all is vriendelijker voor de gebruikers, maar dan wordt het voor spammers ook weer makkelijker een fake quicknet adres te gebruiken. Het is maar net welke policy je als provider wilt aanhangen.
Enige voorlichting naar de gebruikers om via de juiste smtp te verzenden is tegenwoordig eigenlijk een must, omdat bovenstaande mechanismen steeds belangrijker worden.
efok
Expert
Expert
  • 2946Reacties
  • 151Oplossingen
  • 933Likes

efok wrote:
Goed gevonden.
Het is strikt genomen geen "fout". -all kan een bewuste keuze zijn. Lekker streng, waarmee je spammers de optie ontneemt om fake een quicknet adres te gebruiken. 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.

Maar dan zou ik verwachten dat ze diezelfde regel toepassen op de @ziggo.nl, @home.nl, @upcmail.nl en al onze andere extensies.
Wat ik uit het bericht van kb1 begrijp is dat juist niet consequent.
Mark Z
Community Moderator
Community Moderator
  • 5167Reacties
  • 588Oplossingen
  • 1864Likes

Mark Ziggo wrote:

efok wrote:
Goed gevonden.
Het is strikt genomen geen "fout". -all kan een bewuste keuze zijn. Lekker streng, waarmee je spammers de optie ontneemt om fake een quicknet adres te gebruiken. 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.
Maar dan zou ik verwachten dat ze diezelfde regel toepassen op de @ziggo.nl, @home.nl, @upcmail.nl en al onze andere extensies.
Wat ik uit het bericht van kb1 begrijp is dat juist niet consequent.

Dat klopt het is zeker niet consequent.
efok
Expert
Expert
  • 2946Reacties
  • 151Oplossingen
  • 933Likes

Als je als gebruiker van een quicknet.nl (of ziggo.nl) mail adres een mail verzendt via een server van een andere provider (gmail, hotmail, kpn of anders) kun je verwachten dat jouw mails minder goed aankomen.
Er zijn echter hele goede redenen waarom je hier toch tegenaan loopt met gebruik van de originele ziggo mail servers. In mijn geval heeft elke quicknet.nl mail die ik verzend een automatische BCC naar mijn tweede email provider die dat dan weer forward naar een volgend email adres. Zo komen mijn verzonden emails altijd consequent terug. Dat ging dus de afgelopen 20 jaar prima tot ongeveer twee weken geleden...
Er zijn vele andere gebruikers die een forward hebben ingesteld om allerlei redenen.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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.
RobHotton
Ontdekker
  • 5Reacties
  • 1Oplossingen
  • 1Likes

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.
Mark Z
Community Moderator
Community Moderator
  • 5167Reacties
  • 588Oplossingen
  • 1864Likes

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.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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
Hoot_Posthorn
Raadgever
  • 90Reacties
  • 4Oplossingen
  • 57Likes



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.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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
Hoot_Posthorn
Raadgever
  • 90Reacties
  • 4Oplossingen
  • 57Likes

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.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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.
Babbel
Gedreven Raadgever
  • 230Reacties
  • 5Oplossingen
  • 164Likes

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?
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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

==========================================================
Babbel
Gedreven Raadgever
  • 230Reacties
  • 5Oplossingen
  • 164Likes

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
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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.)
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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?
Wlmpie
Gedreven Raadgever
  • 419Reacties
  • 9Oplossingen
  • 123Likes

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
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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...
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

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.
efok
Expert
Expert
  • 2946Reacties
  • 151Oplossingen
  • 933Likes

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.
kb1
Gedreven Liefhebber
  • 84Reacties
  • 2Oplossingen
  • 60Likes

Uitgelicht topic