En e-mails rejse

Modul 1: Sådan virker e-mail · Læsetid: 9 minutter

Læringsmål: Efter denne lektion kan du trin for trin beskrive, hvordan en mail kommer fra afsenderen til modtageren, og ved hvert trin sige hvilket program eller hvilken server der udfører arbejdet.

Centrale begreber: mailprogram (MUA), afsendelsesserver (MSA, submission), mailserver (MTA), MX-record, kø, levering (MDA), mailboks, hentning (IMAP/POP3), envelope, headere

Mail er post, ikke en chatbesked

Når du sender en chatbesked, går den via én udbyder: afsenderens app og modtagerens app taler med de samme servere. E-mail fungerer anderledes. Afsenderen og modtageren kan hver sidde hos en anden udbyder: den ene hos et hostingfirma, den anden hos Gmail, en tredje hos Microsoft 365 eller på sin egen firmaserver. Alligevel kommer mailen frem. Det lykkes, fordi alle mailservere i verden følger de samme aftaler.

Du kan sammenligne e-mail med almindelig post. Du skriver et brev (beskeden), putter det i en kuvert med en adresse (envelope), bringer det til postkassen (afsendelsesserveren), postselskabet finder ud af, hvor adressen ligger (MX-opslaget), transporterer brevet til det rigtige sorteringscenter (den modtagende mailserver), som så lægger det i modtagerens postkasse (mailboksen). Modtageren henter det der, når det passer ham.

Stationerne i rækkefølge

Lad os sige, at Anna sender en mail fra anna@example.com til jan@example.net. Sådan foregår det:

Hos mindre udbydere er MSA, MTA og MDA ofte ét og samme program på én server. Hos store udbydere er det adskilte klynger. For dig gør det ikke den store forskel: det er roller, ikke fysiske kasser.

Læg mærke til forskellen mellem trin 1 og trin 4. Begge bruger SMTP, Simple Mail Transfer Protocol (RFC 5321). Men ved trin 1 logger du ind og bruger port 587 eller 465; det kaldes submission (RFC 6409). Ved trin 4 taler to servere sammen på port 25, uden login: den modtagende server tager imod mail for sine egne domæner fra hvem som helst. I lektion 1.4 kan du se, hvorfor denne adskillelse findes.

Trin 3 i detaljer: MX-opslaget

Den afsendende server ved ikke af sig selv, hvor example.net modtager sin mail. Den spørger DNS'en:

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

Det laveste tal har forrang. Serveren forsøger først mx1, og hvis den ikke svarer, mx2. Derefter slår den IP-adressen for det navn op (A- eller AAAA-record) og opretter forbindelse.

To særlige tilfælde, du kan støde på i praksis:

• Intet MX-record. Så forsøger afsenderen med A- eller AAAA-recordet for selve domænet (den "implicitte MX" fra RFC 5321, afsnit 5.1). Det er en rest fra tidligere og virker ikke pålideligt; ethvert domæne, der modtager mail, bør have et MX-record.
• Et null MX: 0 . Dette betyder: "dette domæne modtager aldrig mail" (RFC 7505). Domænet example.com har sådan et. En afsender giver straks op og sender en fejlmeddelelse tilbage i stedet for at blive ved med at forsøge i dagevis.

Hvordan MX-records og prioriteter nøjagtigt fungerer, kan du læse om i lektion 4.1 af DNS-kurset.

Køen: e-mail må gerne tage lidt tid

En mail er ikke altid fremme inden for et sekund. Svarer den modtagende server ikke, eller siger den "prøv igen senere" (en kode der starter med 4), bliver mailen stående i afsendelsesserverens kø. Den forsøger igen senere, med stadig længere mellemrum. RFC 5321 (afsnit 4.5.4.1) anbefaler mindst 30 minutter mellem forsøg og først at give op efter 4 til 5 dage. Mange servere sender efter nogle timer allerede en advarsel ("delayed", endnu ikke leveret) og efter nogle dage den endelige fejlmeddelelse.

Det er en af e-mailens store styrker: hvis en mailserver er nede i en time, går der ikke mail tabt. Det er også grunden til, at en mail nogle gange først kommer frem timer senere. I modul 6 kan du se, hvordan du genkender sådan en forsinkelse.

