kb1
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

all hosts for 'ziggo.nl' have been failing for a long time (and retry time not reached)

Deze week was het weer zo ver. Van de e-mails verzonden namens de atletiekvereniging werden er een aantal ge-bounced (niet afgeleverd.) De melding in het bounce bericht was

all hosts for 'ziggo.nl' have been failing for a long time (and retry time not reached)

De Status code die werd vermeld was 5.0.0

Een Status die begint met een 5. betekent dat er iets is fout gegaan. De twee cijfers daarna geven een indicatie wat er dan fout gaat. Een status 5.1.1 betekent bijvoorbeeld dat het mail adres niet (meer) bestaat. Een status code 5.0.0 geeft echter geen enkele indicatie wat er fout is gegaan.

De foutboodschap zelf is al even nietszeggend. All hosts (welke dan?) for 'ziggo.nl' have been failing for a long time (hoe lang?) and retry time not reached?

Als verzender van legitieme e-mail word je hiermee flink het bos in gestuurd.

Als de bedoeling is om een beroeps spammer niet wijzer te maken heeft het ook weinig zin. Die weten precies wat er fout is gegaan en schakelen snel over naar paden die nog wel werken.

 

In de bounce berichten was er één die wel een zinvolle foutboodschap meegaf:

Diagnostic-Code: smtp; 550 mx4.tb.mail.iss.as9143.net mx4.tb.mail.iss.as9143.net MXIN103 
Your IP xxx.xxx.xxx.86 is in RBL. Please see http://csi.cloudmark.com/reset-request/?ip=xxx.xxx.xxx.86
;id=BY7amq3BfFSZf;sid=BY7amq3BfFSZf;mta=mx4.tb;d=20210805;t=094854[CET];ipsrc=xxx.xxx.xxx.86;

Dit bericht komt van Cloudmark. Cloudmark houdt een zwarte lijst (blacklist) bij van ip adressen met een slechte reputatie. In tegenstelling tot de vele andere blacklists is de lijst van Cloudmark niet openbaar. Alleen providers zoals Ziggo en KPN die gebruik maken van Cloudmark hebben toegang tot de lijst. Als verzender van e-mail weet je dus ook niet of een ip-address waarvan je via jouw e-mail provider gebruik maakt op die lijst staat, totdat je plotseling bounces terug krijgt.

Heb je een bounce mail met een Cloudmark foutboodschap dan kun je de link hierin openen en een formulier invullen om het ip-address van de zwarte lijst af te krijgen.

 

Het bleek in ons geval te gaan om één ip-address (eindigend op .86) van de mail provider die de atletiekvereniging gebruikt. De provider heeft een heel stel mail servers en een daarvan is waarschijnlijk gebruikt voor spam activiteiten van een van de vele klanten van de provider. Als onze mail provider dit door krijgt zal hij misschien ook zelf contact opnemen met Cloudmark om zijn ip-address van de zwarte lijst af te krijgen. De andere mails gericht aan Ziggo en KPN adressen gebruikten toevallig een ander mail server/ip-address en kwamen ongehinderd aan.

 

We kunnen veronderstellen dat de andere bounce mails met "All hosts for 'ziggo.nl' have been failing" ook zijn gebounced vanwege de Cloudmark vermelding. Vind je dan niet toevallig die ene mail met de Cloudmark boodschap dan tast je volledig in het duister. In het bounce bericht kun je niet eens het foute ip-address terugvinden van de mail server die het originele bericht heeft verzonden.

 

Het is op zich al onbehoorlijk van Cloudmark om hun zwarte lijst geheim te houden. Het is nog veel onbehoorlijker om de goedwillende mail verzenders die vaak buiten hun schuld worden getroffen door deze zwarte lijst in het duister te laten over waarom hun mails worden geweigerd.

Wat het nog een keer erger maakt is dat de verzender van de e-mail helemaal geen relatie hoeft te hebben met in dit geval Ziggo die de mail weigert. Als verzender moet je dan potentieel een klacht indienen bij alle mail providers die mail weigeren (Ziggo, KPN, ...) Deze providers gaan echter niet over de mail provider waarvan het ip-address op de zwarte lijst staat van Cloudmark. Als verzender kom je daar met deze foutboodschap echter niet achter, als je uit deze boodschap al kunt destilleren wat er echt aan de hand is.

 

