Email met enige regelmaat op blacklist

[Basto]

Al jaren heb ik het onderhoud/beheer van mijn website bij een partij ondergebracht. Deze partij regelt ook mijn email.

In de begin jaren ging dit goed maar de laatste 2~3 jaar heb ik met enige regelmaat dat (een deel van) mijn email niet aankomt omdat ik dan op een blacklist sta. In het begin was dit 1x per jaar, inmiddels ongeveer elke 2 tot 3 maanden. Dit lijkt me toch niet normaal? De collega ondernemers die ik heb gesproken, hebben hier in ieder geval geen last van.

 

De beheerder heeft al van alles geprobeerd maar lijkt er toch niet helemaal in te slagen om dit permanent de koop in te drukken. De mail loopt nu via mailchannels. Als alternatief wordt mij gezegd dat ik dan beter via office 365 of google suite kan gaan mailen.

Zelf ben ik daar niet zo'n voorstander van. Enerzijds door de kosten en anderzijds omdat alle mail dan in de cloud staat.

 

Wat is er te doen aan dit fenomeen?

 

 

[StevenK]

Steven, dan kom ik volgens mij automatisch uit op een ...@provider email adres en dat wil ik niet. Voor een bedrijf vind ik dat nogal knullig staan/ Of er moeten nog andere mogelijkheden bestaan?

Nee, dat betekent het niet. Het uitgangspunt van het SMTP protocol (het protocol dat gebruikt wordt voor het versturen van email) is dat je je email verstuurt via de provider die je internetverbinding levert en niet via de provider die jouw email voor jou ophaalt.

 

Daarom is het ook zo dat wanneer je via een SMTP client mailt vanaf je telefoon, je in die cliënt het SMTP adres van je mobiele provider moet gebruiken.

 

Je moet het zo zien, dat het ontvangen van email helemaal los staat van het versturen van email.

 

[R.I.P. | Peter Bonjernoor]

Daarom is het ook zo dat wanneer je via een SMTP client mailt vanaf je telefoon, je in die cliënt het SMTP adres van je mobiele provider moet gebruiken.

Sorry, maar dat is simpelweg niet waar.

[Gelderblom Internet Solutions]

Eens met bovenstaande. Sterker nog; Ik ben van mening dat het zeer onverstandig is. Zie mijn vorige reacties. Dat het kan, en werkt, betekend zeker niet dat je het ook moet gaan gebruiken.

 

Ik zal proberen het beter uit te leggen.

 

Stel je mailt vanaf domeinnaam x, vanaf server y, dan zal de ontvangende partij via de DNS records van de domeinnaam x vragen of server y toegestaan is om mails te sturen namens domeinnaam x. De DNS record die hiervoor verantwoordelijk is, is dus het SPF record. Als deze controle niet bestond, kun je vrijuit iedere domeinnaam als afzender gebruiken (ik kan dan ongestoord mailen als zijnde wouter@google.com).

 

Internet providers gebruiken meerdere versturende mail servers (y), je zult dus al deze servers via het SPF record van domeinnaam x moeten 'toestaan' op de mailen vanuit alle servers van je internet provider. Dit hoeft niet onmogelijk te zijn, als de internet provider hier een oplossing voor bied. Google Apps bied bijvoorbeeld _spf.google.com aan, die je kunt toevoegen aan de lijst van toegestane servers. Deze record bevat alle servers waar vanuit Google mails kan sturen. De meeste internet providers Ziggo, KPN, Telfort.. zullen dit alleen leveren als je hun zakelijke mail diensten afneemt, als ze dit al hebben.

 

Als je mailt vanaf een IPv6 IP adres, zijn er nog extra regels waar je aan moet houden. Dit is de beveiligingssleutel DKIM. Dit is een beveiligingssleutel, in je DNS record, die 'gedeeld' word met de verzendende mail server. Deze sleutel is eenvoudig te controleren voor de ontvangende partij. Even zo eenvoudig mogelijk uitgelegd.

 

