Modul 1 · 1.2
SMTP: samtalen mellom mailservere
Modul 1: Hvordan e-post fungerer · Lesetid: 10 minutter
Læringsmål: Etter denne leksjonen kan du lese en SMTP-samtale, forklare hva EHLO, MAIL FROM, RCPT TO og DATA gjør, og se av en svarkode om en feil er midlertidig eller endelig.
Nøkkelbegreper: SMTP (RFC 5321), sesjon, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, svarkode (2xx, 3xx, 4xx, 5xx), utvidet statuskode, utvidelser (STARTTLS, AUTH, SIZE), null MX
En samtale i vanlig tekst
SMTP er en veldig gammel protokoll (den første versjonen er fra 1982) og derfor veldig lesbar. To servere sender hverandre tekstlinjer. Avsenderen (klienten) sender en kommando, mottakeren (serveren) svarer med et tresifret tall og en liten forklaring. Du kan lese en slik samtale direkte i en feilmelding eller en logg, og det er nettopp derfor det lønner seg å forstå den.
Nedenfor en komplett samtale. S: er mottaksserveren, C: er avsenderserveren. E-posten 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
(fra nå av er forbindelsen kryptert; klienten sender EHLO på nytt)
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 ByeKommandoene, en for en
| Kommando | Betydning | Legg merke til |
|---|---|---|
| (tilkobling) | Serveren hilser med 220 og sitt eget navn. | Dette kalles banneret. Sier serveren med en gang 554, vil den overhodet ikke snakke med IP-adressen din (ofte en blokkeringsliste). |
EHLO navn | "Hei, jeg er out.hosting.example." Serveren svarer med utvidelsene den kjenner til. | Navnet bør være det virkelige navnet til avsenderserveren, helst likt dens PTR-record (leksjon 5.1). HELO er den gamle varianten uten utvidelser. |
STARTTLS | "La oss kryptere fra nå av." | Bare hvis serveren tilbyr det. Mellom servere er dette som regel frivillig (leksjon 5.4). |
MAIL FROM:<adresse> | Envelope sender (envelope-avsender): hit går feilmeldinger. | Blir senere headeren Return-Path. SPF kontrollerer denne adressen. En tom avsender <> bruker servere til egne feilmeldinger, slik at en bounce aldri resulterer i en ny bounce. |
RCPT TO:<adresse> | Mottakeren. Kan gjentas, én gang per mottaker. | Her bør serveren allerede si om adressen finnes. En 550 5.1.1 på dette tidspunktet er en ryddig feil som er kjent med en gang. |
DATA | "Nå kommer selve e-posten." Serveren svarer 354. | Deretter følger headerne, en tom linje og teksten. En linje med bare et punktum avslutter. |
QUIT | Slutt på samtalen. |
Det viktigste poenget: alt før DATA er envelope, alt etter DATA er innholdet. Det som står i MAIL FROM og det som står i headeren From:, leveres hver for seg og trenger ikke være like. Serveren leverer basert på RCPT TO; To:-linjen i innholdet spiller ingen rolle for leveringen.
Svarkodene
Det første sifferet i koden er det viktigste:
| Begynner med | Betydning | Hva gjør avsenderen? |
|---|---|---|
| 2 | Vellykket. | Gå videre til neste steg. 250 etter DATA betyr: serveren har tatt imot e-posten og er nå ansvarlig for den. |
| 3 | Fortsett, jeg venter på mer. | Bare ved 354 etter DATA (og ved innlogging). |
| 4 | Midlertidig feil: ikke nå, prøv senere. | E-posten blir i køen og tilbys på nytt senere. |
| 5 | Endelig feil: dette kommer ikke til å gå. | Avsenderen gir opp og sender en feilmelding (bounce) til envelope-avsenderen. |
Bak de tre sifrene finner du hos moderne servere en utvidet statuskode i formen class.subject.detail (RFC 3463), for eksempel 5.1.1. Det første sifferet er igjen 2, 4 eller 5. Det andre sifferet forteller hva det gjelder: 1 = adresse, 2 = mailbox, 3 = mailsystem, 4 = nettverk og ruting, 5 = protokoll, 6 = innhold, 7 = sikkerhet og retningslinjer. Noen 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 (retningslinjer: spam, blokkeringsliste, DMARC)I modul 6 lærer du å lese en fullstendig bounce, og du finner en tabell med de vanligste kodene.
Hvorfor midlertidig og endelig er så viktig
En server som er i tvil, svarer ofte med en 4xx. Et kjent eksempel er greylisting: en server som ennå ikke kjenner en avsender, sier første gang "prøv igjen senere". En ekte mailserver kommer tilbake etter noen minutter, mange spamprogrammer gjør ikke det. Også store mottakere bruker 4xx for å dempe tempoet når de ennå ikke stoler på en IP-adresse. For deg som avsender betyr det: forsinkelse, men ikke tap. Systemet løser det som regel selv.
En 5xx er annerledes. Der prøver avsenderen ikke på nytt. Får du en 5xx tilbake, må noen endre noe: adressen, innholdet, eller innstillingene til det avsendende domenet.
En fallgruve: noen servere gir en 5xx selv om problemet er midlertidig (for eksempel ved en full mailbox 552 5.2.2), og andre gir en 4xx for noe som aldri kommer til å gå. Les derfor alltid teksten bak koden, ikke bare tallet.
Hvem er ansvarlig?
Etter 250 på punktumet til DATA ligger ansvaret hos mottaksserveren. Klarer den ikke etterpå å legge e-posten i mailboxen, må den selv sende en feilmelding tilbake. Det er kilden til et vanskelig fenomen: backscatter. En server som først tar imot alt og først senere oppdager at adressen ikke finnes, sender en bounce til envelope-avsenderen. Var den forfalsket av en spammer, får en uskyldig tredjepart bouncen. Derfor bør servere allerede ved RCPT TO avvise det som ikke kan leveres (se også catch-all i leksjon 3.3).
I praksis: å se SMTP i ditt eget miljø
En vanlig bruker ser sjelden hele SMTP-samtalen, men ser biter av den:
- i en bounce står den siste linjen i samtalen, for eksempel
Remote-MTA: mx1.mailprovider.exampleogDiagnostic-Code: smtp; 550 5.1.1 ...; - i headerne til en mottatt e-post står det per server en
Received:-linje med EHLO-navnet og IP-adressen (leksjon 1.5); - i et panel med maillogg, som E-mail Tracking i DirectAdmin hos WebOké, ser du for hver melding svaret fra mottaksserveren. Hos andre leverandører heter noe lignende for eksempel meldingssporing eller mail log, og innholdet er sammenlignbart.
Du trenger altså ikke selv koble deg til en mailserver for å kunne lese dette. Den som likevel vil prøve: med openssl s_client -starttls smtp -connect server:25 kan du føre samtalen manuelt, men mange hjemmeleverandører blokkerer utgående trafikk på port 25 (leksjon 1.4).
Oppsummering
- SMTP er en lesbar samtale: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
- Alt før DATA er envelope (levering og feilmeldinger), alt etter er innholdet med headerne du ser.
- 2xx = vellykket, 4xx = midlertidig (prøves igjen senere), 5xx = endelig (bounce).
- Den utvidede koden
X.Y.Zforteller hva det gjelder; X.1 adresse, X.2 mailbox, X.7 retningslinjer og sikkerhet. - Les alltid teksten bak koden; servere er ikke alltid konsekvente.
Quiz
Oppgave
Oppgave Z1.2: Et domene som ikke mottar e-post. Slå opp MX-recordene til example.com. Fyll inn det du finner og velg hva en avsenderserver gjør med e-post til info@example.com: (a) levere til serveren med prioritet 0, (b) prøve A-recordet, (c) gi opp med en gang, eller (d) prøve på nytt senere. Programmet henter MX-recordet live og sjekker svaret.
Les mer
Stegene i disse artiklene gjelder for panelene til WebOké; hos andre leverandører fungerer det på lignende måte.
- Slik sendes e-post / SMTP forklart
- Mail delivery failed: slik leser du feilmeldingen og hva kodene betyr
- DirectAdmin-veiledning 9.3: E-mail Tracking: hvor ble det av e-posten min?
- RFC 5321 (SMTP), avsnitt 3 og 4.2 (svarkoder); RFC 3463 (utvidede statuskoder); RFC 7505 (null MX)