Dagelijks stromen er tientallen e-mails mijn mailbox binnen. Persoonlijke berichten, werk, nieuwsbrieven, mailinglijsten en natuurlijk zo af en toe spam. Voor jou zal dat niet veel anders zijn. Misschien heb je van dit blog zelfs een notificatie per e-mail gekregen. Het lijkt vanzelfsprekend, maar hoe steekt het in elkaar? Reis mee met de route die jouw e-mail aflegt!
Een stukje geschiedenis
E-mail zoals we dat vandaag kennen, is al in 1982 vastgelegd. Daarvoor kon je andere internetgebruikers ook wel berichten sturen, maar een standaard bestond nog niet. Het vastleggen gebeurde in twee delen. Het eerste deel is RFC 821 en omschrijft het SMTP-protocol. Het tweede deel is RFC 822 en omschrijft het standaardformaat van e-mailberichten. Inmiddels is er veel gewijzigd en toegevoegd, maar de kern is hetzelfde. Bekijk je nu de headers van een e-mail, dan is dat nog steeds het formaat zoals in 1982 is beschreven.
Graag e-mail in eigen beheer?
Met onze webhosting heb je ruim voldoende opslagruimte. Inclusief webmail en handige mailfilters!
De opbouw van de e-mailketen
In technische documentatie bestaat de hele e-mailketen uit agents. Je bent waarschijnlijk het bekendst met de MUA, ofwel de mail user agent. Dit is het door jou gebruikte mailprogramma, zoals Thunderbird, Outlook of Apple Mail. Ga jij daar jouw mailaccount instellen, dan wordt je gevraagd om twee servers in te stellen: de inkomende en uitgaande.
Bij de inkomende server stel je de IMAP-server in. Dit is het protocol dat je mailbox beheert. Bij de uitgaande stel je dan de SMTP-server in. Die zorgt ervoor dat je bericht wordt verstuurd. Vanuit een technisch oogpunt staan IMAP en SMTP helemaal los van elkaar. SMTP is dus puur voor verzenden en IMAP voor mailboxbeheer. De client regelt de interactie tussen beiden en zorgt dat een bericht via SMTP verstuurd wordt en daarnaast ook via IMAP in de map ‘Verzonden’ wordt geplaatst.
E-mailprogramma instellen?
In onze helpsectie leggen we per per e-mailprogramma uit hoe dit moet.
Poort 25, 465, 587, 143 en 993?
De verschillende poorten voor e-mail zijn niet altijd even duidelijk. En je moet dan ook nog het type authenticatie kiezen. Gelukkig staat het bij Antagonist goed omschreven, maar het is ook leuk om te begrijpen hoe het werkt.
SMTP- en IMAP-poorten
Poort 25 is de poort die mailservers (MTA’s of mail transfer agents) gebruiken om onderling berichten af te leveren. Authenticatie is niet verplicht. Veel internetproviders blokkeren dan ook inkomende mail op deze poort. Zo voorkomen ze dat mensen zelf slecht geconfigureerde mailservers (open relay) gaan hosten en spammers het makkelijk hebben.
Poort 587 wordt gebruikt om vanuit de client e-mails bij de mailserver af te leveren, hier een MSA (mail submission agent) genoemd. Voor poort 587 is authenticatie verplicht en daardoor niet te misbruiken door spammers, tenzij ze het wachtwoord hebben achterhaald. Dan is er nog poort 465. Dit is een oudere standaard dan STARTTLS. Poort 465 gebruikt meteen vanaf de eerste verbinding al TLS, op dezelfde manier als HTTPS.
Bij IMAP is er een soortgelijke situatie. Ook daar heb je twee poorten: één in plain-text met STARTTLS (143) en één met TLS vanaf het begin (993). Ga jij je e-mailacount instellen in een e-mailprogramma, dan raden we aan om IMAP te gebruiken. De aanbevolen poorten zijn 993 voor de inkomende mailserver en 587 voor de uitgaande.
Opportunistic TLS en DANE
De poorten 25 en 587 gebruiken STARTTLS als versleuteling. Dat wil zeggen dat het protocol zonder encryptie begint en pas bij het juiste commando een TLS-sessie begint. Lukt een beveiligde verbinding opzetten niet, dan gaat het gewoon in plain-text. Dit wordt dan ook wel opportunistic TLS genoemd. Het probeert, maar dwingt niets af. Deze upgrade naar TLS kan zo ook door een kwaadwillende worden tegengehouden.
Daarom is er DANE ontwikkeld. Door een vingerafdruk van het TLS-certificaat in DNS te publiceren, kun je TLS afdwingen. De verzendende server weigert dan de mail te versturen als het opzetten van een versleutelde verbinding niet lukt. We zijn bij Antagonist druk bezig om dit te implementeren. Daarover in een volgend artikel meer!
Blacklisting van e-mail
Soms wordt een e-mail al aan de voordeur geweigerd. Het kan dan het geval zijn dat het IP-adres van de mailserver of het domein van de verzender op een blacklist staat. Vaak is dat het geval, omdat er spam is verzonden of phishing is gehost. Deze blacklists zijn vaak dynamisch en werken op basis van DNS. De mailserver doet dan een query. Als het adres geregistreerd staat, dan geeft de server een tijdelijke fout. Door caching en DNS- vertraging kan het dus soms even duren voordat een blacklisting is opgeheven.
Jouw e-mail afgeleverd
Aan de verzendende kant moet de laatste server kijken waar een e-mail moet worden afgeleverd. Daarvoor doet deze server voor een MX-record op het domein een DNS-lookup. MX staat voor mail exchanger.
Normaal wijst dit record naar de hostingserver, maar gebruik je bijvoorbeeld G Suite of Office Online, dan staan de mailservers daarvan er natuurlijk in. Ontbreekt een MX-record, dan probeert de mailserver een lookup voor een A- of een AAAA-record op het domein te doen en het daar af te leveren.
De laatste server in de hele keten is de MDA, de mail delivery agent. Bij Antagonist is dit ook direct de webserver. Deze mailserver plaatst het bericht in de juiste mailbox binnen je hostingpakket. De IMAP-server kan deze mails dan weer uitlezen. Zo is de cirkel rond.
Het pad van een e-mail bekijken
Iedere mailserver in het pad voegt een Received-header toe om aan te geven wanneer deze de mail heeft ontvangen. Zo kun je dus precies volgen waar je bericht is geweest en hoe lang het over elke stap heeft gedaan. Het verschilt per mailprogramma hoe je de headers van een e-mail opvraagt. Raadpleeg onze handleiding voor instructies.
Je kunt nog meer uit de headers halen. In de Authentication-Results-header kun je zien of de ontvanger vindt dat SPF, DKIM en DMARC kloppen. Je kunt dan aan de pass of fail en het commentaar erachter zien wat er niet goed ging. Ook is er vaak nog een Received-SPF-header aanwezig, waarmee je meer informatie over je SPF-policy krijgt. Dit zijn handige tools om zelf problemen mee te kunnen diagnosticeren, maar natuurlijk kan Support je hier ook mee helpen.
Dat servers zelf headers kunnen toevoegen, geeft ook het belang van DKIM aan. Zonder DKIM kun je niet aantonen dat de servers onderweg de inhoud van je mail niet hebben aangepast. Daarom wordt de inhoud en de headers die niet mogen veranderen (zoals To, From, Date en Subject) cryptografisch ondertekend. Lees meer over DKIM bij Antagonist.
Bestemming bereikt?
Dit artikel beschrijft nog maar een klein deel van de werking van e-mail. Er zijn veel meer tandwielen die het geheel draaiende houden. Gelukkig hoef jij je daar bij ons geen zorgen over te maken. Je kunt op ons vertrouwen dat we je e-mails goed en veilig afleveren. Zo kan je e-mail zorgeloos op reis! 😉
P.S. Op de hoogte blijven van alle artikelen, updates, tips en trucs die op ons blog verschijnen? Volg ons via Facebook, Twitter, Instagram, RSS en e-mail!
Goed verhaal wat wat duidelijkheid in de chaos brengt!
Er is alleen een ding waar ik het niet helemaal mee eens ben:
“Dan is er nog poort 465. Dit is een oudere standaard dan STARTTLS.” Port 465 is juist de de nieuwste standaard (als in: het is de huidige aanbeveling.)
Sinds RFC8314 (januari 2018) raadt de IETF namelijk Implicit TLS (port 465) aan boven STARTTLS (port 587):
“The STARTTLS mechanism on port 587 is relatively widely deployed due to the situation with port 465 (discussed in Section 7.3).”
(…)
“It is desirable to migrate core protocols used by MUA software to Implicit TLS over time, for consistency as well as for the additional reasons discussed in Appendix A.”
RFC8314: https://tools.ietf.org/html/rfc8314
Bedankt voor je feedback, Sebastiaan! Fijn dat het artikel duidelijkheid schept. Je hebt verder een punt. Poort 587 is de nieuwste standaard, maar inderdaad niet de huidige aanbeveling.
Het gebruik van poort 465 is in 1997 oorspronkelijk geregistreerd als algemene SMTP-poort met impliciete TLS. Deze poort werd praktisch alleen voor submission gebruikt, omdat via MX-records geen poort kan worden gecommuniceerd.
In 2011 is poort 587 geregistreerd, specifiek voor submission. Hier is STARTTLS de methode voor encryptie. Later met de invoering van RFC 8314 in 2018 is poort 587 echter deprecated en wordt poort 465 aanbevolen. Hiermee is officieel de context van deze poort ook veranderd.
Dit verandert alleen niets aan communicatie tussen de servers. Hiervoor blijft STARTTLS nodig. Dit is waar DANE om de hoek komt kijken. Hiermee kan toch TLS worden afgedwongen. STARTTLS met DANE is in dat opzicht net zo aanbevolen als impliciete TLS.
Ik vraag me nu af of jullie ook e-mail only pakketten hebben?
Het is mogelijk om onze hostingpakketten alleen voor e-mail te gebruiken. Het is dus niet vereist er een website op te zetten. Een e-mailpakket vinden we overigens zeker interessant. Nu kan het op de genoemde manier, maar een gericht pakket is wellicht iets voor in de toekomst!
Ik weet niet of ik hier op de juiste plek mijn vraag stel maar probeer het toch maar. De vorige beheerder van onze mail instellingen had groepen gemaakt in de forwarders. Omdat daar problemen mee waren heb ik deze nu in mailing lists gezet met dezelfde naam. Nu blijken mails die van sommige adressen worden verstuurd (in een recent geval vanaf telfort) niet aan te komen bij de personen die in de lijst staan vermeld. Als ik die mail stuur (me.com) komen ze wel aan. Is er een verklaring waarom dit gebeurt en kan ik wat ondernemen om het probleem te verhelpen?
Bedankt voor je vraag, Guus! Host je bij ons? Zo ja, dan kun je het beste een e-mail naar Support sturen. Zet daarin om welk domein het exact gaat. We kunnen dan aanvullende informatie vragen en het gerichter voor je nakijken.
Zeer goede uitleg. Bedankt daarvoor. Met genoegen heb ik met jullie organisatie enige tijd kunnen/mogen werken. Zeer professionele organisatie die de klant voorop stelt. Al jaren heb ik zelf een website bij een andere provider, maar kom er nog niet toe die naar jullie om te zetten. Zoals dat gaat moet ik diep in mijn administratie duiken om de juiste gegevens op te zoeken. Binnenkort ga ik daar mee aan de slag. Ik heb in jullie bedrijf veel vertrouwen en ben van plan een eigen mailaccount/server op te zetten. Tijdgebrek door andere prioriteiten is de oorzaak dat het zover nog niet is gekomen. Jullie bieden goede uitleg waarmee ik al eerder in aanraking ben geweest. De minder ervaren gebruiker maken jullie zeer blij met de gedegen hulp!