Dmarc is hekkensluiter. Deze record bepaald, wat er moet gebeuren, als er toch nog 'verkeerde mail' vanuit jouw domeinnaam komt. Hiermee kun je een protocol opstellen, waardoor je reactief kunt optreden. Je krijgt hiermee een beter inzicht in spam meldingen.

 

Dit allemaal houd ik momenteel voor mijn klanten in de gaten met eerder genoemde externe leverancier.

 

Als je bovenstaande in orde hebt, dan heb je een toekomstbestendige oplossing. Zie ook de bijlage.

[StevenK]

Daarom is het ook zo dat wanneer je via een SMTP client mailt vanaf je telefoon, je in die cliënt het SMTP adres van je mobiele provider moet gebruiken.

Sorry, maar dat is simpelweg niet waar.

Dat is het wel. Een alternatief is gebruik maken van een SMTP-extensie die authenticatie gebruikt, maar als je pure SMTP gebruikt, zul je zelfs *moeten* versturen via de SMTP server van je internetprovider, omdat elke andere SMTP server zal antwoorden met een '550 5.7.1 Relaying denied'. Nu zijn daar allerlei houtje touwtje oplossingen als POP before SMTP bedacht uitbreidingen bovenop SMTP, omdat SMTP zelf geen authenticatie kent, maar dat verandert niets aan het aloude SMTP protocol.

 

En dat is overigens ook precies het fundamentele probleem van email: het wordt nog steeds verstuurd met een protocol dat niet controleert of de afzender authentiek is. Maar omdat alle server to server communicatie via de protocol gaat, lukt het niet echt een alternatief te ontwikkelen en daarom zijn er allerlei andere lapmiddelen die dan weer gaan kijken of email wel legitiem is, met bijvoorbeeld blacklists en SPF records.

 

En ja, de meest praktische oplossing om te voorkomen dat je over al die maatregelen struikelt is je volledige mail, zowel in- als uitgaand, bij een provider onderbrengen die de boel goed voor elkaar heeft *of* een eigen mailserver (laten) implementeren op een wijze dat alles klopt.

[R.I.P. | Peter Bonjernoor]

Een alternatief is gebruik maken van een SMTP-extensie die authenticatie gebruikt...

 

Hola - je had het over mailen vanaf je telefoon, niet over de pure specificatie van SMTP. En ik daardoor ook.

 

Daarom is het ook zo dat wanneer je via een SMTP client mailt vanaf je telefoon, je in die cliënt het SMTP adres van je mobiele provider moet gebruiken.

 

[StevenK]

Een alternatief is gebruik maken van een SMTP-extensie die authenticatie gebruikt...

 

Hola - je had het over mailen vanaf je telefoon, niet over de pure specificatie van SMTP. En ik daardoor ook.

maar zonder gekheid: het is niet voor niks dat de mobiele providers hun klanten vertellen welke SMTP server ze moeten gebruiken. En de ellende is dat SMTP, hoe goed het ook ooit bedoeld was, volstrekt te kort schiet voor de eisen die aan emailverkeer worden gesteld.

[Gelderblom Internet Solutions]

Een alternatief is gebruik maken van een SMTP-extensie die authenticatie gebruikt...

 

Hola - je had het over mailen vanaf je telefoon, niet over de pure specificatie van SMTP. En ik daardoor ook.

maar zonder gekheid: het is niet voor niks dat de mobiele providers hun klanten vertellen welke SMTP server ze moeten gebruiken. En de ellende is dat SMTP, hoe goed het ook ooit bedoeld was, volstrekt te kort schiet voor de eisen die aan emailverkeer worden gesteld.

 

Waarom vind je het precies noodzakelijk om de pure specificatie van SMTP te gebruiken? SMTP is enkel een protocol voor het verzenden van mail, dat is wat mij betreft toch prima? We kunnen daar bovenop andere specificaties maken/bedenken voor bijv. authenticatie en verificatie (gelukkig zijn voor beide stabiele oplossingen).

SPF kun je nog zien als 'lapmiddel' (al is er helemaal niets mis mee en redelijk effectief), DKIM overstijgt deze term wel.

 

