SMTP: Transport, kø og leveringsansvar

Simple Mail Transfer Protocol (SMTP) bringer en melding fra én e-postprosess til den neste. Klienten kobler seg til en server, spør etter dens funksjoner, oppgir konvoluttavsender og mottaker og overfører først deretter meldingsinnholdet. Serveren svarer på hvert trinn med en numerisk kode. Fra denne tilsynelatende enkle sekvensen oppstår ruting, køsetting, gjenforsøk og det avgjørende spørsmålet om hvilken server som akkurat nå har ansvaret for meldingen (RFC 5321, avsnitt 1 og 2).

For meldingsadministratorer ligger den avgjørende egenskapen i overføringen av ansvar. En vellykket TCP-etablering betyr bare at en lytter er tilgjengelig. En akseptert RCPT TO reserverer en mottaker i den pågående transaksjonen. Først en positiv avslutning etter det fullstendige meldingsinnholdet overfører til det mottakende SMTP-systemet ansvaret for å levere meldingen eller rapportere en senere feil til konvoluttavsenderen (RFC 5321, avsnitt 4.1.1.4 og 6.1). Kø-ID, svarkode, ekstern MTA, mottakerstatus og Received-spor er derfor ikke tilfeldige loggdetaljer, men beviskjeden for en levering.

Forklaringen følger en melding fra den innsendende klienten via SMTP-økt, konvolutt og kø til neste e-postserver eller postboks. DNS, gjenforsøk, statuskoder, sikkerhet og diagnostikk utdypes der de påvirker veien.

Roller og ansvarsområder

SMTP kjenner i utgangspunktet bare klient og server. I en faktisk leveringskjede byttes disse rollene ved hvert hopp: En Mail Transfer Agent tar som server imot en melding, lagrer den i køen sin og blir selv klient ved neste leveringsforsøk. Først gjennom dette rollebyttet kan logger og ansvar leses riktig (RFC 5321, avsnitt 2.3.3, RFC 5598, avsnitt 4, RFC 6409, avsnitt 2.1).

MSA-en er ikke bare en MTA på en annen port. Message Submission skiller kontrollert innsending av nye meldinger fra åpen overføring mellom e-postdomener. En MSA kan blant annet kontrollere avsenderrettigheter, legge til manglende obligatoriske felt og tilpasse meldinger til lokale regler; en etterfølgende MTA bør som hovedregel ikke vilkårlig endre ferdig meldingsinnhold (RFC 6409, avsnitt 1, 6 og 8). Denne grensen er særlig relevant for DKIM-signaturer: Enhver senere endring av signerte headere eller brødteksten kan gjøre signaturen ugyldig.

Grafikken viser logiske grenser. MSA, utgående MTA, gateway og inngående MTA kan kjøre som separate tjenester, befinne seg på samme system eller være skjult av en skyleverandør. Standardene angir ingen prosessarkitektur. Administrativt er skillet likevel nødvendig, fordi hver aksepterte overlevering kan opprette en ny kø, en ny gjenforsøkstilstand og en ny ansvarlig.

Konvolutt og meldingsinnhold

Før dialogen gjennomgås i detalj, må to dataområder skilles: konvolutten for transport og meldingsinnholdet for mottakere og e-postprogrammer. Konvolutten består av en Reverse Path fra MAIL FROM og én eller flere Forward Paths fra RCPT TO. Innholdet følger etter DATA og inneholder et headerområde i henhold til Internet Message Format samt brødteksten, ofte med MIME-struktur (RFC 5321, avsnitt 2.3.1, RFC 5322, avsnitt 2.1).

SMTP-servere må ikke avlede den endelige ruten fra To:, Cc: eller From:. Omvendt trenger ikke konvoluttadresser å forekomme i meldingsheaderen. Derfor fungerer Bcc, e-postlister, videresendinger, SRS og separate bounce-adresser. Skillet forklarer også hvorfor en melding i klienten visuelt kan synes å komme fra ceo@example.ch, mens konvoluttavsenderen bruker et annet domene. SPF vurderer SMTP-stien; DMARC oppretter i tillegg en referanse til synlig From:. Detaljene i disse kontrollene hører hjemme i e-postautentisering (RFC 5321, vedlegg C, RFC 5322, avsnitt 3.6).

