Reisen til en e-post

Modul 1: Hvordan e-post fungerer · Lesetid: 9 minutter

Læringsmål: Etter denne leksjonen kan du beskrive steg for steg hvordan en e-post kommer fra avsenderen til mottakeren, og for hvert steg si hvilket program eller hvilken server som gjør jobben.

Nøkkelbegreper: e-postprogram (MUA), utsendingsserver (MSA, submission), mailserver (MTA), MX-post, kø, levering (MDA), mailboks, henting (IMAP/POP3), konvolutt (envelope), headere

E-post er post, ikke en chattemelding

Når du sender en chattemelding, går den via ett selskap: appen til avsenderen og appen til mottakeren snakker med de samme serverne. E-post fungerer annerledes. Avsenderen og mottakeren kan være hos hver sin leverandør: den ene hos et webhotell, den andre hos Gmail, en tredje hos Microsoft 365 eller på sin egen bedriftsserver. Likevel kommer e-posten frem. Det går fordi alle mailservere i verden følger de samme reglene.

Du kan sammenligne e-post med vanlig post. Du skriver et brev (meldingen), putter det i en konvolutt med en adresse (konvolutten/envelope), leverer det i postkassen (utsendingsserveren), postselskapet finner ut hvor adressen ligger (MX-oppslaget), frakter brevet til riktig sorteringssentral (den mottakende mailserveren), og den legger det i mottakerens postkasse (mailboksen). Mottakeren henter det der når det passer.

Stasjonene på rad

Si at Anna sender e-post fra anna@example.com til jan@example.net. Dette skjer:

Hos mindre leverandører er MSA, MTA og MDA ofte ett og samme program på én server. Hos store leverandører er det egne klynger. For deg som bruker spiller det liten rolle: det er roller, ikke fysiske bokser.

Legg merke til forskjellen mellom steg 1 og steg 4. Begge bruker SMTP, Simple Mail Transfer Protocol (RFC 5321). Men i steg 1 logger du inn og bruker port 587 eller 465; det kalles submission (RFC 6409). I steg 4 snakker to servere sammen på port 25, uten innlogging: den mottakende serveren tar imot e-post for sine egne domener fra hvem som helst. I leksjon 1.4 ser du hvorfor dette skillet finnes.

Steg 3 nærmere: MX-oppslaget

Den utsendende serveren vet ikke av seg selv hvor example.net mottar e-posten sin. Den spør DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Det laveste tallet har prioritet. Serveren prøver først mx1, og hvis den ikke svarer, mx2. Deretter slår den opp IP-adressen til det navnet (A- eller AAAA-post) og kobler seg til.

To spesielle tilfeller du kan støte på i praksis:

• Ingen MX-post. Da prøver avsenderen A- eller AAAA-posten til selve domenet (den "implisitte MX-en" fra RFC 5321, avsnitt 5.1). Det er en rest fra tidligere og fungerer ikke pålitelig; hvert domene som mottar e-post, bør ha en MX.
• En null MX: 0 . Dette betyr: "dette domenet mottar aldri e-post" (RFC 7505). Domenet example.com har en slik. En avsender gir da opp umiddelbart og sender en feilmelding tilbake, i stedet for å fortsette å prøve i flere dager.

Hvordan MX-poster og prioriteter fungerer i detalj, kan du lese i leksjon 4.1 i DNS-kurset.

Køen: e-post kan ta litt tid

En e-post er ikke alltid fremme i løpet av et sekund. Svarer ikke den mottakende serveren, eller sier den "prøv igjen senere" (en kode som starter med 4), blir e-posten liggende i køen til utsendingsserveren. Den prøver igjen senere, med stadig lengre tid mellom forsøkene. RFC 5321 (avsnitt 4.5.4.1) anbefaler minst 30 minutter mellom forsøk og å gi opp først etter 4 til 5 dager. Mange servere sender en advarsel etter noen timer ("delayed", ennå ikke levert) og den endelige feilmeldingen etter noen dager.

Dette er en stor styrke ved e-post: går en mailserver ned i en time, går ingen e-post tapt. Det er også grunnen til at en e-post noen ganger først kommer frem flere timer senere. I modul 6 ser du hvordan du gjenkjenner en slik forsinkelse.

