Simple Mail Transfer Protocol ( SMTP ) er en standardprotokoll for e-postoverføring. Opprinnelig foreslått i RFC 788 [1] i 1981, deretter oppdatert med RFC 821 [2] i 1982 og ytterligere endret i 2008 med innføringen av utvidet SMTP ( RFC 1869 og RFC 5321 ), som er protokollen som for tiden er i bruk.
Selv om e-postservere bruker SMTP til å sende og motta e-post, bruker e-postklienter på brukernivå kun SMTP for å sende meldingen til e-postserveren, som sørger for å sende meldingen. For å hente meldinger bruker klientapplikasjoner vanligvis protokoller som IMAP eller POP3 .
Kommunikasjon mellom e-postservere bruker TCP -protokollen på port 25 [2] . E-postklienter sender imidlertid ofte utgående e-post til serveren på port 465 [ 3] eller 587 [4] .
Du kan sikre en SMTP-forbindelse med TLS , kjent som SMTPS , gjennom STARTTLS .
Selv om proprietære systemer (som Microsoft Exchange og IBM Notes ) og webpostsystemer (som Outlook.com , Gmail og Yahoo! Mail ) bruker ikke-standardiserte protokoller for å få tilgang til postkassen til den respektive e-postserverkontoen, bruker de alle SMTP, for '' sende og motta e-post, utenfor deres systemer.
Det er en relativt enkel tekstprotokoll , der en eller flere mottakere av en melding er spesifisert og, etter å ha bekreftet at de eksisterer, overføres meldingen. Det er ganske enkelt å sjekke hvordan en SMTP-server fungerer ved å bruke en telnet -klient [5] . SMTP-protokollen bruker TCP som transportlagsprotokoll . Klienten åpner en TCP -sesjon til serveren på port 25 (mange leverandører bruker TCP-port 587 i stedet som kreves av RFC 2476 fra desember 1998 for å begrense spam ). En MX (Mail eXchange) Resource Record brukes til å knytte SMTP-serveren til et gitt domenenavn ( DNS ) .
Siden SMTP er en tekstprotokoll basert på ASCII [2] -kodingen (spesielt ASCII NVT 7-bit), er det ikke tillatt å sende tekst direkte sammensatt med et annet tegnsett (derfor ikke engang binære filer ). MIME -standarden gjør det mulig å utvide meldingsformatet og samtidig opprettholde kompatibilitet med eksisterende programvare . For eksempel støtter mange SMTP-servere i dag utvidelsen 8BITMIME , som tillater overføring av tekst som inneholder aksenttegn (ikke-ASCII) uten behov for omkoding. Andre SMTP-grenser, for eksempel maksimal lengde på en linje, forhindrer at binære filer sendes uten omkoding . (Merk at binære filer sendt med HTTP bruker MIME -formatet uten behov for omkoding.)
SMTP er en protokoll som bare lar deg sende e-postmeldinger, men ikke be om dem fra en server: for å gjøre dette må e-postklienten bruke andre protokoller, for eksempel POP3 (Post Office Protocol) og IMAP (Internet Message Access Protocol) .
På 1960-tallet var flere en-til-en-løsninger for utveksling av meldinger allerede i bruk. Folk kommuniserte med hverandre ved hjelp av systemer utviklet for en bestemt stormaskin . Etter hvert som tilkoblede datamaskiner vokste, spesielt i ARPANET , ble forskjellige standarder utviklet for å tillate utveksling av e-post mellom brukere av forskjellige systemer. SMTP vokste ut av disse standardene i løpet av 1970-tallet.
Røttene til SMTP kan finnes i to implementeringer beskrevet i 1971: Mail Box-protokollen, hvis implementering ble diskutert [6] , men er dekket i ulike RFC-er inkludert RFC 196 [7] , og implementert i SNDMSG-programmet som iht. RFC 2235 , den ble oppfunnet av Ray Tomlinson fra BBN for å brukes på TENEX -datamaskiner for å sende meldinger over ARPANET.
Ytterligere implementeringer inkluderer FTP Mail [8] og Mail Protocol, begge fra 1973 [9] . Utviklingsarbeidet fortsatte utover 1970-tallet, til rundt 1980 ble ARPANET-nettverket omgjort til det moderne internettnettverket. Jon Postel foreslo en Mail Transfer Protocol i 1980 som begynte å fjerne postens avhengighet av FTP [10] . SMTP ble publisert som RFC 788 i november 1981 [11] .
På begynnelsen av 1980-tallet ble SMTP mye brukt. På den tiden var det en utvidelse av UUCP (forkortelse for Unix-to-Unix Copy Program, er en pakke med programmer og protokoller som tillater ekstern kjøring av kommandoer og overføring av filer og e-poster mellom datamaskiner), som var mer egnet for å administrere overføring av e-poster mellom datamaskiner koblet til periodisk. SMTP fungerer imidlertid best med avsender og mottaker alltid koblet til nettverket. Begge bruker en lagrings- og forovermekanisme og er eksempler på push-logikk .
Sendmail , utgitt med 4.1cBSD , kort tid etter RFC 788 , var en av de første postoverføringsagentene som implementerte SMTP [12] . Takket være at BSD Unix ble det mest populære operativsystemet på internett, ble sendmail den mest brukte e-postoverføringsagenten (e-postserveren). Andre SMTP-servere er Postfix , qmail , Novell GroupWise , Exim, Novell NetMail , Microsoft Exchange Server og Oracle Communications Messagging Server .
Evnen til å sende meldinger (RFC 2476 [13] ) og SMTP-AUTH (RFC 2554 [14] ) ble utviklet i 1998 og 1999, og introduserte en ny trend innen e-postlevering. Opprinnelig var SMTP-servere vanligvis innenfor en organisasjon, og mottok e-post for organisasjonen fra utsiden og leverte meldinger fra organisasjonen til utsiden. På grunn av den raske utvidelsen av Word Wide Web , har SMTP-servere måttet sette inn spesifikke regler og metoder for levering av e-post og autentisering av brukere for å forhindre misbruk som levering av uønsket e-post ( spam ). Arbeidet med å sende meldinger (RFC 2476 [15] ) ble utviklet fordi de mest kjente e-postserverne ofte overskrev e-posten for å fikse problemer som finnes i den, som for eksempel å legge til domenenavnet til en uspesifisert adresse. Denne oppførselen er ønsket når meldingen korrigeres mens den er i en innledende, men farlig og ondsinnet tilstand da meldingen ble generert et annet sted og er i ferd med å bli sendt. Å skille post mellom levering og overføring blir sett på som en måte å tillate og oppmuntre til omskriving og blokkere omskriving. Dette skillet mellom levering og overføring ble raskt grunnlaget for postsikkerhet.
Etter å ha startet som en ren tekstbasert 7-bits ASCII -protokoll , håndterte ikke SMTP binære filer og tegn som ikke ble brukt på engelsk. Standarder som Multipurpose Internet Mail Extension ( MIME ) ble utviklet for å kode binære filer for overføring via SMTP. E- postoverføringsagenter (MTA) utviklet etter at Sendmail hadde en tendens til å bli implementert som 8-bits-clean, slik at enhver tekstfil som inneholder data (i hvilken som helst 8-bits ASCII-lignende koding) kunne overføres over SMTP. I dag har 8-bits-rene MTA-er en tendens til å støtte utvidelsen 8BITMIME , noe som muliggjør enkel overføring av binære filer, slik tilfellet er med tekstfiler. Nylig har SMTPUTF8- utvidelsen blitt utviklet for å tillate støtte for UTF-8- kodet tekst , og garanterer utveksling av meldinger på språk som kyrillisk og kinesisk .
Mange mennesker bidro til utviklingen av SMTP-spesifikasjonen, inkludert Jon Postel , Eric Allman, Dave Crocker, Ned Freed, Randall Gellens , John Klensin og Keith Moore .
En e-post sendes fra en e-postklient ( e-postbrukeragent , MUA) til en e-postserver ( mailsubmisson-agent , MSA), ved bruk av SMTP over TCP på port 587. De fleste e-postleverandører tillater imidlertid fortsatt sending på den tradisjonelle porten 25. MSA-en leverer posten til postoverføringsagenten (MTA). Ofte er MSA og MTA forekomster av samme programvare, startet med forskjellige alternativer på samme maskin. I tillegg til en klassisk klient, kan en utgående e-postkonto med SMTP-protokoll konfigureres i et hvilket som helst program som kan sende e-post.
MTA bruker DNS for å finne MX-posten til et spesifikt domene (delen av adressen etter @-tegnet). MX-posten inneholder navnet på målverten. Basert på vertsnavnet og annen informasjon, velger MTA en server og kobler til som en SMTP-klient.
Meldingsoverføring kan skje i en enkelt forbindelse mellom to MTAer eller gjennom en serie hopp over flere mellomliggende systemer. En SMTP-server kan være mottaker av meldingen eller mellomledd (utfører lagring og videresending) eller gateway (den kan overføre meldingen ved hjelp av andre protokoller så vel som SMTP). Hvert hopp er en formell overføring av ansvar over meldingen, så hver server som mottar meldingen må levere den eller rapportere en feil.
Når mottakerserveren godtar den innkommende meldingen, leverer den den til en postleveringsagent (MDA), som lagrer den i en postboks for lokal levering.
Når den er levert til e-postserveren, lagres meldingen for henting av en spesifikk autentisert e-postklient (MUA). E-posten hentes gjennom applikasjoner på brukerens enhet, kalt e-postklienter, ved hjelp av Internet Message Access Protocol (IMAP), som forenkler både tilgang til e-postene og administrerer de lagrede e-postene, eller Post Office Protocol (POP). ) som vanligvis bruker det tradisjonelle mbox-formatet for e-post, eller et proprietært system som Microsoft Exchange / Outlook eller Lotus Notes / Domino. Webmail - klienter kan bruke begge veier, men gjenfinningsprotokollen er vanligvis ikke en standardprotokoll. POP3 og IMAP er lignende protokoller, men med noen betydelige forskjeller:
SMTP definerer hvordan meldingen overføres, ikke innholdet. Den definerer strukturen og dens parametere, for eksempel konvoluttsenderen , men ikke overskriften (bortsett fra sporingsinformasjonen) eller selve meldingen. STD 10 og RFC 5321 [16] definerer strukturen til SMTP mens STD 11 og RFC 5322 [17] definerer meldingen (header og body) gjennom et Internett-meldingsformat.
SMTP er en tilkoblingsorientert , tekstbasert protokoll , der en e-postsender kommuniserer med en e-postmottaker ved å sende kommandostrenger og gi nødvendig informasjon gjennom en pålitelig kommunikasjonskanal, typisk basert på TCP . En SMTP-sesjon består av utveksling av kommandoer generert av en SMTP-klient og de tilsvarende svarene fra SMTP-serveren. En økt kan inneholde null eller flere SMTP-transaksjoner. En SMTP-transaksjon består av tre sekvenser med kommandoer og svar:
I tillegg til de mellomliggende svarene på kommandoen DATA, kan hver serverrespons være positiv (preget av koden 2xx) eller negativ. Negative svar kan være permanente (5xx) eller midlertidige (4xx). Et avvisning representerer en permanent feil, og klienten skal sende en returmelding til serveren den mottok meldingen fra. Et fall er et positivt svar, etterfulgt av avvisningsmeldingen, i stedet for leveringsmeldingen.
Den opprinnelige verten, SMTP-klienten, kan enten være en brukers e- postklient , referert til som en e-postbrukeragent (MUA) eller stole på en e-postoverføringsagent (MTA), som faktisk er en SMTP-server som oppfører seg som en SMTP-klient for gjeldende økt. Mer avanserte SMTP-servere opprettholder en meldingskø for å sende meldinger som har mislyktes (midlertidig) levering på nytt.
En reléserver bestemmer vanligvis hvilken server den skal koble til gjennom hvert domenes DNS MX-post (Mail eXchange). Hvis det ikke finnes noen MX-post, sjekker noen servere A-posten. Hovedforskjellen mellom MTA og MSA er at tilkobling til en MSA krever SMTP-autentisering . Divisjonen mellom MTA og MSA har flere fordeler:
For mer informasjon om forskjellene, se wikipedia-siden om meldingsagenter (på engelsk).
SMTP er kun en leveringsprotokoll. Ved den vanligste bruken sendes meldingen til målpostserveren, eller til serveren i neste trinn. Meldingen rutes basert på destinasjonsserveren, ikke basert på brukeren den skal sendes til. Andre protokoller som Post Office Protocol (POP) og Internet Message Access Protocol (IMAP) er spesielt utviklet for å brukes av brukeren, hente meldinger og administrere postkassen. For å tillate en periodisk tilkoblet e-postserver å hente meldinger fra en ekstern server, har SMTP en funksjon for å starte en meldingsbehandlingskø på en ekstern server (se nedenfor).
Remote Message Queue Initialization er en SMTP-funksjon som lar en ekstern vert starte behandling av e-postkøen på en server, som kan motta meldinger beregnet på den ved å sende inn kommando TURN. Imidlertid ble denne funksjonen ansett som usikker [19] og ble erstattet (RFC 1985 [19] ) av kommandoen ETRNsom fungerer sikrere ved å bruke en autentiseringsmetode basert på Domain Name System Information.
Brukere for hvem skriftspråket ikke er basert på det latinske alfabetet eller som bruker symboler som ikke finnes i ASCII- tegnsettet , kan ha problemer forårsaket av at e-postadressen kun krever latinske tegn. RFC 6531 [20] ble opprettet for å løse dette problemet ved å introdusere SMTPUTF8-utvidelsen og støtte for multi-byte-koding for ikke-ASCII-tegn for e-postadresser, for å støtte språk som gresk og kinesisk.
En e-postklient må kjenne IP-adressen til start-SMTP-serveren, som må oppgis som en del av konfigurasjonen (vanligvis som DNS -navn , MX-felt).
Serveradministratorer må håndheve en form for kontroll over hvilke klienter som kan bruke serveren, for å tillate håndtering av for eksempel spam. Det er vanligvis to løsninger som brukes:
Under disse systemene tillater ikke en ISP tilgang til SMTP-serveren av brukere utenfor nettverket som administreres av ISPen selv. Mer presist kunne serveren bare tillate tilgang for brukere med en IP-adresse levert av Internett- leverandøren , noe som tilsvarer å kreve at både avsender og mottaker er koblet til internett med samme Internett- leverandør . En mobilbruker kan imidlertid ofte være på et nettverk som ikke er det til hans vanlige ISP og kan derfor ikke være i stand til å sende e-post fordi konfigurasjonen av den valgte SMTP-serveren ikke lenger er tilgjengelig.
En organisasjons SMTP-server kunne derfor bare tilby tjenester til brukere på samme nettverk, og blokkere tilgangen til det eksterne nettverket. Alternativt kan serveren utføre en rekkeviddesjekk på klientens IP-adresse. Disse metodene ble vanligvis brukt av enheter og institusjoner som universiteter som tilbyr en SMTP-server kun for intern organisasjonsbruk. Imidlertid bruker mange av disse organisasjonene nå en autentiseringsmetode.
Når en bruker er mobil og kan koble seg til internett gjennom forskjellige Internett-leverandører, er denne typen bruksbegrensninger tyngende og å endre adressen til utgangsserveren er upraktisk. Det er ønskelig å kunne bruke e-postklientkonfigurasjoner som ikke må endres.
KlientautentiseringModerne SMTP-servere krever vanligvis at klienter autentiserer med legitimasjon før de tillater tilgang, i stedet for å blokkere tilgang direkte basert på plassering, som beskrevet ovenfor. Dette mer fleksible systemet lar mobile brukere ha en fast utgående SMTP-server. SMTP-autentisering, ofte forkortet til SMTP AUTH , er en utvidelse av SMTP for å tillate tilgang gjennom autentiseringsmekanismer.
Åpne reléEn server som er tilgjengelig over hele internett og ikke tar i bruk denne typen tilgangsbegrensninger kalles et åpent relé . Å ta i bruk et slikt system anses som dårlig praksis [21] .
DørerKommunikasjon mellom e-postservere foregår vanligvis via TCP på port 25, selv om e-postklienter vanligvis bruker en annen port. E-posttjenester aksepterer vanligvis e-post som skal sendes på porter:
Port 2525 og andre kan brukes av enkelte leverandører, men støttes ikke offisielt.
Mange Internett-tjenesteleverandører blokkerer nå all e-post sendt fra port 25, som et anti spam-tiltak [24] og tillater kun sending fra den angitte e-postserveren. Tilbyder kan dermed kontrollere utgående trafikk.
HELO: Sendt av en klient for egenidentifikasjon, vanligvis med et domenenavn.
EHLO: Lar serveren identifisere støtte for ESMTP -kommandoer (Extended Simple Mail Transfer Protocol ).
MAIL FROM: Identifiserer avsenderen av meldingen. Brukes i skjemaet MAIL FROM:.
RCPT TO: Identifiserer mottakerne av meldingen. Brukes i skjemaet RCPT TO:.
TURN: Lar klienten og serveren bytte roller og sende e-post i motsatt retning uten å måtte opprette en ny tilkobling.
ATRN: Kommandoen ATRN(Autentisert ) TURNbruker, etter eget skjønn, ett eller flere domener som en parameter. Kommandoen ATRNmå avvises hvis økten ikke er autentisert.
SIZE: Gir en mekanisme som SMTP-serveren kan bruke til å indikere den maksimale støttede meldingsstørrelsen. Kompatible servere må gi størrelsesutvidelser for å indikere maksimal tillatt meldingsstørrelse. Klienter bør ikke sende meldinger som er større enn størrelsen angitt av serveren.
ETRN: En utvidelse av SMTP. ETRNden sendes av en SMTP-server for å be om at en annen server sender e-postmeldinger den har.
PIPELINING: Lar deg sende en strøm av kommandoer uten å vente på svar etter hver kommando.
CHUNKING: Dette er en ESMTP - kommando som erstatter kommandoen DATA. Denne kommandoen sender en kommando BDATmed et argument som inneholder det totale antallet byte i meldingen, slik at SMTP-verten ikke trenger å skanne kontinuerlig for å finne slutten av dataene. Den mottakende serveren teller bytene i meldingen, og når meldingsstørrelsen samsvarer med verdien sendt av kommandoen BDAT, antar serveren at den har mottatt alle meldingsdataene.
DATA: Sendt av en klient for å starte overføring av meldingsinnhold.
DSN: Dette er en ESMTP-kommando som utløser varsler om leveringsstatus.
RSET: Avbryt hele meldingstransaksjonen og tilbakestill bufferen.
VRFY: Kontroller at en postboks er tilgjengelig for meldingslevering. Kontroller for eksempel VRFY tedat Teds postkasse ligger på den lokale serveren.
HELP: Returnerer listen over kommandoer som støttes av SMTP-tjenesten.
QUIT: Avslutt økten.
Nedenfor er en SMTP-transaksjon mellom to postkasser ( Alice og Bob ) som er på samme domene ( eksempel.com ). Linjene som sendes av klienten er innledet med "C:", mens de som sendes av serveren av "S:" (men disse bokstavene er ikke en del av meldingsutvekslingen, men tjener bare som et eksempel).
S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.com S: 250 smtp.example.com C: MAIL FRA: <[email protected]> S: 250 OK C: RCPT TIL: <[email protected]> S: 250 OK C: DATO S: 354 Sluttdata med <CR> <LF>. <CR> <LF> C: Fra: "Bob" <[email protected]> C: Til: "Alice" <[email protected]> C: Dato: Tirs 15. januar 2008 16:02:43 -0500 C: Emne: Testmelding C: C: Hei, dette er en testmelding C:. S: 250 Ok: i kø som 12345 C: AVSLUTT S: 221 Ha detKlienten varsler mottakeren av e-posten gjennom kommandoen RCPT TO. I tilfelle meldingen ikke kan leveres, returneres en returadresse. I dette tilfellet sendes meldingen til en postboks på samme server (hvis det også var en kopi, ville meldingen også blitt sendt til postkassen hans). Den tilsvarende SMTP-kommandoen er RCPT TO. Hver vellykket utført kommando fører til generering av en bekreftelse av serveren med kode 250.
Begynnelsen av overføringen av e-postteksten identifiseres av kommandoen DATA, hvoretter teksten overføres linje for linje og avsluttes med sekvensen som <CR><LF>.<CR><LF>kalles end-of-data- sekvens . Siden en linje kun kan inneholde et punktum (.) Som en del av teksten sender klienten to påfølgende punkter hver gang en linje begynner med en punktum. På samme måte erstatter serveren hver sekvens av påfølgende kolon med bare ett (denne teknikken kalles dot-stuffing ).
Serverens positive respons på end-of-data betyr at serveren har overtatt leveringen av meldingen. En melding kan dupliseres hvis det på dette stadiet oppstår et kommunikasjonsproblem, for eksempel forårsaket av strømbrudd. Inntil avsenderen mottar den kodede meldingen 250, antas det at meldingen ikke er levert. På samme måte, etter at mottakeren har bestemt seg for å godta meldingen, antar avsenderen at meldingen er levert. Men i løpet av denne tidsrammen (tiden mellom når meldingen ble sendt til klienten mottar svaret karakterisert ved kode 250), har begge agentene aktive kopier av meldinger som de prøver å levere [25] og dette kan forårsake duplikatmeldingsproblemer. For å begrense dette fenomenet angis vanligvis en timeout-tid på mellom 5 og 10 minutter [26] .
Kommandoen QUITavslutter økten. Hvis e-posten har andre mottakere, vil klienten koble seg til en passende SMTP-server for påfølgende mottakere. Informasjonen som klienten sender med kommandoene HELOog MAIL FROMsettes inn (ikke vist i eksempelkoden) i e-posten som ekstra overskriftsfelt , ved at mottakerserveren legger til henholdsvis Mottatt- og Returbane- feltene .
Noen klienter er implementert for å lukke forbindelsen etter at meldingen er akseptert (i eksemplet 250 OK: i kø som 12345 ), så de to siste linjene kan utelates. Denne løsningen kan imidlertid føre til at serveren mislykkes når svaret sendes 221.
Klienten kan finne ut hvilke alternativer en server støtter gjennom meldingen EHLO, som vist nedenfor, i stedet for å sende den tradisjonelle HELO. Klienten går tilbake til en melding HELObare hvis serveren ikke støtter SMTP-utvidelser. [27]
Moderne klienter kan bruke nøkkelordet SIZE, introdusert av ESMTP -utvidelsen , for å spørre serveren om maksimal meldingsstørrelse som er akseptert. Tidligere var det en risiko for at klienter og servere forsøkte å overføre meldinger som var for store, som ville bli blokkert etter bruk av nettverksressurser inkludert tilkoblingstid [28] .
Brukere kan manuelt bestemme, på forhånd, maksimal størrelse akseptert av ESMTP-serveren, og erstatte kommandoen HELOmed EHLO, som nedenfor
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.com S: 250-smtp2.example.com Hei bob.example.org [192.0.2.201] S: 250-STØRRELSE 14680064 S: 250-PIPELINING S: 250,- HJELPSvaret viser at smtp2.example.com erklærer å akseptere en maksimal melding med en fast størrelse som ikke er større enn 14 680 064 oktetter (8-bit, byte). Den maksimale meldingsstørrelsen kan imidlertid variere avhengig av gjeldende bruk av serverressurser (det kan hende den ikke kan motta en så stor melding).
I det enkleste tilfellet erklærer en ESMTP- server en maksimal størrelse umiddelbart etter mottak av kommandoen , selv om parameteren i svaret er valgfri EHLOifølge RFC 1870 [29] . I stedet kan klienten, når den sender en kommando , inkludere den estimerte størrelsen på meldingen den er i ferd med å sende, slik at serveren kan nekte å motta meldinger som er for store. SIZEEHLOMAIL FROM
En av begrensningene til den opprinnelige SMTP-protokollen er at den ikke håndterer autentisering av sendere. I tillegg til risikoen for spam , er det mulighet for å sende e-post ved å få adressen til en annen konto til å vises som avsender. Uten å få tilgang til tredjepartskontoen, er det mulig å opprette en forbindelse til e-postserveren og skrive en melding i SMTP-kode som inneholder kommandoene knyttet til avsender og mottaker, for å gi de relative parameterne og e-postteksten.
For å overvinne disse problemene har en utvidelse kalt SMTP-AUTH blitt utviklet .
Til tross for dette er spam fortsatt et stort e-postproblem den dag i dag. En radikal revisjon av SMTP-protokollen anses imidlertid ikke som mulig, på grunn av det store antallet implementeringer av gjeldende protokoll (for eksempel har Internet Mail 2000 blitt foreslått som en alternativ protokoll).
Av denne grunn har flere hjelpeprotokoller blitt foreslått for å hjelpe SMTP-transaksjoner. IETF Anti-Spam Research Group jobber med ulike forslag til e-postautentisering sentrert om fleksibilitet, letthet og skalerbarhet .
Publisert i 2008, RFC 5321 - "The Simple Mail Transfer Protocol" er hovedspesifikasjonsdokumentet for SMTP-protokollen og gjør RFC 821 (også kjent som STD 10), RFC 974 , RFC 1869 og RFC 2821 foreldet . I tillegg utvider følgende RFC-er funksjonaliteten til SMTP-protokollen: (på originalspråk)
(oversatt til italiensk)