SMTP: het gesprek tussen mailservers

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

Leerdoel: Na deze les kun je een SMTP-gesprek lezen, uitleggen wat EHLO, MAIL FROM, RCPT TO en DATA doen, en aan een antwoordcode zien of een fout tijdelijk of definitief is.

Kernbegrippen: SMTP (RFC 5321), sessie, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, antwoordcode (2xx, 3xx, 4xx, 5xx), uitgebreide statuscode, uitbreidingen (STARTTLS, AUTH, SIZE), null MX

Een gesprek in gewone tekst

SMTP is een heel oud protocol (de eerste versie is van 1982) en daarom heel leesbaar. Twee servers sturen elkaar regels tekst. De verzender (de client) stuurt een commando, de ontvanger (de server) antwoordt met een getal van drie cijfers en een stukje uitleg. Je kunt zo'n gesprek in een foutmelding of logboek letterlijk teruglezen, en dat is precies waarom het loont om het te begrijpen.

Hieronder een volledig gesprek. S: is de ontvangende server, C: de verzendende server. De mail gaat van anna@example.com naar jan@example.net.

S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (vanaf hier is de verbinding versleuteld; de client stuurt opnieuw EHLO)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Offerte
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hoi Jan, hierbij de offerte.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

De commando's een voor een

Het belangrijkste inzicht: alles vóór DATA is envelope, alles na DATA is de inhoud. Wat in MAIL FROM staat en wat in de kopregel From: staat, worden apart aangeleverd en hoeven niet gelijk te zijn. De server bezorgt op RCPT TO; de To:-regel in de inhoud speelt bij de bezorging geen rol.

De antwoordcodes

Het eerste cijfer van de code is het belangrijkste:

Achter de drie cijfers staat bij moderne servers een uitgebreide statuscode in de vorm klasse.onderwerp.detail (RFC 3463), bijvoorbeeld 5.1.1. Het eerste cijfer is weer 2, 4 of 5. Het tweede cijfer zegt waar het over gaat: 1 = adres, 2 = mailbox, 3 = mailsysteem, 4 = netwerk en routering, 5 = protocol, 6 = inhoud, 7 = beveiliging en beleid. Een paar die je vaak ziet:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (tijdelijk)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (beleid: spam, blocklist, DMARC)

In module 6 leer je een volledige bounce lezen en vind je een tabel met de codes die het meest voorkomen.

Waarom tijdelijk en definitief zo belangrijk is

Een server die twijfelt, antwoordt vaak met een 4xx. Een bekend voorbeeld is greylisting: een server die een verzender nog niet kent, zegt de eerste keer "probeer het later". Een echte mailserver komt na een paar minuten terug, veel spamprogramma's niet. Ook grote ontvangers gebruiken 4xx om het tempo af te remmen als ze een IP-adres nog niet vertrouwen. Voor jou als verzender betekent dat: vertraging, maar geen verlies. Het systeem lost het meestal zelf op.

Een 5xx is anders. Daar gaat de verzender niet opnieuw proberen. Krijg je een 5xx terug, dan moet iemand iets veranderen: het adres, de inhoud, of de instellingen van het verzendende domein.

Een valkuil: sommige servers geven een 5xx terwijl het probleem tijdelijk is (bijvoorbeeld bij een volle mailbox 552 5.2.2), en andere geven een 4xx voor iets dat nooit gaat lukken. Lees dus altijd de tekst achter de code, niet alleen het getal.

Wie is verantwoordelijk?

Na 250 op de punt van DATA ligt de verantwoordelijkheid bij de ontvangende server. Lukt het hem daarna niet om de mail in de mailbox te zetten, dan moet hij zelf een foutmelding terugsturen. Dat is de bron van een lastig fenomeen: backscatter. Een server die eerst alles aanneemt en pas later bedenkt dat het adres niet bestaat, stuurt een bounce naar de envelope-afzender. Was die vervalst door een spammer, dan krijgt een onschuldige derde de bounce. Daarom horen servers al bij RCPT TO te weigeren wat niet kan (zie ook catch-all in les 3.3).

In de praktijk: SMTP zien in je eigen omgeving

Een gewone gebruiker ziet het SMTP-gesprek zelden helemaal, maar wel in stukjes:

• in een bounce staat de laatste regel van het gesprek, bijvoorbeeld Remote-MTA: mx1.mailprovider.example en Diagnostic-Code: smtp; 550 5.1.1 ...;
• in de kopregels van een ontvangen mail staat per server een Received:-regel met de EHLO-naam en het IP-adres (les 1.5);
• in een paneel met maillogboek, zoals E-mail Tracering in DirectAdmin bij WebOké, zie je per bericht het antwoord van de ontvangende server. Bij andere aanbieders heet zoiets bijvoorbeeld berichttracering of mail log, en de inhoud is vergelijkbaar.

Je hoeft dus zelf geen verbinding te maken met een mailserver om dit te kunnen lezen. Wie dat wel wil proberen: met openssl s_client -starttls smtp -connect server:25 kun je het gesprek met de hand voeren, maar veel thuisproviders blokkeren uitgaand verkeer op poort 25 (les 1.4).

Samenvatting

• SMTP is een leesbaar gesprek: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Alles vóór DATA is envelope (bezorging en foutmeldingen), alles erna is de inhoud met de kopregels die je ziet.
• 2xx = gelukt, 4xx = tijdelijk (later opnieuw), 5xx = definitief (bounce).
• De uitgebreide code X.Y.Z vertelt waar het over gaat; X.1 adres, X.2 mailbox, X.7 beleid en beveiliging.
• Lees altijd de tekst achter de code; servers zijn niet altijd consequent.

Quiz

Opdracht

Opdracht Z1.2: Een domein dat geen mail ontvangt. Zoek de MX-records op van example.com. Vul in wat je vindt en kies wat een verzendserver met mail voor info@example.com doet: (a) afleveren bij de server met prioriteit 0, (b) het A-record proberen, (c) meteen opgeven, of (d) het later opnieuw proberen. Het programma vraagt het MX-record live op en kijkt na.

Verder lezen

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

• Uitleg verzendproces van emails / SMTP
• Mail delivery failed: zo lees je de foutmelding en wat de codes betekenen
• DirectAdmin handleiding 9.3: E-mail Tracering: waar is mijn mail gebleven?
• RFC 5321 (SMTP), paragraaf 3 en 4.2 (antwoordcodes); RFC 3463 (uitgebreide statuscodes); RFC 7505 (null MX)