Konvolutt og headere: to adresser

Akkurat som med vanlig post har en e-post to typer adresser:

• Konvolutten (envelope). Det er adressene serverne bruker seg imellom i SMTP-samtalen: MAIL FROM (avsenderen for feilmeldinger, senere synlig som Return-Path) og RCPT TO (mottakeren). Serverne leverer basert på konvolutten.
• Headerne. Det er det som står i selve brevet: From:, To:, Cc:, Subject:, Date:. E-postprogrammet ditt viser disse.

Som regel er de like, men ikke alltid. En BCC-mottaker står i konvolutten, men ikke i headerne; derfor ser ikke andre vedkommende. En nyhetsbrevtjeneste setter sin egen adresse som konvolutt-avsender (envelope sender), slik at feilmeldinger havner hos tjenesten, mens From: viser din adresse. Og en svindler kan skrive hva han vil i From:.

Hvorfor dette betyr noe: SPF kontrollerer konvolutt-avsenderen (envelope sender), brukeren ser From:. Derfor finnes DMARC, som kobler disse to sammen (modul 4).

Hvor det kan gå galt

Med dette bildet kan du ved ethvert problem spørre: ved hvilken stasjon går det galt?

• Sending lykkes ikke (feilmelding med en gang i programmet ditt): steg 1 eller 2. Nesten alltid innstillinger: port, innlogging, passord (modul 2).
• Du får en bounce tilbake: steg 4 eller 5. Den mottakende serveren avviste e-posten, eller adressen finnes ikke (modul 6).
• E-posten kommer frem, men i spammappen: steg 5. Mottakeren stoler ikke på e-posten (modul 4 og 5).
• Mottakeren ser ingenting, og du får ingen feilmelding: e-posten ligger kanskje fortsatt i en kø, eller er blitt filtrert bort stille hos mottakeren. Her hjelper loggene til utsendingsserveren (modul 6).
• E-post kommer ikke frem i det hele tatt for domenet ditt: steg 3. MX-postene stemmer ikke, for eksempel etter en flytting (modul 8).

I praksis: slik ser det ut hos en hostingpakke

Hos en hostingpakke fra WebOké utfører én server per pakke alle rollene: e-postprogrammet ditt leverer e-posten til den serveren (steg 1 og 2), serveren sender den videre ut (steg 3 og 4) og mottar e-post for domenet ditt (steg 5). I DirectAdmin kan du bruke E-mail Tracking til å se per melding om den er levert. Hos andre leverandører fungerer det på lignende måte; der kalles en slik funksjon for eksempel "meldingssporing" eller "mail log".

Oppsummering

• En e-post går fra e-postprogrammet ditt (MUA) via utsendingsserveren (MSA/MTA) til den mottakende serveren (MTA/MDA) og derfra til mottakerens e-postprogram.
• Sending fra programmet ditt er SMTP-submission med innlogging (587/465); servere snakker SMTP seg imellom på port 25; henting skjer med IMAP eller POP3.
• Den utsendende serveren slår opp MX-postene til domenet etter @-tegnet. En null MX (0 .) betyr: dette domenet mottar ikke e-post.
• En e-post som ikke kan leveres med en gang, blir liggende i køen og det prøves på nytt i flere dager.
• Konvolutt (Return-Path) og headere (From) er to forskjellige avsendere. SPF ser på den første, brukeren på den andre.

Quiz

Oppgave

Oppgave Z1.1: Finne den første mailserveren. Slå opp MX-postene til gmail.com (eller til ditt eget domene). Fyll inn hvilken server som prøves først, med prioritetstallet, og én IP-adresse (IPv4 eller IPv6) til den serveren. Programmet henter de samme opplysningene live og kontrollerer dem.

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
• DirectAdmin-veiledning 8.7: IMAP eller POP3: hva er forskjellen?
• Gratis DNS-kurs 4.1: MX-poster og prioritet
• RFC 5321 (SMTP), avsnitt 5.1 (MX og implisitt MX) og 4.5.4.1 (nye forsøk); RFC 7505 (null MX)