Poorten, versleuteling en inloggen

Module 1: Hoe e-mail werkt · Leestijd: 10 minuten

Leerdoel: Na deze les kun je per mailpoort zeggen waarvoor hij is, het verschil tussen STARTTLS en directe TLS uitleggen, en een certificaatmelding of een geweigerde login verklaren.

Kernbegrippen: poort 25, 587, 465, 993, 995, 143, 110, STARTTLS, directe TLS (implicit TLS, RFC 8314), certificaat, servernaam, SMTP-authenticatie (SMTP AUTH), open relay, blokkade van poort 25, app-wachtwoord, OAuth

Een poort is een deur

Een server heeft één IP-adres, maar veel deuren. Elke dienst luistert op zijn eigen poort, een nummer. Je webbrowser klopt aan op poort 443, je mailprogramma op poort 993 om mail te lezen en op 587 of 465 om te versturen. Kies je de verkeerde deur, dan antwoordt er niemand, of iemand die een andere taal spreekt. Dat geeft vage foutmeldingen als "kan geen verbinding maken" of "de server reageert niet".

De mailpoorten op een rij:

Waarom niet gewoon poort 25 voor versturen?

Vroeger stelde je in je mailprogramma poort 25 in. Dat is om twee redenen verleden tijd.

Ten eerste: op poort 25 neemt een mailserver mail aan van iedereen, voor zijn eigen domeinen. Er wordt niet ingelogd. Een server die op poort 25 ook mail van iedereen naar andere domeinen doorstuurt, heet een open relay, en die wordt binnen een paar uur door spammers misbruikt. Daarom is het versturen van je eigen mail naar de hele wereld een aparte dienst geworden: submission op poort 587 (en 465), waar je altijd eerst inlogt.

Ten tweede: veel internetproviders blokkeren uitgaand verkeer naar poort 25 vanaf thuisaansluitingen. Een besmette computer in een huiskamer kan dan geen spam rechtstreeks naar mailservers sturen. Gevolg voor jou: probeer je vanuit je mailprogramma via poort 25 te versturen, dan kan het thuis niet werken en op kantoor wel, of andersom.

Onthoud: mailprogramma's versturen via 587 of 465, met inloggen. Poort 25 is voor servers onderling.

STARTTLS of directe TLS?

Er zijn twee manieren om een mailverbinding te versleutelen.

Directe TLS (implicit TLS): de verbinding is vanaf de eerste byte versleuteld, net als een website met https. Dat gebeurt op 465, 993 en 995.

STARTTLS: de verbinding begint onversleuteld. De server zegt "ik kan versleutelen", de client antwoordt STARTTLS, en vanaf dat moment is alles versleuteld. Dat gebeurt op 587 (en op 25, 143 en 110).

Voor de beveiliging maakt het weinig uit, zolang je programma STARTTLS verplicht stelt. Het risico van STARTTLS zit in het begin: iemand die tussen jou en de server zit, kan het aanbod "ik kan versleutelen" wegpoetsen. Een programma dat dan stilletjes onversleuteld doorgaat, stuurt je wachtwoord leesbaar over de lijn. Daarom adviseert RFC 8314 (2018) voor mailprogramma's directe TLS (465, 993, 995) boven STARTTLS. In de praktijk zijn 587 met STARTTLS en 465 met SSL/TLS allebei goed, als je de versleuteling in je programma op "verplicht" zet en niet op "indien beschikbaar".

Een veelgemaakte fout is de verkeerde combinatie: poort 587 met "SSL/TLS", of poort 465 met "STARTTLS". Het programma verwacht dan iets anders dan de server doet, en de verbinding hangt of mislukt. Onthoud de paren: 587 + STARTTLS en 465 + SSL/TLS. Programma's noemen directe TLS soms "SSL", "SSL/TLS" of "TLS"; STARTTLS heet soms ook "TLS". Kijk dus naar de poort.

Het certificaat en de servernaam

Bij elke versleutelde verbinding laat de server een certificaat zien, dat bewijst dat hij is wie hij zegt. Je mailprogramma controleert twee dingen: is het certificaat uitgegeven door een vertrouwde partij en nog geldig, en staat de naam die jij hebt ingevuld als server erin?

Dat laatste gaat het vaakst mis. Vul je mail.example.com in, maar staat in het certificaat alleen server12.hosting.example, dan krijg je een melding als "Kan identiteit van server niet verifiëren" of "De principal-naam van het doel is onjuist". De verbinding zelf is dan wel versleuteld, maar je programma kan niet zeker weten dat het met de echte server praat.