En tom Reverse Path overføres som MAIL FROM:<>. Den forhindrer feilrapportsløyfer og er påkrevd for Delivery Status Notifications. En server som generelt avviser tomme avsendere, skader derfor tilbakerapporteringsveien i e-postsystemet (RFC 5321, avsnitt 3.6.3).

SMTP-økt og transaksjon

På en TCP-forbindelse kjører en SMTP-økt; innenfor den kan flere meldinger følge som separate e-posttransaksjoner. Serveren starter med en 220-hilsen; klienten identifiserer seg med EHLO og mottar en øktspesifikk liste over ESMTP-funksjoner. Deretter består en transaksjon av MAIL, minst én akseptert RCPT og DATA eller en forhandlet erstatning som BDAT (RFC 5321, avsnitt 3.1 og 4.1).

1. Forbindelse og hilsen: Klienten kobler seg til; serveren svarer med 220. Hvis den forsinker eller avviser allerede her, finnes det ennå ingen e-posttransaksjon.
2. Funksjonsforhandling: EHLO client.example setter begge parter i initialtilstand og oppgir utvidelser som SIZE, STARTTLS, PIPELINING eller SMTPUTF8. En klient kan ikke forutsette at en annen klyngenode eller en senere økt tilbyr de samme funksjonene.
3. Valgfri TLS-oppgradering: Etter vellykket STARTTLS forkastes SMTP-tilstanden og tidligere lærte funksjoner. Klienten sender EHLO på nytt innenfor den beskyttede kanalen (RFC 3207, avsnitt 4).
4. Konvoluttavsender: MAIL FROM åpner en transaksjon og tømmer tidligere konvolutt- og databufre. ESMTP-parametere som SIZE, BODY eller SMTPUTF8 er knyttet til denne kommandoen.
5. Mottaker: Hver RCPT TO besvares enkeltvis. En server kan akseptere to mottakere og permanent avvise en tredje; klienten sender da innholdet for den aksepterte delmengden.
6. Innhold: Etter DATA følger ved beredskap 354. Klienten overfører headere og brødtekst som CRLF-avsluttede linjer, masker punkter i starten av linjen og avslutter med en linje som kun består av ..
7. Avslutning: Svaret etter denne End-of-Data-markøren avgjør om serveren overtar meldingen som helhet for de tidligere aksepterte mottakerne. RSET forkaster den pågående transaksjonen uten å avslutte økten; QUIT avslutter den på en ordnet måte.

SMTP er lockstep-orientert, men ESMTP-PIPELINING kan tillate at tillatte kommandogrupper sendes uten å vente på hvert enkelt svar. Svarene forblir i mottaksrekkefølge og må fortsatt tilordnes riktig til hver kommando (RFC 2920). Et pakkefangst med flere MAIL-/RCPT-linjer rett etter hverandre er derfor ikke automatisk et protokollbrudd.

Dialogen er dermed fullført, men leveringsansvaret er ennå ikke avklart. Det skifter først med et helt bestemt svar fra den mottakende serveren.

Akseptgrense: 250 etter End-of-Data

Den viktigste SMTP-grensen ligger etter meldingsinnholdet. En 250 på MAIL FROM aksepterer bare Reverse Path. En 250 på RCPT TO aksepterer en mottaker for den pågående transaksjonen. Først en 250 etter End-of-Data-markøren betyr at serveren har overtatt ansvaret for meldingen. Et korrekt system må deretter enten levere den eller opprette en ikke-leveringsrapport ved en senere oppdaget feil; den sendende klienten kan fjerne sin lokale kopi fra det aktive leveringsansvaret (RFC 5321, avsnitt 4.1.1.4 og 6.1).