Zie je deze boodschap in een bounce mail gericht aan een ziggo.nl, quicknet.nl, enz. adres - stuur dan een e-mail naar abuse@ziggo.nl met daarin een kopie van de bounce mail(s). Als ze vriendelijk zijn kunnen ze namens jou Cloudmark vragen om het ip-address te resetten die op de zwarte lijst staat.

Hoe je dit meldt bij KPN weet ik niet. Bij Tele2 is het lastiger, daar moet je lid worden van de Tele2 community en daarin jouw klacht melden.

 

Een betere oplossing is natuurlijk als Ziggo de bounce tekst aanpast. Minimaal moet daar in staan waarom de e-mail is geweigerd met vermelding van het ip-address die op de zwarte lijst staat. Als er een Cloudmark boodschap beschikbaar is dan hoort die in het bounce bericht te staan. Wijzig ook de 5.0.0. bounce status naar een waarde die beter overeenkomt met de reden van de weigering.

 

 

 

 

1 Geaccepteerde oplossing

Geaccepteerde oplossingen
kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

De boodschap: "all hosts for 'ziggo.nl' have been failing for a long time (and retry time not reached)"

komt niet van Ziggo maar van de mail provider die de mail verzendt. Om dit te laten oplossen moet je contact opnemen met de verzendende mail provider.

In de meeste andere gevallen waar een e-mail niet kan worden afgeleverd aan een Ziggo adres kun je mailen naar abuse@ziggo.nl en een kopie van de mail bijsluiten.

 

De boodschap "all hosts..." komt uit het mail software pakket Exim die door de verzendende mail provider wordt gebruikt. De oorzaak is bijna altijd dat een van de mail servers van de provider op een zwarte lijst is terecht gekomen. Dat gebeurt bijvoorbeeld als een of meer gebruikers van de mail provider veel mails sturen die als spam worden aangemerkt. De mail provider moet actie nemen om van die zwarte lijst af te komen.

 

Als Ziggo merkt dat een mail server die naar een Ziggo adres wil sturen op een zwarte lijst staat dan breekt Ziggo direct de poging af met een 550 status en een boodschap die aangeeft dat de mail server op de zwarte lijst staat. Die boodschap krijg je te zien in de geweigerde mail.

Exim ziet dat Ziggo mails weigert van de mail server en besluit na korte of lange tijd om nieuwe mails direct terug te sturen met een "all hosts..." boodschap. Als je dit ziet is de mail dus nooit bij Ziggo geweest.

 

Exim zal zo nu en dan een mail proberen te bezorgen om te kijken of het probleem is opgelost. Als Exim te snel besluit om mails direct terug te sturen kun je aan die mails ook niet zien wat de oorzaak is, op welke zwarte lijst de mail server staat. Dat is vervelend omdat je als verzender in het duister blijft.

 

Als de mail provider meerdere mail servers heeft kunnen andere mails nog wel bezorgd worden via servers die niet op een zwarte lijst staan. Je kunt een mail die terugkomt met "all hosts..." dus gewoon nog een keer proberen te verzenden met een redelijke kans op succes.

Bekijk in context

20 Reacties 20
efok
Expert
Expert
  • 3158Posts
  • 170Oplossingen
  • 1033Likes

De melding in het bounce bericht over de “all hosts” komt denk ik niet van Ziggo, maar van de mailserver van de atletiekvereniging die zijn berichten niet kwijt kan. Het bevreemd me dat je dan niet een duidelijkere melding terug krijgt, zoals je zelf ook constateert. Misschien is het zo dat als je op de cloudmark list staat, de Ziggo servers gewoon de connectie weigeren. Daarom de melding all hosts for ziggo.nl failed. Ze reageren gewoon niet. Aan de andere kant zeg je dat je een 5.0.0 krijgt. Komt die van de Ziggo server?

Ik ben het met je eens dat een nette foutmelding op zijn plek is, anders is er niets te troubleshooten. 

Kun je eens het hele bericht laten zien?

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

@efok 

Ik denk dat je gelijk hebt - de bounce messages komen van onze mail provider (Reporting-MTA:). In het geval waar de Cloudmark boodschap staat wordt als Remote-MTA de Ziggo mailserver aangegeven. In het "all hosts" geval ontbreekt de Remote-MTA regel.