Envelope og headere: to adresser

Ligesom med almindelig post har en mail to slags adresser:

• Envelope. Det er de adresser, serverne bruger indbyrdes i SMTP-samtalen: MAIL FROM (afsenderen for fejlmeddelelser, senere synlig som Return-Path) og RCPT TO (modtageren). Serverne leverer på baggrund af envelopen.
• Headerne (headers). Det er det, der står i selve brevet: From:, To:, Cc:, Subject:, Date:. Dit mailprogram viser disse.

Som regel er de ens, men ikke altid. En BCC-modtager står godt nok i envelopen, men ikke i headerne; derfor ser andre ham ikke. En nyhedsbrevstjeneste sætter sin egen adresse som envelope-afsender (envelope sender), så fejlmeddelelser havner hos tjenesten, mens der i From: står din adresse. Og en svindler kan skrive hvad som helst i From:.

Hvorfor det har betydning: SPF kontrollerer envelope-afsenderen, brugeren ser From:. Derfor findes DMARC, som kobler de to sammen (modul 4).

Hvor det kan gå galt

Med dette billede i baghovedet kan du ved ethvert problem spørge: ved hvilken station går det galt?

• Afsendelse lykkes ikke (fejlmeddelelse med det samme i dit program): trin 1 eller 2. Næsten altid indstillinger: port, login, adgangskode (modul 2).
• Du får en bounce tilbage: trin 4 eller 5. Den modtagende server afviste mailen, eller adressen findes ikke (modul 6).
• Mailen kommer frem, men i spammappen: trin 5. Modtageren stoler ikke på mailen (modul 4 og 5).
• Modtageren ser ingenting, og du får ingen fejlmeddelelse: mailen ligger måske stadig i en kø, eller er blevet filtreret stille hos modtageren. Her hjælper afsendelsesserverens logs (modul 6).
• Mail kommer slet ikke ind for dit domæne: trin 3. MX-records stemmer ikke, for eksempel efter en flytning (modul 8).

I praksis: sådan ser det ud med en hostingpakke

Med en hostingpakke fra WebOké udfører én server pr. pakke alle rollerne: dit mailprogram afleverer mailen til den server (trin 1 og 2), serveren sender den videre ud (trin 3 og 4) og modtager mail for dit domæne (trin 5). I DirectAdmin kan du med E-mailsporing se pr. besked, om den er blevet leveret. Hos andre udbydere fungerer det tilsvarende; der hedder sådan en funktion for eksempel "message tracking" eller "mail log".

Opsummering

• En mail går fra dit mailprogram (MUA) via afsendelsesserveren (MSA/MTA) til den modtagende server (MTA/MDA) og derfra til modtagerens mailprogram.
• Afsendelse fra dit program er SMTP-submission med login (587/465); servere taler indbyrdes SMTP på port 25; hentning foregår med IMAP eller POP3.
• Den afsendende server slår domænets MX-records op efter @-tegnet. Et null MX (0 .) betyder: dette domæne modtager ikke mail.
• En mail, der ikke kan leveres med det samme, bliver i køen og forsøges igen i flere dage.
• Envelope (Return-Path) og headere (From) er to forskellige afsendere. SPF kigger på den første, brugeren på den anden.

Quiz

Opgave

Opgave Z1.1: Find den første mailserver. Slå MX-records op for gmail.com (eller for dit eget domæne). Angiv hvilken server der forsøges først, med dens prioritetstal, og én IP-adresse (IPv4 eller IPv6) for den server. Programmet slår de samme oplysninger op live og kontrollerer dem.

Læs videre

Trinnene i disse artikler gælder for WebOkés kontrolpaneler; hos andre udbydere fungerer det tilsvarende.

• Sådan bliver e-mails sendt / SMTP
• DirectAdmin vejledning 8.7: IMAP eller POP3: hvad er forskellen?
• Gratis DNS-kursus 4.1: MX-records og prioritet
• RFC 5321 (SMTP), afsnit 5.1 (MX og implicit MX) og 4.5.4.1 (gentagne forsøg); RFC 7505 (null MX)