Denne semantikken gjør siste del av dialogen kritisk. Hvis forbindelsen brytes etter punktet, men før et fullstendig svar er mottatt, vet ikke klienten sikkert om serveren har lagret meldingen. Den må kunne forsøke leveringen på nytt; dermed er duplikater mulig. SMTP gir ingen global Exactly-once-garanti. Systemer trenger derfor idempotent sporing via kø-ID, Message-ID, mottaker, tid, størrelse og eventuelt en proprietær transaksjonsreferanse, uten å likestille disse identifikatorene.

Innholdsfiltre, DLP, skadevarekontroll eller DKIM-signering bør integreres i akseptpipen slik at serveren før det endelige positive svaret vet om den kan overta persistent ansvar. En foranliggende proxy som for tidlig rapporterer 250 og deretter mister meldingen internt, kan ikke lenger returnere feilen til den opprinnelige SMTP-klienten. Nettopp her må en arkitektur fastsette om aksept først bekreftes etter durable write, etter replikering, etter skanning eller allerede ved overlevering til en intern broker. Dette er en produktegenskap, ikke et krav i SMTP-standarden, og må dokumenteres gjennom produsentdokumentasjon samt feil- og gjenopprettingstester.

Etter aksept må MTA-en bestemme hvor meldingen skal sendes videre. For Internett-e-post begynner denne avgjørelsen i DNS.

Ruting via DNS og MX

For direkte Internett-levering bestemmer den sendende MTA-en neste mål ut fra domenet til konvoluttmottakeren. Den spør DNS etter MX-poster, sorterer kandidater etter stigende preferanseverdi og løser de valgte Exchange-navnene til A- eller AAAA-adresser. Flere mål med samme preferanse er likeverdige kandidater; en backup-MX med høyere verdi er ikke en kopi av primærkøen, men en selvstendig SMTP-mottaker med egen policy og leveringsansvar (RFC 5321, avsnitt 5).

Hvis et MX-RRset mangler, behandler SMTP historisk domenet som en implisitt MX på selve domenenavnet og forsøker adressene dets. En eksplisitt Null MX med preferanse 0 og Exchange . erklærer derimot at et domene ikke mottar e-post (RFC 7505). NXDOMAIN, NODATA, SERVFAIL, DNSSEC-valideringsfeil og en tilgjengelig MX uten fungerende SMTP-tjeneste er ulike tilstander og må forbli separat synlige i køårsaken.

Interne e-postveier bruker ofte statiske neste hopp, smarthoster, connectorer eller rutingtabeller i stedet for offentlig MX-valg. Konvoluttmottakeren forblir likevel leveringsadressen; den lokale rutingpolicyen avgjør bare hvilket neste system den betros til. Ved hver diagnose må derfor tre navn noteres: mottakerdomenet, valgt neste-hop-navn og faktisk tilkoblet IP-adresse.

Selv når MTA-en kjenner målet, er levering ikke alltid mulig umiddelbart. Midlertidige feil fører derfor til køen i stedet for tap av meldingen.

Kø, gjenforsøk og DSN

En fullverdig MTA er et Store-and-Forward-system. Hvis den ikke straks kan nå neste hopp eller dette svarer midlertidig, beholder MTA-en melding og konvolutt i en persistent kø, planlegger et nytt forsøk og administrerer status per mottaker. RFC 5321 krever en gjenforsøksstrategi, men foreskriver ingen enkelt algoritme for alle produkter. Den anbefaler forsinkede gjentakelser, varsling ved langvarig forsinkelse og oppbevaring i flere dager før endelig oppgivelse (RFC 5321, avsnitt 4.5.4). Produktverdier som backoff, maksimal kølevetid, parallellitet og Destination Concurrency må derfor leses fra den konkrete MTA-konfigurasjonen.

En fornuftig køoppføring inneholder minst:

• uforanderlig meldingsinnhold eller en referert blob;
• konvoluttavsender og status for hver konvoluttmottaker;
• tidspunkt for aksept, neste forsøk og utløpsgrense;
• valgt transport, neste hopp, siste adresse og TLS-/policyavgjørelse;
• siste SMTP- og Enhanced-statuskode sammen med ekstern tekst;
• lokal kø-ID samt korrelerbare ID-er fra foranliggende eller etterfølgende hopp;
• tilstander for aktiv, deferred, hold, delivered, bounced og quarantined;
• replikerings-, filsystem- eller databasetilstand når aksept skal være høytilgjengelig.

Midlertidige feil forsøkes normalt på nytt. Permanente feil før egen aksept returneres synkront til den sendende SMTP-klienten. Permanente feil etter egen aksept fører til en Delivery Status Notification (DSN) til Reverse Path. RFC 3464 definerer for dette en maskinlesbar multipart/report-melding med felt per melding og per mottaker, som Reporting-MTA, Final-Recipient, Action, Status og valgfritt Remote-MTA eller Diagnostic-Code (RFC 3464).

En bounce er ikke automatisk pålitelig. DSN-er kan forfalskes, avsløre det opprinnelige innholdet eller generere backscatter ved misbrukt konvoluttavsender. En gateway bør avvise ugyldige meldinger så langt som mulig under den opprinnelige SMTP-økten, i stedet for å akseptere dem og senere returnere dem til en mulig forfalsket adresse.

Svarkoder og diagnostisk betydning

SMTP-svar har en tresifret basiskode. Det første sifferområdet beskriver den umiddelbare tilstanden; teksten er beregnet på mennesker og kan være produktspesifikk (RFC 5321, avsnitt 4.2).

Enhanced Status Codes supplerer formatet x.y.z. x angir suksess, midlertidig eller permanent; y angir det grove feilområdet og z detaljen. Dermed tilhører 5.1.1 adresseklassen og angir en ikke-eksisterende målpostboks, mens 4.4.x klassifiserer nettverks- og rutingproblemer. De registrerte betydningene finnes i IANA-registeret for Enhanced Status Codes; en produsenttekst må ikke vurderes i strid med den numeriske semantikken (RFC 3463, RFC 5248).

Den samme koden kan gjelde noe forskjellig avhengig av protokollfase. 550 på MAIL FROM avviser avsenderen eller dens autorisasjon, på RCPT TO en bestemt mottaker og etter innholdet hele transaksjonen. En sak uten ekstern vert, tid, fase, basiskoder, Enhanced Code og fullstendig svarttekst er derfor ufullstendig.

ESMTP og utvidelser

Extended SMTP bruker EHLO for å forhandle funksjoner per forbindelse. IANA fører det bindende registeret over SMTP Service Extensions. En klient kan bare bruke en utvidelse når den er tilbudt i den aktuelle økten; etter STARTTLS må den hente listen på nytt.

Capability Drift mellom klyngenoder er et vanlig driftsproblem. Hvis bare enkelte lyttere tilbyr SMTPUTF8, samme SIZE-verdi eller identiske AUTH-mekanismer, oppstår tilsynelatende tilfeldige leveringsfeil. Overvåking bør derfor ikke bare kontrollere én VIP, men hver relevant backendsti med samme SNI, EHLO-navn og kildenettverk.

Frem til nå har det handlet om transport mellom servere. Innsending fra brukere og applikasjoner er en egen tjeneste med andre porter, identiteter og misbruksrisikoer.

Innsending, relay og autentisering

Port 25 brukes til MTA-til-MTA-overføring. Port 587 angir Message Submission; port 465 er registrert for innsending over TLS som er aktivt fra starten av, som tjenesten submissions. Port 465 er ikke en alternativ MX-port: Offentlig MX-levering har ingen portangivelse og bruker port 25 (RFC 6409, avsnitt 1 og 3, RFC 8314, avsnitt 7.3, IANA Service Name and Port Number Registry).