Dat wijst er inderdaad op dat de Ziggo mail server niet meer wil praten met de verzendende mail server.

"Failing for a long time" is in dit geval een seconde, zoveel tijd zat er tussen de twee berichten.

 

De Ziggo server gooit dus gewoon direct de deur dicht voor ip-addressen die op een zwarte lijst staan. De boodschap "All hosts for 'ziggo.nl' have been failing" moet dus worden geïnterpreteerd als "de Ziggo mailservers willen jouw mail server niet meer kennen".

Nu zit je als verzender in de problemen want in de bounce message zie je niet welke mail server (ip-address) heeft geprobeerd om de Ziggo mail server te bereiken. Het is zelfs de vraag of abuse.ziggo.nl nog kan helpen want de mail server heeft de Ziggo server niet kunnen bereiken.

 

 

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pxxxxxxxx@ziggo.nl
    all hosts for 'ziggo.nl' have been failing for a long time (and retry time not reached)

 

Reporting-MTA: dns; se24-yh.route25.eu

Action: failed
Final-Recipient: rfc822;pxxxxxxxx@ziggo.nl
Status: 5.0.0

 

efok
Expert
Expert
  • 3158Posts
  • 170Oplossingen
  • 1033Likes

Ja, dat dacht ik dus ook. Maar zo is het mail systeem natuurlijk niet bedoeld. Je hoort een nette foutmelding te krijgen imho. Dit is lomp en arrogant gedrag.
De reporting MTA, zal de server zijn die Ziggo probeert te connecten toch? Ik zou dat toch eens aan abuse voorleggen. Het bijhorend IP staat verder nergens op een blacklist zo te zien.

Je kan ook nog eens kijken in de headers van mail die wel aankomt, wat de verzendende server is.

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

Als de hosting provider van de atletiekvereniging met 1 van zijn ip's op een zwarte lijst staat is het eigenlijk zijn taak om dat op te lossen.

Heeft hij die link al geprobeerd om het ip weer vrij te krijgen?

http://csi.cloudmark.com/reset-request/?ip=xxx.xxx.xxx.86

 Verder is het helaas niet alleen Cloudmark die met geheime blacklists werkt. Maar bij die andere krijg je wel een melding zoals je nu van Cloudmark erbij had staan.

Het betreffende ip met .86 op het eind kan ik nergens volledig zien dus heb ik verder niet kunnen kijken. Maar ik neem aan dat de anderen dat al gedaan hebben gezien de reacties.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

@efok, De reporting MTA is de server die de bounce message naar ons terugstuurt en niet de server die op de zwarte lijst staat. Het ip-address zit wel in dezelfde reeks.

@RichardDe oorzaak is inderdaad ontstaan bij de mailserver van de provider van de atletiekvereniging. De oorzaak is natuurlijk een spammer die ook bij deze provider zit of die iemand heeft gekraakt die bij deze provider zit. Deze provider heeft echter dezelfde uitdaging als wij - Ziggo wil niet meer met hun praten en vertelt niet waarom. Ze zullen dat bovendien ook ervaren van KPN en nog een aantal andere bestemmingen.

Als deze provider een support afdeling heeft die goed oplet komen ze er wel uit want dan letten ze ook op of hun mailservers voorkomen op blacklists. Ik was ze echter waarschijnlijk voor met een reset request aan Cloudmark, een kwartier na de bounce en Cloudmark reageerde 20 minuten later met een bevestiging dat het adres van de blacklist was afgehaald. Zonder die eerste mail met de Cloudmark boodschap had ik dat niet kunnen doen en eerdere keren had ik die melding ook niet. Die is toen wellicht naar een andere gebruiker gezonden.

Het issue is dus eigenlijk dat na de eerste bounce de Ziggo server dichtklapt en de bounce melding die de rapporterende mail server (reporting MTA) kan geven nietszeggend is omdat de Ziggo mailserver als Remote MTA geen response geeft.

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

@KB"want dan letten ze ook op of hun mailservers voorkomen op blacklists."

Klopt, maar zoals je ziet is dat niet altijd mogelijk omdat er enkele blacklists zijn die dus hun lijst geheim houden en dan merk je het pas als er mails terug komen of na klachten van klanten.


