Modul 1 · 1.2
SMTP: samtalet mellan mailservrar
Modul 1: Hur e-post fungerar · Lästid: 10 minuter
Lärandemål: Efter den här lektionen kan du läsa ett SMTP-samtal, förklara vad EHLO, MAIL FROM, RCPT TO och DATA gör, och se på en svarskod om ett fel är tillfälligt eller permanent.
Nyckelbegrepp: SMTP (RFC 5321), session, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, svarskod (2xx, 3xx, 4xx, 5xx), utökad statuskod, tillägg (STARTTLS, AUTH, SIZE), null MX
Ett samtal i vanlig text
SMTP är ett mycket gammalt protokoll (den första versionen är från 1982) och därför mycket läsbart. Två servrar skickar textrader till varandra. Avsändaren (klienten) skickar ett kommando, mottagaren (servern) svarar med ett tresiffrigt tal och en kort förklaring. Du kan läsa ett sådant samtal ordagrant i ett felmeddelande eller en loggfil, och just därför lönar det sig att förstå det.
Nedan följer ett komplett samtal. S: är den mottagande servern, C: den sändande servern. Mejlet går från anna@example.com till 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
(härifrån är anslutningen krypterad; klienten skickar 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: 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 ByeKommandona ett efter ett
| Kommando | Betydelse | Observera |
|---|---|---|
| (anslutning) | Servern hälsar med 220 och sitt namn. | Detta kallas bannern. Säger servern direkt 554, vill den inte alls prata med din IP-adress (ofta en blocklista). |
EHLO namn | "Hej, jag är out.hosting.example." Servern svarar med de tillägg den känner till. | Namnet bör vara det verkliga namnet på den sändande servern, helst samma som dess PTR-post (lektion 5.1). HELO är den gamla varianten utan tillägg. |
STARTTLS | "Låt oss kryptera från och med nu." | Endast om servern erbjuder det. Mellan servrar är detta oftast frivilligt (lektion 5.4). |
MAIL FROM:<adress> | Envelope sender (envelope-avsändaren): hit går felmeddelanden. | Blir senare rubrikraden Return-Path. SPF kontrollerar den här adressen. En tom avsändare <> används av servrar för egna felmeddelanden, så att en bounce aldrig ger upphov till en ny bounce. |
RCPT TO:<adress> | Mottagaren. Kan upprepas, en gång per mottagare. | Här bör servern redan säga om adressen finns. En 550 5.1.1 vid det här tillfället är ett tydligt, direkt igenkännbart fel. |
DATA | "Nu kommer själva mejlet." Servern svarar 354. | Därefter följer rubrikraderna, en tom rad och texten. En rad med enbart en punkt avslutar. |
QUIT | Slut på samtalet. |
Den viktigaste insikten: allt före DATA är envelope, allt efter DATA är innehållet. Det som står i MAIL FROM och det som står i rubrikraden From: levereras separat och behöver inte vara desamma. Servern levererar utifrån RCPT TO; raden To: i innehållet spelar ingen roll vid leveransen.
Svarskoderna
Den första siffran i koden är den viktigaste:
| Börjar med | Betydelse | Vad gör avsändaren? |
|---|---|---|
| 2 | Lyckades. | Vidare till nästa steg. 250 efter DATA betyder: servern har tagit emot mejlet och är nu ansvarig för det. |
| 3 | Fortsätt, jag väntar på mer. | Endast vid 354 efter DATA (och vid inloggning). |
| 4 | Tillfälligt fel: inte nu, försök senare. | Mejlet stannar i kön och levereras igen senare. |
| 5 | Permanent fel: detta kommer inte att lyckas. | Avsändaren ger upp och skickar ett felmeddelande (bounce) till envelope-avsändaren. |
Efter de tre siffrorna anger moderna servrar en utökad statuskod i formen class.subject.detail (RFC 3463), till exempel 5.1.1. Den första siffran är återigen 2, 4 eller 5. Den andra siffran anger vad det handlar om: 1 = adress, 2 = brevlåda, 3 = mailsystem, 4 = nätverk och routing, 5 = protokoll, 6 = innehåll, 7 = säkerhet och policy. Några du ofta ser:
550 5.1.1 The email account that you tried to reach does not exist
452 4.2.2 Mailbox full (tillfälligt)
552 5.3.4 Message size exceeds fixed limit
451 4.7.1 Greylisted, please try again later
550 5.7.1 Message rejected (policy: spam, blocklista, DMARC)I modul 6 lär du dig läsa en fullständig bounce och hittar en tabell med de vanligaste koderna.
Varför tillfälligt och permanent är så viktigt
En server som tvekar svarar ofta med en 4xx. Ett känt exempel är greylisting: en server som ännu inte känner till en avsändare säger första gången "försök senare". En riktig mailserver kommer tillbaka efter några minuter, många spamprogram gör det inte. Även stora mottagare använder 4xx för att bromsa takten om de ännu inte litar på en IP-adress. För dig som avsändare betyder det: fördröjning, men ingen förlust. Systemet löser det oftast själv.
En 5xx är annorlunda. Där försöker avsändaren inte igen. Får du en 5xx tillbaka måste någon ändra något: adressen, innehållet, eller inställningarna för det sändande domänet.
En fallgrop: vissa servrar ger en 5xx trots att problemet är tillfälligt (till exempel vid en full brevlåda 552 5.2.2), och andra ger en 4xx för något som aldrig kommer att lyckas. Läs därför alltid texten efter koden, inte bara siffran.
Vem är ansvarig?
Efter 250 på punkten i DATA ligger ansvaret hos den mottagande servern. Lyckas den inte därefter lägga mejlet i brevlådan, måste den själv skicka tillbaka ett felmeddelande. Det är källan till ett besvärligt fenomen: backscatter. En server som först tar emot allt och sedan senare kommer på att adressen inte finns, skickar en bounce till envelope-avsändaren. Var den förfalskad av en spammare, får en oskyldig tredje part bouncen. Därför bör servrar redan vid RCPT TO avvisa det som inte går (se även catch-all i lektion 3.3).
I praktiken: se SMTP i din egen miljö
En vanlig användare ser sällan hela SMTP-samtalet, men väl i delar:
- i en bounce står den sista raden av samtalet, till exempel
Remote-MTA: mx1.mailprovider.exampleochDiagnostic-Code: smtp; 550 5.1.1 ...; - i rubrikraderna för ett mottaget mejl står per server en
Received:-rad med EHLO-namnet och IP-adressen (lektion 1.5); - i en panel med maillogg, som E-postspårning i DirectAdmin hos WebOké, ser du per meddelande svaret från den mottagande servern. Hos andra leverantörer kallas något liknande till exempel meddelandespårning eller mail log, och innehållet är jämförbart.
Du behöver alltså inte själv ansluta till en mailserver för att kunna läsa detta. Den som vill testa: med openssl s_client -starttls smtp -connect server:25 kan du föra samtalet för hand, men många hemleverantörer blockerar utgående trafik på port 25 (lektion 1.4).
Sammanfattning
- SMTP är ett läsbart samtal: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
- Allt före DATA är envelope (leverans och felmeddelanden), allt efter är innehållet med de rubrikrader du ser.
- 2xx = lyckades, 4xx = tillfälligt (försök igen senare), 5xx = permanent (bounce).
- Den utökade koden
X.Y.Zberättar vad det handlar om; X.1 adress, X.2 brevlåda, X.7 policy och säkerhet. - Läs alltid texten efter koden; servrar är inte alltid konsekventa.
Quiz
Uppgift
Uppgift Z1.2: En domän som inte tar emot mail. Slå upp MX-posterna för example.com. Fyll i vad du hittar och välj vad en sändande server gör med mejl till info@example.com: (a) levererar till servern med prioritet 0, (b) försöker med A-posten, (c) ger upp direkt, eller (d) försöker igen senare. Programmet slår upp MX-posten live och kontrollerar svaret.
Läs mer
Stegen i dessa artiklar gäller för panelerna hos WebOké; hos andra leverantörer fungerar det på liknande sätt.
- Så fungerar det när e-post skickas (SMTP)
- E-postleverans misslyckades: så läser du felmeddelandet och vad koderna betyder
- DirectAdmin-guide 9.3: E-postspårning: vart tog mitt mejl vägen?
- RFC 5321 (SMTP), avsnitt 3 och 4.2 (svarskoder); RFC 3463 (utökade statuskoder); RFC 7505 (null MX)