En innsendingstjeneste kombinerer autentisering med autorisasjon. AUTH bruker SASL og kan bære mekanismer som PLAIN over TLS eller OAuth-baserte Bearer-tokener. Den autentiserte identiteten, den forespurte autorisasjonsidentiteten og den tillatte konvoluttavsenderen er ulike størrelser. En vellykket innlogging gir ikke automatisk rett til å bruke ethvert avsenderdomene eller enhver konvoluttavsender (RFC 4422, avsnitt 3.4, RFC 4954, RFC 7628).

Åpent relay oppstår når en MTA videresender meldinger fra uautoriserte kilder til ikke-lokale mål. En sikker konfigurasjon avgjør derfor separat for lokale mottakerdomener, pålitelige kildenettverk, autentisert innsending og eksplisitte connectorer. IP-tillatlister er nettverksautorisering, ikke en erstatning for brukeridentitet; ved NAT, Cloudflare-egress eller delte relayer kan den frigi en langt større avsenderkrets enn tiltenkt.

Først når rolle og port er avklart, kan riktig TLS-policy bestemmes: Innsending skal være beskyttet og autentisert, mens åpen MTA-transport trenger ytterligere domene-policyer.

TLS-policy for SMTP

STARTTLS beskytter den enkelte forbindelsen når begge parter utfører oppgraderingen. Ved åpen MTA-overføring forblir rent STARTTLS likevel opportunistisk: En aktiv angriper kan fjerne tilbudet eller manipulere DNS-mål, og en avsender uten ytterligere policy kan falle tilbake til klartekst. DANE for SMTP knytter TLSA-data via DNSSEC til valget av MX-mål. MTA-STS publiserer en PKIX-basert MX- og TLS-policy via DNS og HTTPS. TLS-RPT rapporterer aggregerte feil ved slike policyer. Kryptografiske detaljer, sertifikatkjeder og testmetoder behandles i artikkelen TLS.

Innsending er annerledes: Her er klient og tjeneste administrativt tilordnet, og brukeren skal ikke stille falle tilbake til klartekst. RFC 8314 anbefaler implisitt TLS for Mail Submission and Access og krever at klartekst behandles som foreldet. SMTP AUTH med passord- eller Bearer-mekanismer krever en tilstrekkelig beskyttet kanal; en server bør ikke engang tilby svake mekanismer før STARTTLS (RFC 8314, avsnitt 3, RFC 4954, avsnitt 14).

Lokal levering med LMTP

Local Mail Transfer Protocol (LMTP) bruker en SMTP-lignende dialog for overlevering til et system uten egen langsiktig e-postkø, for eksempel en postbokstjeneste. Den vesentlige forskjellen vises etter meldingsinnholdet: LMTP gir et eget endelig svar for hver tidligere aksepterte mottaker. Dermed kan e-postlageret levere vellykket til én mottaker og avvise en annen på grunn av kvote eller en lokal feil, uten at den foranliggende MTA-en må behandle hele transaksjonen enhetlig (RFC 2033, avsnitt 4.2).

LMTP flytter ikke ansvaret ut av systemet. Hvis e-postlageret midlertidig avviser en mottaker, må den foranliggende MTA-en fortsatt beholde denne mottakeren i køen. Med Unix-sockets faller riktignok IP-nettverksstien bort, men ikke behovet for å overvåke socket-tillatelser, backpressure, tidsavbrudd, per-recipient-svar og persistensgrensen.

Implementerings- og teknologistakk

SMTP definerer protokollen på ledningen, ikke den interne programvarearkitekturen. I praksis kombinerer en MTA flere tekniske lag:

Implementeringene realiserer disse lagene forskjellig. Postfix deler mottak, cleanup, Queue Manager og leveringsagenter i samarbeidende prosesser og skiller incoming, active og deferred som køtilstander. Exim lagrer konvolutt/headere og brødtekst i spoolen og lar queue-runnere behandle forfalte leveringsforsøk. Apache James kjører på JVM og kombinerer protokollserver, kø og en Mailet-pipeline med utskiftbare lagringsbackender. Alle tre snakker SMTP, men prosess-, kø-, utvidelses- og gjenopprettingsmodellene deres er ikke utskiftbare.