Het is snel genoeg gebeurt, zeker op shared hosting hoeft er maar een accountje gehackt te zijn of een lek stukje thema of plugin in Wordpress en kwaadwillenden spammen dan de boel plat. Daar kun je jezelf als hoster deels wel tegen beschermen (max. mails per dag) maar veelal kun je dan al hangen. Zeker als dat binnen een half jaar zeg toevallig een keer of 2 a 3 gebeurt.

Dan moet je zelf zien van die lijst af te komen, er is een link.

 

Dat ze Ziggo server meteen dicht klapt is normaal. Wij hebben op de server ook bepaalde lijsten die we controleren, als daar je ip op staat komt de mail niet binnen, werkt allemaal automatisch.

Inderdaad zeggen bounce meldingen niet altijd iets helaas. Als daar en in de server logs niets te zien is wordt het oplossen erg moeilijk.

MTA's en hun bescherming (noodzakelijk met hedendaagse spammers) kunnen wel eens voor aparte issues zorgen.

Ik hoop dat de atletiek hoster het op kan lossen met Cloudflare.

efok
Expert
Expert
  • 3158Posts
  • 170Oplossingen
  • 1033Likes

Hmm. Mijn mailserver werkt ook met RBL, maar geeft dan wel netjes terug dat het aankloppende IP op zo'n RBL staat, met foutmelding, zonder de email te accepteren.

Om maar gewoon niet thuis te geven, werkt een boel onduidelijkheden en verloren mail in de hand. Dat lijkt me toch niet de bedoeling?

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

Nee dat klopt zonder meer. Maar dat zie je dan ook terug in de log van de MTA en niet perse in de bounce mail.

Zal wel met anti-spam maatregelen te maken hebben. Tegenwoordig zie je ook bij steeds meer systemen dat de bounce berichten het originele bericht ook niet meer bevatten of bijna niets.

 

Spammers vonden het leuk om postbussen vol te spammen en dan een allerlei andere return adressen aan te geven zodat de bounces met origineel bericht overal terecht kwamen en je een grotere kans had op blacklists te komen staan.

Daarom is dat minimaal wat je in bounce messages en headers van mail ziet vaak.

Maar zoals je zelf al zei, in de log van de MTA zelf moet dat wel zichtbaar zijn. Alleen bij Microsoft kan het voorkomen dat ie in de spam komt en je in de MTA log alleen ziet dat je messages "queued for delivery" zijn, hetgeen je altijd al te zien krijgt bij hun. 😉

Echter spamfolder is geen weigering dus dat mag.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

De boodschap "all hosts for 'ziggo.nl' have been failing for a long time (and retry time not reached)" blijkt te komen uit Exim Internet Mailer, het mail verzend pakket dat de provider van de atletiek vereniging gebruikt. Exim heeft blijkbaar besloten dat de Ziggo mail server "te lang" niet reageert en bounced nieuwe mails zonder het zelfs te proberen (of maximaal 1 keer). "Te lang" kan in dit geval wel eens heel kort zijn want er zit 20 seconden tussen de bounce met de Cloudmark response en de volgende bounce met "All hosts...". Het is dus zelfs mogelijk dat Exim niet eens heeft geprobeerd om af te leveren bij Ziggo nadat de eerste keer een aflever fout is opgetreden.

 

Ik heb de bounce mails naar abuse@ziggo.nl gestuurd. In een eerste reactie bevestigen ze dat ze met de bounce mail met "All hosts..." niets kunnen vinden in de Ziggo log files. Ze zijn (nog) niet duidelijk over het blokkeren van mail servers die op een blacklist staan en waarom er één Cloudmark boodschap wel is doorgekomen. Ze geven aan dat er relatief veel spam binnenkomt via de mail provider van de atletiek vereniging. Tja, dat is een internet hoster met heel veel klanten en daar zit vast wel kaf tussen het koren. Het advies van abuse@ziggo.nl om zorgvuldig met mail lijsten om te gaan en te voorkomen dat de ontvangers de mail inhoud aanmerken als spam is op zich correct maar helaas onbruikbaar omdat we het gedrag van de andere gebruikers van onze mail provider niet kunnen beïnvloeden.

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

You dat "all hosts" komt zeker van de verzendende mailserver af, dat werd eerder ook al gezegd dacht ik.

