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

[SixtySpecial]

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.

[Mark]

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.

[hanh]

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

[SixtySpecial]

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

[Steefb]

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 .

[SixtySpecial]

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.

[hanh]

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

[Steefb]

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

[hanh]

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

[SixtySpecial]

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 😉

[hanh]

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

[SixtySpecial]

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?

[efok · Accepted solution]

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.

[SixtySpecial]

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!

[hanh]

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.

[kb1]

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.

[Mark]

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

[efok]

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.

[Mark]

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.

[efok]

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.

[kb1]

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.