Programmeringsspråk og runtime påvirker pakking, patchprosess, minneprofil og utvidbarhet, ikke semantikken i SMTP-dialogen. Postfix bygges med en nativ C-toolchain for Unix-lignende systemer (Postfix INSTALL); Exim-dokumentasjonen angir ANSI C som implementeringsspråk. Apache James beskriver seg derimot som en Java-/Scala-plattform på JVM (Apache James). En skytjeneste kan avbilde de samme RFC-rollene gjennom proprietære mikrotjenester, distribuerte køer og API-er. For driftsgodkjenning må derfor ikke bare EHLO-funksjoner, men også persistensløfte, gjenforsøksmodell, køeksport, sikkerhetskopi, nøkkelhåndtering, skaleringsgrenser og feilområder dokumenteres.

Fra leveringsforløpet følger en fast feilsøking: Bestem mål, kontroller forbindelse og SMTP-dialog, vurder svaret og følg deretter køen samt neste hopp.

Diagnostikk fra DNS til køen

Pålitelig SMTP-diagnostikk følger leveringsstien og holder observasjonsnivåene atskilt. Tester bør utføres med testdomener og autoriserte mottakere; fremmede servere må ikke misbrukes til relay-, adressevaliderings- eller lasttester.

Bestem MX-mål og adresser

Resolve-DnsName og dig viser publiserte DNS-data. Utdataene må kontrolleres for preferanse, Null MX, CNAME-kjeder, IPv4/IPv6 og resolveren det faktisk ble spurt mot. Et DNS-svar beviser verken lytter- eller TLS-funksjon.

Kontroller TCP-tilgjengeligheten til valgt hopp

Test-NetConnection og nc kontrollerer her bare DNS-oppløsning og TCP-etablering. En suksess på 25 sier ikke om SMTP-hilsenen kommer i tide; en suksess på 587 eller 465 sier ingenting om TLS- og AUTH-policy.

Kontroller STARTTLS, EHLO og sertifikat

openssl s_client utfører den nødvendige klartekstdialogen med -starttls smtp, angir SMTP-EHLO-navnet med -name og SNI med -servername. -verify_hostname og -verify_return_error gjør den rene handshaken om til en eksplisitt PKIX-navnetest. Resultatet beskriver OpenSSL med sin truststore, ikke automatisk policyen til den produktive MTA-en.

Test konvolutt og svarfase kontrollert

swaks logger SMTP-kommandoer og svar og kan bevisst avslutte testen etter RCPT uten å sende meldingsdata. Verktøyet er ikke en systemkomponent i Windows; swaks.exe eller en Perl-installasjon må komme fra en kontrollert kilde. En RCPT-test må bare utføres mot egne eller uttrykkelig godkjente systemer og adresser, fordi den utløser policy, katalogoppslag og rate limits.

Undersøk lyttere og pakker på serveren

Get-NetTCPConnection og ss tilordner lyttere og TCP-tilstander til lokale prosesser. pktmon og tcpdump fanger pakker; produksjonsopptak kan inneholde konvoluttadresser, ukryptert innhold og autentiseringsdata og må beskyttes, begrenses og slettes tilsvarende. Wireshark egner seg for analyse av TCP, SMTP og TLS-handshaker, men erstatter verken kø- eller policylogger.

Tilordne feil til en grense

Observerbarhet og driftsmodell

En SMTP-monitor bør ikke bare sende en test-e-post. Den må synliggjøre systemets enkelte tilstander:

• Greeting-, EHLO-, STARTTLS-, AUTH- og End-of-Data-latens separat;
• forbindelser, økter, aktive transaksjoner og avvisninger per fase;
• tilbudte ESMTP-funksjoner per lytter og backend;
• akseptrate, mottakerantall, meldingsstørrelse og durable-write-latens;
• køomfang etter alder, mål, transport, status og siste feil;
• gjenforsøksrate, eldste melding, utløpende leveringer og DSN-opprettelse;
• DNS-mål, tilkoblet IP, IPv4/IPv6, TLS-modus, cipher og policyresultat;
• svarkoder som strukturerte felt i stedet for utelukkende som fritekst;
• korrelasjon av Edge-ID, intern kø-ID, ekstern kø-ID, Message-ID og mottaker;
• LMTP-/postboksstatus per mottaker samt karantene- og frigivelsesstier;
• spoolkapasitet, I/O-latens, database- eller brokerstatus og replikeringsetterslep;
• beskyttelsesgrenser for logger og opptak, fordi konvolutt, headere og innhold inneholder personopplysninger eller konfidensielle data.

Køsikkerhetskopier alene er ikke nok. Gjenoppretting må ta hensyn til konfigurasjon, rutingtabeller, sertifikater og nøkler, kømetadata, meldingsblober, karantene, signaturtilstand og idempotens. Etter en restore må en allerede levert mottakerkopi ikke ukontrollert sendes på nytt; samtidig må fortsatt åpne mottakere av en delvis levert melding ikke gå tapt. RPO og RTO må derfor defineres per tilstandskomponent og testes med en faktisk kø med flere mottakere.

Teknisk historie

SMTP oppstod fra tidligere ARPANET-e-postprosedyrer. Jon Postels RFC 821 standardiserte i 1982 modellen som fortsatt er gjenkjennelig, med Sender-SMTP, Receiver-SMTP, MAIL, RCPT, DATA og tresifrede svar. Meldingsformatet ble samme år beskrevet separat i RFC 822. Dette skillet mellom overføringsprotokoll og meldingsformat ble bevart.

Med MIME vokste SMTP utover ren 7-biters tekst. ESMTP-rammeverket introduserte EHLO, registrerte funksjoner og parametere på MAIL henholdsvis RCPT; versjonen fra 1995 stod i RFC 1869. Utvidelser bygget på dette, som SIZE, 8BITMIME, PIPELINING, AUTH, STARTTLS, CHUNKING, DSN og senere SMTPUTF8, utviklet protokollen gradvis uten å opprette en parallell «SMTP 2»-stakk.

RFC 2821 konsoliderte SMTP i 2001 og erstattet RFC 821 samt flere supplerende dokumenter. RFC 5321 fulgte i 2008 som en ytterligere konsolidering; det tilhørende Internet Message Format finnes i RFC 5322. Message Submission ble først spesifisert separat og konsolidert i RFC 6409. Den tekniske utviklingen skjedde dermed gjennom tydeligere roller, utvidelsesregistre, internasjonaliserte adresser, leveringsrapporter og transport-policy, mens den grunnleggende tilstandsbaserte dialogen forble kompatibel.

Også programvarearkitekturene utviklet seg i ulike retninger. Historisk Sendmail-kompatibilitet preget lokale kommandolinjegrensesnitt; Postfix satset på samarbeidende prosesser med separerte privilegier og eksplisitte køer, Exim på en sterkt konfigurerbar router-/transport- og spooltilnærming, og JVM-systemer som Apache James gjorde behandlingen utvidbar gjennom komponenter og Mailets. Skyplattformer fordeler de samme logiske rollene på frontender, brokere, policytjenester og regionale køer. For administratorer forblir derfor RFC-semantikken fellesnevneren, mens persistens, skalering og gjenoppretting alltid må dokumenteres produktspesifikt.

Kilder