Dat gaat Ziggo dus ook niet in de logs terug vinden.

Hoe groter je bent als hoster, hoe meer je moet opletten, er zijn meerdere maatregelen nodig om te zorgen dat er niet te veel naar buiten kan aan spam als er toch een account gehackt zou zijn. Het blijft goed monitoren.

Waarom Exim zo snel reageert is mij een raadsel of het moet zijn de mails langer al in de queue van Exim staan. Deze probeert mails te versturen, als dat niet lukt gaan ze de queue (wachtrij) in en wordt het later nog eens geprobeerd. Als ik me niet vergis na 72 uur voor de laatste keer, als de geadresseerde of geadresseerde server dan niet bereikt kan worden dan krijg je die melding te zien.

Als dit meteen met nieuwe mails gebeurt die niet in de queue staan kan dat ook op connection timeouts wijzen veroorzaakt door een blokkade (bijv. blacklist of firewall issue).

Deze regel moet je dan ook niet gebruiken om te troubleshooten, maar dat kon jij niet weten. Het is slechts een melding dat mail niet aan komt wegens dat er iets niet bereikbaar is.

De hoster van de atletiekvereniging moet hier zelf slim genoeg voor zijn, zeker als hij wat groter is moet hij kunnen ontdekken waar het probleem ligt, gecombineerd met die Cloudlinux melding.

 

Exim is overigens voor de meeste hosting providers de standaard mailserver die gebruikt wordt.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

Exim beschouwt deze situatie als een probleem met een remote mail server. Dat betekent wel dat de Ziggo mail server dat triggert, bijvoorbeeld door de sessie direct te sluiten als Exim aanklopt met een ip-address die bij Ziggo gesignaleerd staat als fout.

Exim retried een aantal keren afhankelijk van de configuratie en het soort foutsituatie totdat de maximale retry tijd (cut off time) is bereikt. Komen er dan nog nieuwe e-mails binnen dan worden die direct gebounced zonder ze naar Ziggo te sturen en dat geeft de "all hosts..." melding. "(and retry time not reached)" zegt hier dat Exim niet heeft gewacht op het aflopen van een retry timer. De Ziggo mailserver staat bij Exim echter nog wel op een retry lijst (ook na het bereiken van de cut off time). Elke keer dat die timer afloopt stuurt Exim één mail door naar Ziggo. Gaat dat goed dan is de situatie weer hersteld. Gaat het fout dan bouncen nieuwe mails opnieuw direct.

Ik vermoed dat de mail met de Cloudmark bounce net degene kan zijn geweest die is doorgelaten door Exim en waar Ziggo de bounce boodschap voor heeft gezet. Daarna was de Ziggo mailserver het weer zat en blokkeerde de volgende  verzoeken vanaf het foute ip-address.

Ik denk ook dat de cut off time wel langer zal zijn en dat het ip-address al langer problemen had. De situatie is uiteindelijk opgelost doordat ik een Cloudmark reset heb aangevraagd. Bij de Ziggo mailserver was daarna de signalering opgeheven en Exim vond bij de volgende poging geen probleem meer.

 

Ik heb ook aan onze mail provider hierover vragen gesteld en ik ben benieuwd waar ze mee komen...

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

abuse@ziggo.nl bevestigd net dat de Ziggo mail server een verzoek van een ip-address die op een zwarte lijst staat zal beantwoorden met een reject status : 550: <your ip is in RBL + RBL delist info>. Dit wordt gedaan na de connect en voor de helo/ehlo stage, dus nog voordat de servers mail informatie gaan uitwisselen.

 

Doordat Ziggo al zo vroeg de sessie afsluit is er geen verdere informatie beschikbaar in de Ziggo log files.

 

Het lijkt er op dat Exim de 550 reject status opvat als een mail server probleem en na het bereiken van de cut off time nieuwe e-mails bounced zonder zelfs contact op te nemen met de Ziggo server met als gevolg de "all hosts..." melding.

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

"reject status : 550: <your ip is in RBL + RBL delist info>."

Nou... bijna. Bij gebruik van de "geheime" blacklist of handmatige blokkade komt er alleen te staan dat het ip geblokkeerd is maar wordt er geen delist info bij geleverd. Dus dat + RBL delist info is alleen van toepassing bij de standaard gebruikte lijsten. En dat is uit eigen ervaring met Ziggo.

