# E-mail ## Hvad det er E-mail er systemet, der bringer en skrevet besked frem til en adresse som `navn@domæne` og lægger den i en postkasse, hvor den bliver liggende, til ejeren åbner den. Mange skriver det email eller bare mail, og standarderne selv siger for det meste blot mail. Modtageren behøver ikke at være på nettet, når beskeden sendes: servere tager imod den, gemmer den og sender den videre, og derfor kaldes princippet gem-og-videresend frem for en samtale. To dokumenter står for det meste af definitionen. RFC 5322 beskriver, hvad en besked er: en række headerfelter, én blank linje og derefter selve teksten. RFC 5321 beskriver SMTP, protokollen, som en afsendende server bruger til at aflevere beskeden til den næste server på vejen. For at finde den næste server slår afsenderen domænets MX-poster op i DNS, og de navngiver de maskiner, der vil tage imod post til domænet. En fuldstændig besked kan være meget kort: ```text From: Ana Holm To: ordre@example.com Date: Fri, 16 Oct 2026 09:14:00 +0200 Subject: Faktura 114 har forkert momsnummer Message-ID: <20261016.0914.ana@example.org> Hej, kan I sende en rettet kopi? ``` Kun to af headerfelterne er obligatoriske: datoen og afsenderens adresse. Resten er valgfrit efter standardens ordlyd, selv om en besked uden emne eller uden besked-id ser sjusket ud for de programmer, der sorterer post. En linje må højst være 998 tegn og bør holde sig inden for 78, fordi mange mailprogrammer stadig klipper eller ombryder alt, der er længere. Der findes et andet, skjult lag. SMTP flytter beskeden i en _konvolut_: en returadresse, hvor fejlrapporter havner, og en liste over modtagere. Konvolutten og de `From:`- og `To:`-linjer, læseren ser, er adskilte og er ofte forskellige. En blindkopi virker, fordi modtageren står på konvolutten og mangler i headerne. En mailingliste virker, fordi konvoluttens returadresse peger på listen, så en afvisning fra en nedlagt abonnent havner hos listesoftwaren i stedet for hos den, der skrev indlægget. ## Hvorfor det betyder noget En e-mailadresse er den identitet, det meste af nettet falder tilbage på. Bekræftelser ved tilmelding, nulstilling af adgangskoder, kvitteringer, fakturaer og beskeden om, at en betaling er afvist, rejser alle med posten. Et produkt, hvis post forsvinder, har altså brugere, der er låst ude, uden at nogen opdager det. Den, der aldrig fik sit bekræftelseslink, skriver sjældent for at sige det. Vedkommende går bare. E-mail har heller ingen ejer. Ethvert domæne kan køre sine egne servere, og enhver server kan tale med enhver anden, og den åbenhed er grunden til, at e-mail har overlevet næsten alle beskedtjenester, der er bygget siden. Prisen er tillid. Det oprindelige design lader en afsender skrive hvad som helst i `From:`-linjen, så modtagende servere afgør nu selv, om de vil tro på en besked. De afgør det ud fra beviser, som det afsendende domæne offentliggør i DNS: hvilke værter der må sende på dets vegne, hvilke nøgler der signerer dets post, og hvad der skal ske med en besked, der påstår at komme fra domænet og hverken har det ene eller det andet. For en virksomhed er den nyttige opdeling mellem to slags trafik. Transaktionsmail går til én person på grund af noget, den person lige har gjort: en kode, en kvittering, et link til nulstilling. Massemail går til mange, fordi afsenderen har valgt at sende den. De to opbygger hver sit omdømme, får klager i forskelligt tempo og sendes ofte fra forskellige domæner, så blandes de, kan et nyhedsbrev, der irriterer folk, forsinke nulstillingen af en adgangskode. Til sidst er der spørgsmålet om, hvor posten bor. At drive en mailserver betyder lagerplads, spamfiltrering, opdateringer og et afsenderomdømme, der skal tjenes og holdes ved lige. En hostet postkasse til læsning og en afsendertjeneste til automatisk post er det almindelige svar, og det er et valg, der er værd at træffe bevidst frem for at lade det ske af sig selv. ## Sådan ser det ud i praksis På én platform bar posten verifikation, notifikationer, sammendrag og kampagner, og med kun én udbyder blev ethvert udfald totalt. Svaret blev at sætte [tre udbydere bag én grænseflade med automatisk failover](/da/portfolio/built-email-as-a-platform-capability-with-failover-62/): SendGrid først, derefter SMTP2GO og Azure Communication Services. Indgående webhooks fortæller, hvad hver udbyder gjorde med en besked, og begge sider ender i en afsendelseslog og en tabel over leveringshændelser, så om en person fik sin verifikationsmail, er en databaseforespørgsel og ikke et gæt. Kampagner til udvalgte grupper af brugere kører i et separat broadcast-skema på 5 tabeller og 24 funktioner, bygget adskilt fra transaktionsmail, fordi det er et andet problem. Et opstartstjek sender en rigtig besked gennem hele kæden bag et flag; i udvikling bliver en fejl til en advarsel i loggen, og i staging og produktion stopper den processen. Siden nævner også prisen: tre integrationer, der skal holdes kørende, og leveringslogge, der vokser og skal ryddes op. Virksomhedens egen post begynder i DNS. Zonen rummer omkring tyve poster, blandt dem postruting gennem en hostet postkasseudbyder, et domæne til transaktionsmail og autentificeringsposterne for begge, og [hele zonen ligger som data i repositoriet](/da/portfolio/reconciled-a-dns-zone-declaratively-118/) og afstemmes mod udbyderens API. Et revisionsindgangspunkt viser forskellen mellem erklæringen og det, der faktisk serveres, uden at ændre noget, og det er den del, der bruges mest. Hvor virksomhedens egen post skal bo, blev afgjort af regnestykket. De offentlige tjenester kører på [én vært med 512 MB hukommelse](/da/portfolio/ran-the-whole-company-on-one-512mb-host-109/), og posten holdes bevidst væk fra den maskine: en mailserver kræver luft, som værten allerede har brugt, så den er skrevet som et installationsstillads, der venter på sin egen vært. Imens læses breve til virksomheden i dens egen postkasse, som hostes hos Apple iCloud, og der står ingen mailingliste bag. ## Hvor det går galt **Post begynder at lande i spam den uge, udbyderen skiftes.** Intet i applikationen er ændret, men modtagerne bliver mistænksomme. Domænets offentliggjorte poster nævner stadig den gamle afsender, så post fra den nye ankommer usigneret eller fra en vært, domænet aldrig har godkendt. Føj den nye afsender til posterne før skiftet, behold den gamle, til dens sidste besked er sendt, og læs de samlede rapporter, modtagerne sender tilbage, hvis domænet beder om dem. **Applikationen starter, og ingen modtager noget.** En udløbet nøgle eller en suspenderet afsenderkonto ligner præcis en fungerende opsætning, indtil en rigtig person venter på en kode. Send en rigtig besked ved opstart, hvor stilhed er farlig, og registrér, hvad udbyderen siger, der skete med hver besked, så en besked, der aldrig kom frem, kan spores i stedet for at blive diskuteret. **Afvisninger hober sig op hos en adresse, ingen læser.** Konvoluttens returadresse peger på en `no-reply`-boks, så permanente fejl ankommer og bliver liggende uåbnede. Afsenderen bliver ved med at skrive til postkasser, der lukkede for et år siden, og modtagerne læser det som en spammers vane. Lad returadressen pege på noget, der behandler rapporterne, og hold op med at skrive til en adresse efter en permanent fejl. **En midlertidig afvisning behandles som endelig.** SMTP-svar, der begynder med 4, betyder prøv igen senere; svar, der begynder med 5, betyder stop. En afsender, der giver op ved første 4xx, mister post, som en travl eller forsigtig server ville have taget imod en halv time senere. RFC 5321 beder om nye forsøg med mindst 30 minutters mellemrum og om at vente mindst fire til fem dage, før man giver op. Transaktionsmail vil som regel have hurtigere forsøg med stigende pauser og en tydelig registrering, når afsenderen til sidst holder op. ## Læs mere - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322) — headerfelterne, den blanke linje, grænserne for linjelængde og de to felter, enhver besked skal have. - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) — konvolutten, svarkoderne, opslaget af MX-poster og rådene om nye forsøg. - [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208) — hvordan et domæne oplister de værter, der må sende post i dets navn. - [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376) — signering af headere og tekst med en nøgle, modtageren henter i DNS. - [RFC 7489: DMARC](https://www.rfc-editor.org/rfc/rfc7489) — binder begge tjek til domænet i den synlige `From:`-linje med en politik og rapporter; et informativt dokument, ikke en standard.