Klik zo'n melding niet weg. De oplossing is een servernaam die wel in het certificaat staat (zie les 2.1). Bij een gedeelde server is dat vaak de naam van de server zelf, die je aanbieder opgeeft. Nog een bekende oorzaak: een virusscanner die versleutelde mail "scant" en daarvoor zijn eigen certificaat ertussen zet. In de melding staat dan de naam van de scanner bij "uitgegeven door".

Inloggen bij het versturen

Op 587 en 465 moet je inloggen voordat de server je mail naar buiten wil sturen. Dat heet SMTP-authenticatie (SMTP AUTH). In je programma heet de optie "uitgaande server vereist verificatie", "aanmelden vereist" of "authenticatie: normaal wachtwoord". Meestal gebruik je dezelfde gebruikersnaam en hetzelfde wachtwoord als voor IMAP.

Staat verificatie uit, of is de gebruikersnaam bij de uitgaande server leeg gebleven, dan kun je wel mail lezen maar niet versturen. De server antwoordt dan met iets als 530 5.7.0 Authentication required of 554 5.7.1 Relay access denied. Dat is de meest voorkomende reden voor "ontvangen werkt, versturen niet".

Een tweede soort weigering: 535 5.7.8 Authentication failed. Dan klopt de combinatie van gebruikersnaam en wachtwoord niet. Let op: na een aantal mislukte pogingen blokkeren veel servers het IP-adres waar die pogingen vandaan komen, tegen wachtwoordraden. Een oude telefoon met een oud wachtwoord kan zo je hele kantoor laten blokkeren.

App-wachtwoorden en OAuth

Bij grote aanbieders als Google en Microsoft werkt inloggen met alleen je gewone wachtwoord in een los mailprogramma steeds minder vaak. Zij gebruiken OAuth: je programma stuurt je naar een inlogpagina van de aanbieder, je logt daar in (eventueel met tweestapsverificatie), en het programma krijgt een sleutel in plaats van je wachtwoord. Programma's die dat niet kunnen, krijgen soms een app-wachtwoord: een apart, lang wachtwoord dat alleen voor dat ene programma geldt en dat je los kunt intrekken.

Bij een gewone mailbox bij een hostingbedrijf log je meestal met het wachtwoord van de mailbox zelf in. Dat maakt een sterk en uniek wachtwoord extra belangrijk (les 3.4).

In de praktijk: de instellingen van een mailbox

Bij een mailbox van WebOké zijn de instellingen: IMAP 993 met SSL/TLS, POP3 995 met SSL/TLS, versturen 587 met STARTTLS of 465 met SSL/TLS, verificatie aan met je volledige e-mailadres en het wachtwoord van de mailbox. Bij andere aanbieders werkt het vergelijkbaar: de poorten zijn bijna overal dezelfde, alleen de servernaam verschilt. Welke servernaam je kiest, zie je in les 2.1.

Samenvatting

• Mailprogramma's versturen via 587 (STARTTLS) of 465 (directe TLS), altijd met inloggen. Poort 25 is voor servers onderling en wordt thuis vaak geblokkeerd.
• Lezen gaat via 993 (IMAP) of 995 (POP3), allebei met directe TLS.
• Combineer goed: 587 + STARTTLS, 465 + SSL/TLS. Zet versleuteling op verplicht.
• Een certificaatmelding betekent meestal: de servernaam die je invulde, staat niet in het certificaat. Wegklikken is geen oplossing.
• "Lezen lukt, versturen niet" is bijna altijd: verificatie voor de uitgaande server staat uit of is leeg.

Quiz

Opdracht

Opdracht Z1.4: Poorten en certificaat van een mailserver. Vul de inkomende en de uitgaande servernaam in die je voor je eigen mailbox gebruikt (heb je geen eigen mailbox, gebruik dan imap.gmail.com en smtp.gmail.com). Kies voor poort 993 (inkomend) en de poorten 465 en 587 (uitgaand) wat je verwacht: directe TLS, STARTTLS of niet bereikbaar, en vul in of je denkt dat de naam in het certificaat staat. Het programma maakt zelf verbinding met de drie poorten en zet de uitkomst naast jouw antwoorden.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• DirectAdmin handleiding 8.1: Alle instellingen op een rij: servers, poorten en beveiliging
• DirectAdmin handleiding 8.8: Verzenden of ontvangen lukt niet: zo los je het op
• Foutmelding over het certificaat bij het ophalen van mail
• Ik kan geen e-mail versturen (ontvangen werkt wel)
• RFC 8314 (directe TLS voor mailprogramma's), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)