Anyway, dat zou dan dus in de logfiles van de atletiek provider te zien moeten zijn. Dat er niet meer in de Ziggo logfiles te zien is dat is logisch.

Het is echter ook een feit dat de mailserver van de atletiekvereniging er geen verbinding (meer) mee krijgt, en dan nog het aparte cloudflare verhaal.

 

Die laatste alinea wat je schrijft is met Exim niet zomaar het geval. Tenzij jij zelf kunt kijken wat de hoster van de atletiekvereniging op dat moment nog in de queue heeft staan. En daarbij is het dus nog niet gezegd dat Exim het na een bepaalde tijd nog eens probeert of inderdaad ermee stopt, afhankelijk van de instelling.

 

Maar nogmaals, dit is een zaak voor de hosting provider van de atletiekvereniging, die moet dat kunnen oplossen, hij heeft toegang tot de Exim mailqueue en alle Exim logfiles en daar moet gewoon meer in te vinden zijn.

 

Edit:

Tip! Ga eens naar https://www.mail-tester.com/ dan zie je daar een raar mail adres van hun, stuur een mail vanuit de atletiekvereniging daar naar toe.

Even later kun je op die pagina het resultaat zien. Als het goed is moet dat 10/10 zijn of minstens 9/10.

Als het lager is, zeker als het rond de 5 of 6 is of lager, dan zijn er zaken niet goed geconfigureerd.

Maar ok dat moet je hoster ook weten, ook deze pagina moet hem bekend zijn.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

Quote van abuse@ziggo.nl: "Bij de meeste rbl’s vertellen ze je niet precies waarom je geblacklist was maar geven ze je wel de kans om te delisten".

Als Ziggo je zelf handmatig blokkeert staat er dus geen delist info bij. Dan moet je dus bij abuse@ziggo.nl zijn.

 

Uit het gedrag van Exim in ons geval en ondersteund door hun documentatie maak ik op dat Exim na de eerste 550 ten gevolge van de (Cloudmark) blacklisting de e-mail ofwel retried dan wel (na eventueel een aantal retries) bounced met de melding van de Ziggo mailserver. Een Cloudmark boodschap met delist informatie wordt met de bounce afgeleverd.

Na een langere tijd - uren, dagen? - wordt de cut off time van Exim bereikt. Volgende nieuwe e-mails worden nu zonder meer gebounced met "all hosts...". Hierin staat geen informatie van de Ziggo mail server want de mail is daar nooit geweest. Telkens na het aflopen van een retry timer (van enkele seconden of minuten?) probeert Exim nu één mail te verzenden. Zo lang ze op de blacklist staan gaat dat mislukken en worden volgende e-mails weer direct gebounced.

"retry time not reached" geeft dus niet aan dat Exim het als een tijdelijk probleem beschouwd en later opnieuw gaat proberen maar betekent - je krijgt nu al een permanente bounce en Exim wacht niet op de retry timer om jouw mail opnieuw te proberen. Met een tijdelijk probleem zou je een 4.x.x status krijgen maar de "all hosts..."melding komt met een permanente 5.0.0 status.

 

Ik heb nog geen reactie van onze mail provider hierover.

 

De tip https://www.mail-tester.com/ is een goede als je twijfelt of de bulk mails die je verzendt er goed uit zien. Je krijgt veel praktische aanwijzingen om te verbeteren via deze link. Zorg altijd dat jouw eigen mailingen ok zijn.

In ons geval met een shared mail provider is het niet de oplossing. Onze score is prima maar het zijn de mailingen van sommige andere gebruikers van de mail provider die de blacklisting veroorzaken.

 

Andere mail test links:

https://www.checktls.com/TestReceiver - test het aanmelden bij de remote mail server en geeft details over encryptie en aanmeld protocol.

check-auth@verifier.port25.com - stuur je mail naar dit adres en je krijgt een gedetailleerde analyse van DKIM, SPF, DMARC en IPREV status van jouw mail.

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

Ik ben het niet eens met je verhaal over mail tester. Ik doe zelf aan shared hosting en het is wel degelijk goed te gebruiken om te testen of mail goed verzonden wordt en niet alleen voor bulk mailings.
Testers zijn nooit oplossingen, maar aanduidingen waar het mis kan zijn.