• RFC 5321 – Simple Mail Transfer Protocol – SMTP-modell, ruting, kommandoer, svar, kø, gjenforsøk, sporing og leveringsansvar.
• RFC 5598, avsnitt 4
• RFC 6409 – Message Submission for Mail – skille mellom innsending og relay, roller, port 587 og MSA-policy.
• RFC 5322 – Internet Message Format – headere, brødtekst, adressefelt, Message-ID og sporingsfelt.
• RFC 3207 – SMTP Service Extension for Secure SMTP over TLS – STARTTLS og tilbakestilling av SMTP-tilstanden.
• RFC 2920 – SMTP Command Pipelining – ordnede kommandogrupper uten round trip per kommando.
• RFC 7505 – A Null MX No Service Resource Record – uttrykkelig markering av domener som ikke kan motta e-post.
• RFC 3464 – Delivery Status Notification Format – maskinlesbar DSN-struktur og mottakerstatus.
• IANA – SMTP Enhanced Status Codes – registrerte betydninger av detaljkodene.
• RFC 3463 – Enhanced Mail System Status Codes – struktur og klasser for utvidede statuskoder.
• RFC 5248 – SMTP Enhanced Status Code Registry – registreringsmodell for Enhanced Codes.
• IANA – Simple Mail Transfer Protocol Parameters – SMTP-kommandoer, utvidelser og EHLO-nøkkelord.
• RFC 1870 – SMTP SIZE Extension – størrelsesforhandling og avvisning før innholdet.
• RFC 6152 – SMTP Service Extension for 8-bit MIME Transport – 8BITMIME og BODY-parametere.
• RFC 3030 – CHUNKING and BINARYMIME – BDAT-overføring og binære MIME-meldinger.
• RFC 6531 – SMTP Extension for Internationalized Email – SMTPUTF8 og internasjonale postbokser.
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications – konvoluttparametere for DSN-forespørsler.
• RFC 4954 – SMTP Service Extension for Authentication – AUTH-kommando og SASL-profil for SMTP.
• RFC 8314, avsnitt 7.3
• IANA – Service Name and Transport Protocol Port Number Registry – tilordning av SMTP, Submission og Submissions til porter.
• RFC 4422, avsnitt 3.4
• RFC 7628 – SASL Mechanisms for OAuth – OAuth-baserte SASL-mekanismer for SMTP og andre protokoller.
• RFC 7672 – SMTP Security via DANE TLS – DNSSEC- og TLSA-bundet SMTP-transportpolicy.
• RFC 8461 – SMTP MTA Strict Transport Security – PKIX-basert MX- og TLS-policy.
• RFC 8460 – SMTP TLS Reporting – aggregerte rapporter om transport-TLS-feil.
• RFC 2033, avsnitt 4.2
• Postfix – Architecture Overview – prosessroller, Queue Manager og leveringsagenter.
• Exim – How Exim receives and delivers mail – spool-, ruting-, transport- og queue-runner-modell.
• Postfix – Installation From Source Code – native build-, plattform- og toolchain-krav.
• Exim – teknisk oversikt – ANSI C som implementeringsspråk og tekniske produktegenskaper.
• Apache James Project – JVM-, Java-/Scala- og komponentarkitektur.
• Microsoft Learn – Resolve-DnsName – DNS-oppslag i Windows.
• BIND 9 – dig manual – DNS-oppslag i Unix-systemer.
• Microsoft Learn – Test-NetConnection – TCP-tilgjengelighet i Windows.
• OpenBSD – nc(1) – TCP-forbindelser med Netcat.
• OpenSSL – s_client – STARTTLS-, SNI- og sertifikatdiagnostikk.
• Swaks – Swiss Army Knife for SMTP – SMTP-transaksjons- og utvidelsestest.
• Microsoft Learn – Get-NetTCPConnection – lokale TCP-lyttere og forbindelser.
• Linux man-pages – ss(8) – socket- og TCP-tilstandsdiagnostikk.
• Microsoft Learn – Packet Monitor – Windows-pakkefangst og PCAPNG-konvertering.
• tcpdump(1) manual – pakkebasert diagnostikk på Unix-systemer.
• Wireshark User’s Guide – interaktiv analyse av nettverks- og protokollspor.
• RFC 821 – Simple Mail Transfer Protocol – historisk SMTP-spesifikasjon fra 1982.
• RFC 1869 – SMTP Service Extensions – historisk ESMTP-rammeverk og EHLO-modell.
• RFC 2821 – Simple Mail Transfer Protocol – SMTP-konsolidering fra 2001.
• RFC 3848 – ESMTP and LMTP Transmission Types – with-verdier som ESMTPSA i Received-headere.