Modul 1 · 1.2
SMTP: samtalen mellem mailservere
Modul 1: Sådan virker e-mail · Læsetid: 10 minutter
Læringsmål: Efter denne lektion kan du læse en SMTP-samtale, forklare hvad EHLO, MAIL FROM, RCPT TO og DATA gør, og ud fra en svarkode se om en fejl er midlertidig eller permanent.
Kernebegreber: SMTP (RFC 5321), session, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, svarkode (2xx, 3xx, 4xx, 5xx), udvidet statuskode, udvidelser (STARTTLS, AUTH, SIZE), null MX
En samtale i almindelig tekst
SMTP er en meget gammel protokol (den første version er fra 1982), og derfor meget letlæselig. To servere sender hinanden linjer med tekst. Afsenderen (klienten) sender en kommando, modtageren (serveren) svarer med et tal på tre cifre og en lille forklaring. Du kan læse sådan en samtale direkte i en fejlmeddelelse eller logfil, og det er netop derfor det kan betale sig at forstå den.
Herunder ses en komplet samtale. S: er den modtagende server, C: den afsendende server. Mailen går fra anna@example.com til 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
(herfra er forbindelsen krypteret; klienten sender EHLO igen)
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: Tilbud
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hej Jan, her er tilbuddet.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 ByeKommandoerne en for en
| Kommando | Betydning | Bemærk |
|---|---|---|
| (forbindelse) | Serveren hilser med 220 og sit navn. | Dette kaldes banneret. Svarer serveren straks 554, vil den slet ikke tale med din IP-adresse (ofte en blocklist). |
EHLO navn | "Hej, jeg er out.hosting.example." Serveren svarer med de udvidelser, den kender. | Navnet bør være det rigtige navn på den afsendende server, helst identisk med dens PTR-record (lektion 5.1). HELO er den gamle variant uden udvidelser. |
STARTTLS | "Lad os kryptere fra nu af." | Kun hvis serveren tilbyder det. Mellem servere er dette som regel frivilligt (lektion 5.4). |
MAIL FROM:<adresse> | Envelope senderen (envelope sender): fejlmeddelelser sendes hertil. | Bliver senere til headeren Return-Path. SPF kontrollerer denne adresse. En tom afsender <> bruger servere selv til fejlmeddelelser, så en bounce aldrig udløser en ny bounce. |
RCPT TO:<adresse> | Modtageren. Kan gentages, en gang pr. modtager. | Her bør serveren allerede sige om adressen findes. En 550 5.1.1 på dette tidspunkt er en pæn, hurtigt kendt fejl. |
DATA | "Nu kommer selve mailen." Serveren svarer 354. | Derefter følger headere, en tom linje og teksten. En linje med kun et punktum afslutter. |
QUIT | Samtalen afsluttes. |
Det vigtigste at forstå: alt før DATA er envelope, alt efter DATA er indholdet. Det der står i MAIL FROM, og det der står i headeren From:, leveres hver for sig og behøver ikke være ens. Serveren leverer ud fra RCPT TO; To:-linjen i indholdet spiller ingen rolle for leveringen.
Svarkoderne
Det første ciffer i koden er det vigtigste:
| Begynder med | Betydning | Hvad gør afsenderen? |
|---|---|---|
| 2 | Lykkedes. | Videre til næste trin. 250 efter DATA betyder: serveren har modtaget mailen og er nu ansvarlig for den. |
| 3 | Fortsæt, jeg venter på mere. | Kun ved 354 efter DATA (og ved login). |
| 4 | Midlertidig fejl: ikke nu, prøv senere. | Mailen bliver i køen og bliver sendt igen senere. |
| 5 | Permanent fejl: dette vil ikke lykkes. | Afsenderen opgiver og sender en fejlmeddelelse (bounce) til envelope senderen. |
Efter de tre cifre står der hos moderne servere en udvidet statuskode i formen class.subject.detail (RFC 3463), for eksempel 5.1.1. Det første ciffer er igen 2, 4 eller 5. Det andet ciffer fortæller hvad det handler om: 1 = adresse, 2 = postkasse, 3 = mailsystem, 4 = netværk og routing, 5 = protokol, 6 = indhold, 7 = sikkerhed og politik. Nogle du ofte ser:
550 5.1.1 The email account that you tried to reach does not exist
452 4.2.2 Mailbox full (midlertidig)
552 5.3.4 Message size exceeds fixed limit
451 4.7.1 Greylisted, please try again later
550 5.7.1 Message rejected (politik: spam, blocklist, DMARC)I modul 6 lærer du at læse en komplet bounce, og du finder en tabel med de mest almindelige koder.
Hvorfor midlertidig og permanent er så vigtigt
En server der er i tvivl, svarer ofte med en 4xx. Et kendt eksempel er greylisting: en server der endnu ikke kender en afsender, siger første gang "prøv igen senere". En rigtig mailserver kommer tilbage efter et par minutter, mange spamprogrammer gør ikke. Store modtagere bruger også 4xx til at bremse tempoet, hvis de endnu ikke har tillid til en IP-adresse. For dig som afsender betyder det: forsinkelse, men ikke tab. Systemet løser det som regel selv.
En 5xx er anderledes. Her forsøger afsenderen ikke igen. Får du en 5xx tilbage, skal nogen ændre noget: adressen, indholdet eller indstillingerne for det afsendende domæne.
En faldgrube: nogle servere giver en 5xx, selvom problemet er midlertidigt (for eksempel ved en fuld postkasse 552 5.2.2), og andre giver en 4xx for noget der aldrig vil lykkes. Læs derfor altid teksten efter koden, ikke kun tallet.
Hvem er ansvarlig?
Efter 250 på punktummet efter DATA ligger ansvaret hos den modtagende server. Lykkes det den ikke bagefter at lægge mailen i postkassen, skal den selv sende en fejlmeddelelse tilbage. Det er kilden til et besværligt fænomen: backscatter. En server der først modtager alt og først senere opdager at adressen ikke findes, sender en bounce til envelope senderen. Var den forfalsket af en spammer, får en uskyldig tredjepart bouncen. Derfor bør servere allerede ved RCPT TO afvise det der ikke kan lade sig gøre (se også catch all i lektion 3.3).
I praksis: at se SMTP i dit eget miljø
En almindelig bruger ser sjældent hele SMTP-samtalen, men wel i stykker:
- i en bounce står den sidste linje af samtalen, for eksempel
Remote-MTA: mx1.mailprovider.exampleogDiagnostic-Code: smtp; 550 5.1.1 ...; - i headerne for en modtaget mail står der pr. server en
Received:-linje med EHLO-navnet og IP-adressen (lektion 1.5); - i et panel med maillogfil, som E-mailsporing i DirectAdmin hos WebOké, ser du for hver besked svaret fra den modtagende server. Hos andre udbydere hedder noget tilsvarende for eksempel besked-sporing eller mail log, og indholdet er sammenligneligt.
Du behøver altså ikke selv forbinde til en mailserver for at kunne læse dette. Hvis du vil prøve det: med openssl s_client -starttls smtp -connect server:25 kan du føre samtalen manuelt, men mange private internetudbydere blokerer udgående trafik på port 25 (lektion 1.4).
Opsummering
- SMTP er en letlæselig samtale: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
- Alt før DATA er envelope (levering og fejlmeddelelser), alt derefter er indholdet med de headere du ser.
- 2xx = lykkedes, 4xx = midlertidig (prøves igen senere), 5xx = permanent (bounce).
- Den udvidede kode
X.Y.Zfortæller hvad det handler om; X.1 adresse, X.2 postkasse, X.7 politik og sikkerhed. - Læs altid teksten efter koden; servere er ikke altid konsekvente.
Quiz
Opgave
Opgave Z1.2: Et domæne der ikke modtager mail. Slå MX-records op for example.com. Skriv hvad du finder, og vælg hvad en afsenderserver gør med mail til info@example.com: (a) leverer til serveren med prioritet 0, (b) prøver A-recorden, (c) opgiver straks, eller (d) prøver igen senere. Programmet slår MX-recorden op live og kontrollerer dit svar.
Læs mere
Trinene i disse artikler gælder for WebOkés paneler; hos andre udbydere fungerer det tilsvarende.
- Sådan bliver e-mails sendt / SMTP
- Mail delivery failed: sådan læser du fejlmeddelelsen, og hvad koderne betyder
- DirectAdmin vejledning 9.3: E-mailsporing: hvor er min mail blevet af?
- RFC 5321 (SMTP), afsnit 3 og 4.2 (svarkoder); RFC 3463 (udvidede statuskoder); RFC 7505 (null MX)