De andere testers zijn ook prima te gebruiken. Als de score echter goed is, weet de hoster in elk geval dat de instellingen oke zijn. Maar het kunnen juist bepaalde foute instellingen zijn die er voor zorgen dat men op een blacklist komt of mails gewoon geweigerd worden. Vandaar de tip over die test.

 

"Ik heb nog geen reactie van onze mail provider hierover."

Dat zullen we dan moeten afwachten, want zoals gezegd moet er meer te vinden zijn in de logs en eventueel de queue. Want Exim zal niet definitief stoppen met verzenden.

Op een gegeven moment wordt deze retry timer ook weer gecleared, het me niet bekend hoe lang dit precies duurt, zal ergens in de Exim docs staan.

Deze timer kun je (je hoster) echter ook handmatig clearen, maar dat is bijzaak.

Ben benieuwd wat hij kan vinden.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

Wat betreft mail tester wil ik aangeven dat het "in ons geval" niet relevant is. We scoren hierop uitstekend en dat deden we altijd al. De blacklisting is veroorzaakt door andere gebruikers (of misbruikers) van onze shared hoster.

Dat gezegd hebbende blijft mail tester een prima tool voor het vooraf beoordelen van bulk mail.

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

Onze mail provider kwam na 11 dagen met een eerste reactie. Ze blijken niet te zijn geabonneerd op blacklist notificatie van Cloudmark. Ze maken gebruik van SpamExperts die een geblacklist ip-address 24 uur niet gebruikt. Hoe dat helpt om dat ip-address van de blacklist af te krijgen is mij niet duidelijk.

Ze begrijpen het probleem nog niet echt door aan te geven dat de bounce boodschap van de ontvangende mail server af komt wat duidelijk niet zo is in dit geval. Wordt vervolgd...

kb1
topicstarter
Gedreven Liefhebber
  • 103Posts
  • 3Oplossingen
  • 67Likes

Een update van onze mail provider. Het blijkt dat er maar een korte periode van verstoring is geweest toen Exim de "all hosts..." boodschap naar ons verstuurde. Mijn conclusie is dat Exim dus (bijna?) direct na de eerste 550 reply van Ziggo is gestopt met aanbieden van mails aan Ziggo en alle volgende mails heeft gebounced met "all hosts...". Ik heb de provider gevraagd om daar verder naar te kijken...

Deze strategie ontneemt immers de goedwillende gebruikers de informatie waarom de mails worden gebounced. Een vriendelijker instelling zou enige tijd (uren?) de bounce van Ziggo doorgeven en pas daarna overgaan op de "all hosts..." melding. Dat geeft de mail provider ook de mogelijkheid om intussen de blacklisting op te heffen.

De mail provider geeft verder aan dat het nu mogelijk is voor hun om te abonneren op blacklistings van hun servers bij Cloudmark en ze gaan hierop actie nemen.

Ze zeggen verder dat het oplossen van een blacklisting nog steeds handwerk is. Ook zij moeten een verzoek doen om de listing te laten verwijderen.

 

Richard G.
Gedreven Raadgever
  • 345Posts
  • 25Oplossingen
  • 120Likes

Ik ga even verder niet in op wat de hoster zegt over korte of lange tijd.
Er zijn inderdaad blacklists, waarbij het oplossen (delisten) handwerk is, zoals by Symantic, Cloudmark en OpenSRS. Nadeel is dat bijv. OpenSRS geen publieke lijst heeft en je kunt het ook niet op hun site opzoeken. Dus dat vergt minstens een email (of 2).

Ziggo maakt in elk geval gebruik van OpenSRS en zo te zien ook van Cloudmark. Van KPN weet ik dat ze Symantic gebruiken of gebruikten. Het werk wat er in gaat steken valt in principe best mee als je de zaken goed voor elkaar hebt. Maar het is wel handmatig ja.

Dat maakt het soms wel ietwat lastig voor hosters, maar ik blijf van mening dat het wel veel te lang geduurd heeft voordat ze voor jou als klant actie zijn gaan ondernemen.
Maar goed, als het maar opgelost wordt, dat is het belangrijkst.

Uitgelicht topic