Ook op mijn mobiele telefoon heb ik nooit de noodzaak gezien om een internet provider mijn mail te laten afhandelen.

[Basto]

Ivm een beurs een wat late reactie. De afgelopen week heb ik twee maal gehad dat een klant een foutmelding krijgt op een mail die men naar mij stuurt. Ik krijg de mail echter wel binnen.

Blijkbaar loopt het toch niet helemaal lekker, en ik ben benieuwd of ik wel alle mail ontvang.

 

 

[Ward van der Put]

een foutmelding

Welke?

[Basto]

Een failed to deliver melding bij één van de twee. Van de andere weet ik het niet.

[StevenK]

Ivm een beurs een wat late reactie. De afgelopen week heb ik twee maal gehad dat een klant een foutmelding krijgt op een mail die men naar mij stuurt. Ik krijg de mail echter wel binnen.

Blijkbaar loopt het toch niet helemaal lekker, en ik ben benieuwd of ik wel alle mail ontvang.

Maar dat heeft hoe dan ook niets te maken met door jou verzonden email die geblacklist wordt. Email verzenden en ontvangen staan echt los van elkaar.

 

En de meest voorkomende reden voor onbezorgbare email is dat de bijlagen te groot zijn. Dus een failed to deliver is op zich niet interessant, maar de reden die erbij gegeven wordt.

[Basto]

Zowel bij de fouten van het verzenden en ontvangen waren er geen bijlagen bij de berichten bijgevoegd. Bijgaand twee foutmelding codes die ik terug kreeg bij het verzenden van email: code 554 en de andere met code 450.

 

De eerste betekend volgens mij dat mijn mail geweigerd wordt omdat de ontvanger mij als ongewenst heeft aangemerkt of omdat mijn IP op een zwarte lijst staat.

 

[Picture It]

Weigeren van mails met die foutmelding zouden kunnen komen door een (oude) blacklist vermelding, maar probeer uit te sluiten dat er geen andere redenen zijn dat je mails geweigerd worden.

 

Dit kun je doen door diezelfde mails naar mailtester te sturen. ( https://www.mail-tester.com/ ). Bezoek site, stuur de email naar het mailadres dat je ziet ( kopieer plak bericht en content van de emails die een foutmelding geven) Eventueel kun je de link van het rapport van mailtester hier delen ( als daar geen gevoelige informatie in staat ). Je kunt deze link ook naar je hosting sturen.

 

Voor blacklist vermeldingen en problemen moet je bij je hosting zijn. Als deze de problemen niet kan oplossen moet je wellicht overwegen om over te stappen naar een hosting van betere kwaliteit of een e-mail delivery service te gebruiken.

[Basto]

Dennis, zojuist een mail doorgestuurd naar mailtester. Over het algemeen is de score vrij goed, er zijn de onderstaande aandachtspunten:

 

[*]Je bericht is niet ondertekend met DKIM

[*]Je heb geen DMARC record

[*]Your message does not contain a List-Unsubscribe header

 

In totaal een score van 9 uit 10. Niet slecht maar wellicht toch reden voor een enkele hapering. Betreft je laatste paragraaf, dat gaat hoogstwaarschijnlijk de vervolg stap worden.

[Picture It]

Dan is op moment van testen niks aan de hand. Score 9 van 10 is keurig. Het ligt in ieder geval niet aan je eigen instellingen / mails en op dit moment sta je niet op een blacklist.

[Sander_Aerts]

Een goede mx tester en blacklist check staat op mxtoolbox, voorbeeld:

 

https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3asrv02.aertsit.com&run=toolpage

 

mail-tester is een goede test voor inhoud van e-email maar niet voldoende voor alle blacklists.

 

DMAC en DKIM zijn wel aanraders zoals al eerder aangegeven, je hosting partij zou dit moeten kunnen configureren. Bij Microsoft en veel andere blacklist kun je je ip laten whitelisten maar moet je weer reputatie opbouwen.

 

Ik ben zelf overigens een groot fan van o365 en exchange online :) maar goed dat is om andere redenen dan het probleem verplaatsten zoals bij jou geadviseerd werdt.