Protocol de transfer simplu prin poștă

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Simple Mail Transfer Protocol ( SMTP ) este un protocol standard pentru transmiterea e-mailului. Propus inițial în RFC 788 [1] în 1981, apoi actualizat cu RFC 821 [2] în 1982 și modificat ulterior în 2008 cu introducerea SMTP extins ( RFC 1869 și RFC 5321 ), care este protocolul utilizat în prezent.

Deși serverele de e-mail folosesc SMTP pentru a trimite și primi e-mailuri, clienții de e-mail la nivel de utilizator folosesc doar SMTP pentru a trimite mesajul către serverul de e-mail, care se ocupă de trimiterea mesajului. Pentru a prelua mesaje, aplicațiile client utilizează de obicei protocoale precum IMAP sau POP3 .

Comunicarea între serverele de poștă electronică utilizează protocolul TCP pe portul 25 [2] . Cu toate acestea, clienții de e-mail trimit deseori e-mailuri către server pe portul 587 [3] . Deși sunt depreciate, furnizorii de e-mail și unii producători, cum ar fi Apple [4], permit totuși utilizarea portului 465 [5] non-standard pentru această operațiune.

Puteți asigura o conexiune SMTP cu TLS , cunoscută sub numele de SMTPS , prin STARTTLS .

Deși sistemele proprietare (cum ar fi Microsoft Exchange și IBM Notes ) și sistemele de webmail (precum Outlook.com , Gmail și Yahoo! Mail ) folosesc protocoale nestandardizate pentru a accesa căsuța poștală a contului respectiv de server de poștă, toate folosesc SMTP, pentru '' trimiterea și primirea de e-mail, în afara sistemelor lor.

Descriere

Este un protocol textual relativ simplu, în care sunt specificați unul sau mai mulți destinatari ai unui mesaj și, după verificarea existenței lor, mesajul este transferat. Este destul de ușor să verificați cum funcționează un server SMTP folosind un client telnet [6] . Protocolul SMTP folosește TCP ca protocol de strat de transport . Clientul deschide o sesiune TCP către serverul de pe portul 25 (mulți furnizori folosesc în schimb portul TCP 587 conform cerințelor RFC 2476 din decembrie 1998 pentru a limita spamul). O înregistrare de resurse MX (Mail eXchange) este utilizată pentru a asocia serverul SMTP cu un anumit nume de domeniu ( DNS ) .

Deoarece SMTP este un protocol text bazat pe codificarea ASCII [2] (în special ASCII NVT pe 7 biți), nu este permisă transmiterea directă a textului compus cu un set de caractere diferit (deci nici măcar fișiere binare). Standardul MIME vă permite să extindeți formatul mesajului, menținând în același timp compatibilitatea cu software-ul existent. De exemplu, multe servere SMTP acceptă în prezent extensia 8BITMIME , care permite un transfer de text care conține caractere accentuate (non-ASCII) fără a fi nevoie de transcodare. Alte limite SMTP, cum ar fi lungimea maximă a unei linii, împiedică trimiterea fișierelor binare fără transcodare . (Rețineți că fișierele binare trimise cu HTTP utilizează formatul MIME fără a fi nevoie de transcodare.)

SMTP este un protocol care vă permite să trimiteți numai mesaje de poștă electronică, dar nu să le solicitați de la un server: pentru a face acest lucru, clientul de poștă electronică trebuie să utilizeze alte protocoale, precum POP3 (Post Office Protocol) și IMAP (Internet Message Access Protocol) .

Istorie

În anii 1960, mai multe soluții one-to-one pentru schimbul de mesaje erau deja utilizate. Oamenii comunicau între ei folosind sisteme dezvoltate pentru un sistem mainframe specific. Pe măsură ce computerele conectate au crescut, în special în ARPANET , s-au dezvoltat diferite standarde pentru a permite schimbul de e-mail între utilizatorii diferitelor sisteme. SMTP a ieșit din aceste standarde în anii 1970.

Rădăcinile SMTP pot fi găsite în două implementări descrise în 1971: protocolul Mail Box, a cărui implementare a fost discutată [7] , dar este acoperită în diferite RFC-uri, inclusiv RFC 196 [8] , și implementată în programul SNDMSG care, conform RFC 2235 , a fost inventat de Ray Tomlinson de la BBN pentru a fi utilizat pe computerele TENEX pentru a trimite mesaje prin ARPANET.

Alte implementări includ FTP Mail [9] și Mail Protocol, ambele din 1973 [10] . Lucrările de dezvoltare au continuat pe parcursul anilor 1970, până când, în jurul anului 1980, rețeaua ARPANET a fost transformată în rețeaua modernă de internet. Jon Postel a propus un protocol de transfer de corespondență în 1980, care a început să elimine dependența de e-mail de FTP [11] . SMTP a fost publicat sub numele de RFC 788 în noiembrie 1981 [12] .

La începutul anilor 1980, SMTP a devenit utilizat pe scară largă. La acea vreme, era o extensie a UUCP (prescurtarea pentru Unix-to-Unix Copy Program, este o suită de programe și protocoale care permit executarea de la distanță a comenzilor și transferul de fișiere și e-mailuri între computere), care era mai potrivită pentru gestionarea transferul de e-mailuri între computerele conectate intermitent. Cu toate acestea, SMTP funcționează cel mai bine cu expeditorul și receptorul conectat întotdeauna la rețea. Ambele folosesc un mecanism de stocare și redirecționare și sunt exemple de logică push .

Sendmail , lansat cu 4.1cBSD , la scurt timp după RFC 788 , a fost unul dintre primii agenți de transfer de e-mail care au implementat SMTP [13] . Datorită faptului că BSD Unix a devenit cel mai popular sistem de operare de pe internet, sendmail a devenit cel mai utilizat agent de transfer de mail (server de mail). Alte servere SMTP sunt Postfix , qmail , Novell GroupWise , Exim, Novell NetMail , Microsoft Exchange Server și Oracle Communications Messagging Server .

Capacitatea de a trimite mesaje (RFC 2476 [14] ) și SMTP-AUTH (RFC 2554 [15] ) au fost dezvoltate în 1998 și 1999, introducând o nouă tendință în livrarea e-mailurilor. Inițial, serverele SMTP erau de obicei în cadrul unei organizații, primeau e-mailuri pentru organizație din exterior și livrau mesaje de la organizație către exterior. Datorită extinderii rapide a Word Wide Web , serverele SMTP au trebuit să introducă reguli și metode specifice pentru livrarea e-mailurilor și autentificarea utilizatorilor pentru a preveni abuzurile, cum ar fi livrarea de mesaje nesolicitate ( spam ). Lucrarea la trimiterea mesajelor (RFC 2476 [16] ) a fost dezvoltată deoarece cele mai faimoase servere de poștă au suprascris deseori poșta pentru a remedia problemele conținute în ea, cum ar fi, de exemplu, adăugarea numelui de domeniu la o adresă nespecificată. Acest comportament este dorit atunci când mesajul este corectat într-o stare inițială, dar periculoasă și rău intenționată, atunci când mesajul a fost generat în altă parte și este pe cale să fie transmis. Separarea corespondenței între livrare și transmisie este văzută ca o modalitate de a permite și încuraja trimiterea rescrierii și blocarea releuului de rescriere. Această separare între livrare și transmisie a devenit rapid baza securității poștei.

După ce a început ca un protocol ASCII pe 7 biți pe bază de text pur, SMTP nu a gestionat bine fișierele și caracterele binare care nu sunt utilizate în limba engleză. Standarde precum Multipurpose Internet Mail Extension ( MIME ) au fost dezvoltate pentru a codifica fișiere binare pentru transfer prin SMTP. Agenții de transfer poștal (MTA), dezvoltați după Sendmail, au avut tendința de a fi implementați ca 8-bit-clean, astfel încât orice fișier text care conține date (în orice codificare ASCII de 8 biți) ar putea fi transmis prin SMTP. În prezent, MTA-urile pe 8 biți tind să accepte extensia 8BITMIME , permițând transmiterea ușoară a fișierelor binare, cum ar fi fișierele text. Recent, extensia SMTPUTF8 a fost dezvoltată pentru a permite suportul textului codificat UTF-8 , garantând schimbul de mesaje în limbi precum chirilica și chineza .

Mulți oameni au contribuit la dezvoltarea specificației SMTP, inclusiv Jon Postel , Eric Allman, Dave Crocker, Ned Freed, Randall Gellens , John Klensin și Keith Moore .

Model de gestionare a e-mailurilor

Un e-mail este trimis de la un client de e-mail ( agent de utilizator de e-mail , MUA) către un server de e-mail ( agent de trimitere de e-mail , MSA), utilizând SMTP prin TCP pe portul 587. Majoritatea furnizorilor de e-mail permit totuși trimiterea pe portul tradițional 25. MSA livrează e- mailul către agentul de transfer de e - mail (MTA). Adesea MSA și MTA sunt instanțe ale aceluiași software, pornite cu opțiuni diferite pe aceeași mașină. În plus față de un client clasic, un cont de e-mail de ieșire cu protocol SMTP poate fi configurat în orice aplicație software care poate trimite e-mail.

MTA folosește DNS pentru a găsi înregistrarea MX a unui anumit domeniu (partea adresei după caracterul @). Înregistrarea MX conține numele gazdei țintă. Pe baza numelui gazdei și a altor informații, MTA alege un server și se conectează ca client SMTP.

Transferul de mesaje poate avea loc într-o singură conexiune între două MTA-uri sau printr-o serie de hamei în mai multe sisteme intermediare. Un server SMTP poate fi destinatarul mesajului sau intermediar (efectuarea operațiunilor de stocare și redirecționare) sau gateway (poate transmite mesajul utilizând alte protocoale, precum și SMTP). Fiecare salt este un transfer formal de responsabilitate asupra mesajului, astfel încât fiecare server care primește mesajul trebuie să-l livreze sau să raporteze o eroare.

Odată ce serverul de recepție acceptă mesajul primit, acesta îl livrează unui agent de livrare de e-mail (MDA), care îl salvează într-o cutie poștală pentru livrare locală.

Odată livrat la serverul de e-mail, mesajul este stocat pentru a fi preluat de un client de poștă autentificat specific (MUA). E-mailul este recuperat prin intermediul aplicațiilor de pe dispozitivul utilizatorului, numite clienți de poștă electronică, utilizând Protocolul de acces la mesaje pe Internet (IMAP), care facilitează atât accesul la e-mailuri, cât și gestionarea e-mailurilor stocate, sau Post Office Protocol (POP) ) care utilizează în mod obișnuit formatul mbox tradițional pentru e-mailuri sau un sistem proprietar precum Microsoft Exchange / Outlook sau Lotus Notes / Domino. Clienții Webmail pot utiliza ambele moduri, dar protocolul de recuperare nu este de obicei un protocol standard. POP3 și IMAP sunt protocoale similare, dar cu unele diferențe substanțiale:

  • POP3 : clientul de e-mail se conectează la server, descarcă e-mail-ul local, șterge mesajele descărcate de pe server și se deconectează (este totuși posibil să setați unii parametri pentru a evita ștergerea e-mailului de pe server). Caracteristicile acestui protocol: posibilitatea de a avea mesaje întotdeauna salvate local, de aceea nu este necesară o conexiune la internet (evident necesară pentru trimiterea și descărcarea de mesaje noi) și economisirea spațiului pe server.
  • IMAP : clientul de poștă electronică se conectează la server, solicită mesaje noi și le prezintă utilizatorului salvându-le sub formă de fișiere temporare (similar cu POP3, este posibil să salvați mailurile local permanent). Orice modificare pe care o faceți mesajelor se reflectă și pe server și pe orice alt dispozitiv la care sunteți conectat. Caracteristici: e-mailul salvat pe server, prin urmare, întotdeauna disponibil de pe orice dispozitiv prin autentificare, posibilitatea de a prelua e-mailul chiar dacă un anumit dispozitiv pe care este consultat e-mailul nu mai funcționează, economisind spațiu pe client.

SMTP definește modul în care este transmis mesajul, nu conținutul acestuia. Acesta definește structura și parametrii săi, cum ar fi expeditorul plicului , dar nu antetul (cu excepția informațiilor de urmărire) sau corpul mesajului în sine. STD 10 și RFC 5321 [17] definesc structura SMTP, în timp ce STD 11 și RFC 5322 [18] definesc mesajul (antet și corp) printr-un format de mesaj Internet.

Structura protocolului

SMTP este un protocol bazat pe conexiune , bazat pe text , în care un expeditor de mesaje comunică cu un receptor de e-mail prin trimiterea șirurilor de comandă și furnizarea informațiilor necesare printr-un canal de comunicație fiabil, de obicei bazat pe TCP . O sesiune SMTP constă în schimbul de comenzi generate de un client SMTP și răspunsurile corespunzătoare ale serverului SMTP. O sesiune poate include zero sau mai multe tranzacții SMTP. O tranzacție SMTP constă din trei secvențe de comenzi și răspunsuri:

  1. MAIL FROM : comandă pentru a defini adresa de returnare, numită și return-path [19] , reverse-path [17] , adresa de respingere, mfrom sau plic expeditor.
  2. RCPT TO : comandă pentru a defini destinatarul mesajului. Această comandă poate fi trimisă de mai multe ori, o dată pentru fiecare destinatar (adresele fac parte din structură (plic)).
  3. DATA : comandă trimisă pentru a semnaliza începutul mesajului text, conținutul mesajului, așa cum este definit în plic. Se compune dintr-un antet și un corp, separate printr-o linie goală. DATA totuși, este un set de comenzi la care serverul răspunde de două ori: prima dată ca o confirmare a primirii textului (confirmare), a doua oară după secvența de sfârșit de date pentru a accepta sau respinge întregul mesaj.

În plus față de răspunsurile intermediare la comanda DATA , fiecare răspuns al serverului poate fi pozitiv (caracterizat prin codul 2xx) sau negativ. Răspunsurile negative pot fi permanente (5xx) sau temporare (4xx). O respingere reprezintă un eșec permanent și clientul ar trebui să trimită un mesaj rebot către serverul de la care a primit mesajul. O scădere este un răspuns pozitiv, urmat de mesajul de respingere, mai degrabă decât mesajul de livrare.

Gazda inițială, clientul SMTP, poate fi fie clientul de e-mail al unui utilizator, denumit agent de utilizator de e-mail (MUA), fie se bazează pe un agent de transfer de e-mail (MTA), care este de fapt un server SMTP care se comportă ca un client SMTP pentru sesiunea curentă. Serverele SMTP mai avansate mențin o coadă de mesaje pentru a retrimite mesajele care nu au fost livrate (temporar).

Un server de releu determină de obicei la ce server ar trebui să se conecteze prin înregistrarea DNS MX (Mail eXchange) a fiecărui domeniu. Dacă nu există nicio înregistrare MX, unele servere verifică înregistrarea A. Principala diferență între MTA și MSA este că conectarea la un MSA necesită autentificare SMTP . Împărțirea între MTA și MSA are mai multe beneficii:

  • MSA, întrucât interacționează direct cu utilizatorul (prin MUA), poate corecta mici erori în formatul mesajului (de exemplu, data lipsă, destinatar lipsă, nume de domeniu inexistent etc.). Un MTA care acceptă un mesaj nu poate face aceste modificări în mod fiabil și sigur, deoarece orice modificări făcute de MTA ajung la expeditorul mesajului după ce mesajul a fost deja trimis.
  • MSA și MTA pot avea diferite soluții de blocare a spamului. Majoritatea MSA-urilor necesită autentificare prin e-mail și parolă și, prin urmare, expeditorul mesajului poate fi urmărit. Acest lucru permite MSA să aibă o politică de spam mai puțin strictă.

Pentru mai multe informații despre diferențe, consultați pagina Wikipedia despre agenții de trimitere a mesajelor (în engleză).

Recuperarea mesajelor

SMTP este doar un protocol de livrare. În cea mai obișnuită utilizare, mesajul este trimis către serverul de e-mail de destinație sau către server în pasul următor. Mesajul este direcționat pe baza serverului de destinație, nu pe baza utilizatorului căruia urmează să i se trimită. Alte protocoale, cum ar fi Post Office Protocol (POP) și Internet Message Access Protocol (IMAP), sunt dezvoltate special pentru a fi utilizate de utilizator, preluând mesaje și gestionând cutia poștală. Pentru a permite unui server de poștă conectat intermitent să preia mesaje de pe un server la distanță, SMTP are o funcție de a iniția o coadă de procesare a mesajelor pe un server la distanță (vezi mai jos).

Inițializare la coadă de mesaje la distanță

Initializarea cozii de mesaje la distanță este o caracteristică SMTP care permite unei gazde la distanță să inițieze procesarea cozii de e-mail pe un server, care poate primi mesaje destinate acesteia prin trimiterea unei comenzi TURN . Cu toate acestea, această caracteristică a fost considerată nesigură [20] și a fost înlocuită (RFC 1985 [20] ) de comanda ETRN care funcționează mai sigur folosind o metodă de autentificare bazată pe informații despre sistemul de nume de domeniu.

Internaționalizare

Utilizatorii pentru care limba scrisă nu se bazează pe alfabetul latin sau care utilizează simboluri care nu sunt conținute în setul de caractere ASCII , pot avea probleme cauzate de faptul că adresa de e-mail necesită doar caractere latine. RFC 6531 [21] s-a născut pentru a rezolva această problemă, introducând extensia SMTPUTF8 și suport pentru codarea multi-octet pentru caractere non-ASCII pentru adrese de e-mail, pentru a sprijini limbi precum greaca și chineza.

Server SMTP

Un client de e-mail trebuie să cunoască adresa IP a serverului SMTP de pornire, care trebuie furnizat ca parte a configurației sale (de obicei ca nume DNS , câmp MX).

Restricții de acces

Administratorii serverului trebuie să impună un fel de control asupra clienților care pot utiliza serverul, pentru a permite gestionarea, de exemplu, a spamului. Există două soluții utilizate de obicei:

  • În trecut, multe sisteme impuneau restricții de utilizare bazate pe locația geografică a clientului, permițând doar utilizarea clienților ale căror adrese IP sunt printre cele administrate de administratorul serverului. Utilizarea de către alte adrese IP nu a fost permisă.
  • Serverele SMTP moderne oferă de obicei un sistem alternativ care impune clientului să se autentifice prin acreditări înainte de a permite accesul.

Restricții de acces bazate pe locație

În cadrul acestor sisteme, un ISP nu permite accesul la serverul SMTP de către utilizatorii din afara rețelei gestionate chiar de ISP . Mai precis, serverul ar putea permite accesul doar al utilizatorilor cu o adresă IP furnizată de ISP , care este echivalentă cu necesitatea ca ambii, expeditor și destinatar, să fie conectați la internet utilizând același ISP . Un utilizator mobil, totuși, poate fi adesea într-o rețea care nu este cea a ISP-ului său normal și, prin urmare, poate să nu poată trimite mesaje, deoarece configurația serverului SMTP ales nu mai este accesibilă.

Prin urmare, serverul SMTP al unei organizații ar putea furniza servicii doar utilizatorilor din aceeași rețea, blocând accesul la rețeaua externă. Alternativ, serverul ar putea efectua o verificare a gamei de adrese IP a clientului. Aceste metode au fost utilizate în mod obișnuit de entități și instituții, cum ar fi universitățile care furnizează un server SMTP numai pentru utilizarea organizației interne. Cu toate acestea, multe dintre aceste organizații folosesc acum o metodă de autentificare.

Atunci când un utilizator este mobil și se poate conecta la internet prin intermediul unor ISP diferiți, acest tip de restricție de utilizare este oneros și schimbarea adresei serverului de ieșire este impracticabilă. Este de dorit să puteți utiliza configurațiile clientului de poștă electronică care nu trebuie modificate.

Autentificarea clientului

Serverele SMTP moderne necesită de obicei autentificarea clientului prin acreditări înainte de a permite accesul, în loc să blocheze direct accesul în funcție de locație, așa cum este descris mai sus. Acest sistem mai flexibil permite utilizatorilor de telefonie mobilă să aibă un server SMTP fix în ieșire. Autentificarea SMTP, adesea prescurtată ca SMTP AUTH , este o extensie a SMTP pentru a permite accesul prin mecanisme de autentificare.

Releu deschis

Un server accesibil pe întregul internet și care nu adoptă aceste tipuri de restricții de acces se numește releu deschis . Adoptarea unui astfel de sistem este considerată o practică proastă [22] .

Ușile

Comunicarea între serverele de e-mail are loc de obicei prin TCP pe portul 25, deși clienții de e-mail folosesc de obicei un alt port. Serviciile de poștă electronică acceptă, de obicei, e-mailuri pentru a fi trimise în porturi:

  • 587 (livrare), după cum este standardizat în RFC 6409 [23] (anterior RFC 2476 [16] ).
  • 465. Acest port a fost depreciat de RFC 2487 [24] , după ce a fost atribuit serviciului SMTP securizat în 1990. Cu toate acestea, este utilizat în mod obișnuit de furnizorii de poștă.

Portul 2525 și altele pot fi utilizate de unii furnizori, dar nu sunt acceptate oficial.

Mulți furnizori de servicii de internet blochează acum toate mesajele trimise de la portul 25, ca măsură anti-spam [25] și permit trimiterea acestuia numai de la serverul de mail desemnat. Furnizorul poate controla astfel traficul de ieșire.

Comenzi SMTP

HELO : Trimis de un client pentru autoidentificare, de obicei cu un nume de domeniu.

EHLO : permite serverului să identifice suport pentru comenzile ESMTP (Extended Simple Mail Transfer Protocol ) .

MAIL FROM : Identifică expeditorul mesajului. Folosit sub forma MAIL FROM:

RCPT TO : Identifică destinatarii mesajului. Folosit sub forma RCPT TO:

TURN : Permite clientului și serverului să schimbe rolurile și să trimită mesaje în direcția opusă, fără a fi nevoie să stabilească o nouă conexiune.

ATRN : Comanda ATRN ( TURN autentificat) utilizează, la discreția sa, unul sau mai multe domenii ca parametru. Comanda ATRN trebuie respinsă dacă sesiunea nu a fost autentificată.

SIZE : Oferă un mecanism prin care serverul SMTP poate indica dimensiunea maximă acceptată a mesajului. Serverele compatibile trebuie să furnizeze extensii de dimensiuni pentru a indica dimensiunea maximă admisibilă a mesajului. Clienții nu trebuie să trimită mesaje mai mari decât dimensiunea indicată de server.

ETRN : o extensie a SMTP. ETRN este trimis de un server SMTP pentru a solicita unui alt server să trimită orice mesaje de e-mail pe care le are.

PIPELINING : Vă permite să trimiteți un flux de comenzi fără a aștepta un răspuns după fiecare comandă.

CHUNKING : Este o comandă ESMTP care înlocuiește comanda DATA . Această comandă trimite o comandă BDAT cu un argument care conține numărul total de octeți ai mesajului, astfel încât gazda SMTP nu trebuie să scaneze continuu pentru a determina sfârșitul datelor. Serverul de primire numără octeții din mesaj și, atunci când dimensiunea mesajului se potrivește cu valoarea trimisă de comanda BDAT , serverul presupune că a primit toate datele mesajului.

DATA : Trimise de un client pentru a iniția transferul conținutului unui mesaj.

DSN : Aceasta este o comandă ESMTP care declanșează notificări privind starea de livrare.

RSET : RSET întreaga tranzacție de mesaje și resetați bufferul.

VRFY : Verificați dacă este disponibilă o cutie poștală pentru livrarea mesajelor. De exemplu, VRFY ted verifică dacă cutia poștală a lui VRFY ted se află pe serverul local.

HELP : Returnează lista de comenzi acceptate de serviciul SMTP.

QUIT : Încheiați sesiunea.

Exemplu de comunicare SMTP

Mai jos este o tranzacție SMTP între două cutii poștale ( Alice și Bob ) care se află pe același domeniu ( example.com ). Liniile trimise de client sunt precedate de „C:”, în timp ce cele trimise de server de „S:” (cu toate acestea, aceste scrisori nu fac parte din schimbul de mesaje, ci servesc doar ca exemplu).

 S: 220 smtp.example.com ESMTP Postfix
    C: HELO relay.example.com
S: 250 smtp.example.com
    C: MAIL DE LA: <[email protected]>
S: 250 OK
    C: RCPT TO: <[email protected]>
S: 250 OK
    C: DATA
S: 354 Terminați datele cu <CR> <LF>. <CR> <LF>
    C: De la: „Bob” <[email protected]>
    C: Către: „Alice” <[email protected]>
    C: Data: marți, 15 ianuarie 2008 16:02:43 -0500
    C: Subiect: Mesaj de testare
    C: 
    C: Bună, acesta este un mesaj de testare
    C :.
S: 250 Ok: în coadă ca 12345
    C: IEȘI
S: 221 Pa

Clientul notifică destinatarul e-mailului prin comanda RCPT TO . În cazul în care mesajul nu poate fi livrat, se returnează o adresă de respingere. În acest caz, mesajul este trimis către o cutie poștală de pe același server (dacă ar exista și un Cc, mesajul ar fi trimis și la cutia poștală a acestuia). Comanda SMTP corespunzătoare este RCPT TO . Fiecare comandă executată duce cu succes la generarea unei confirmări de către server cu codul 250.

Începutul transmiterii textului prin e-mail este identificat prin comanda DATA , după care textul este transmis linie cu linie și se termină cu secvența <CR><LF>.<CR><LF> numită secvență de sfârșit de- data . Deoarece o linie poate conține doar un punct (.) Ca parte a textului, clientul trimite două puncte consecutive de fiecare dată când o linie începe cu un punct. În mod similar, serverul înlocuiește fiecare secvență de puncte consecutive cu doar una (această tehnică se numește dot-stuffing ).

Răspunsul pozitiv al serverului la finalul datelor înseamnă că serverul a preluat livrarea mesajului. Un mesaj poate fi duplicat dacă, în această etapă, apare o problemă de comunicare, cauzată de exemplu de o pană de curent. Până când expeditorul nu primește mesajul cu codul 250 , se presupune că mesajul nu a fost livrat. În mod similar, după ce destinatarul decide să accepte mesajul, expeditorul presupune că mesajul a fost livrat. Cu toate acestea, în acest interval de timp (timpul dintre momentul în care mesajul a fost trimis la momentul în care clientul primește răspunsul caracterizat prin codul 250), ambii agenți au copii active ale mesajelor pe care încearcă să le livreze [26] și acest lucru poate provoca probleme de mesaj duplicat. Pentru a limita acest fenomen, se specifică de obicei un timp de expirare între 5 și 10 minute [27] .

Comanda QUIT încetează sesiunea. Dacă e-mailul are alți destinatari, clientul se va conecta la un server SMTP adecvat pentru destinatarii următori. Informațiile pe care clientul le trimite cu comenzile HELO și MAIL FROM sunt inserate (nu sunt afișate în codul de exemplu) în e-mail ca câmpuri de antet suplimentare, de către serverul destinatar, adăugând câmpurile Received și Return-Path .

Unii clienți sunt implementați pentru a închide conexiunea după ce mesajul a fost acceptat (în exemplul 250 OK: la coadă ca 12345 ), astfel încât ultimele două linii pot fi omise. Cu toate acestea, această soluție poate provoca eșecul serverului la trimiterea răspunsului 221 .

Extensii

Clientul poate afla ce opțiuni acceptă un server prin mesajul EHLO , așa cum se arată mai jos, în loc să trimită HELO tradițional. Clientul revine la un mesaj HELO numai dacă serverul nu acceptă extensii SMTP. [28]

Clienții moderni pot folosi cuvântul cheie SIZE , introdus de extensia ESMTP , pentru a cere serverului dimensiunea maximă a mesajului acceptată. În trecut, exista riscul ca clienții și serverele să încerce să transfere mesaje prea mari, care ar fi blocate după utilizarea resurselor de rețea, inclusiv timpul de conectare [29] .

Utilizatorii pot determina manual, în prealabil, dimensiunea maximă acceptată de serverul ESMTP, prin înlocuirea comenzii HELO cu EHLO , ca mai jos

 S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.com
S: 250-smtp2.example.com Bună ziua bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-TIPELINING
S: 250 AJUTOR

Răspunsul arată că smtp2.example.com declară că acceptă un mesaj maxim cu o dimensiune fixă ​​nu mai mare de 14.680.064 octeți (8 biți, octeți). Cu toate acestea, dimensiunea maximă a mesajului poate varia în funcție de utilizarea curentă a resurselor serverului (este posibil să nu poată primi un mesaj atât de mare).

În cel mai simplu caz, un server ESMTP declară o dimensiune maximă imediat după primirea comenzii EHLO , deși conform RFC 1870 [30] , parametrul SIZE din răspunsul EHLO este opțional. Il client potrebbe invece, quando invia un comando MAIL FROM , includere la dimensione stimata del messaggio che sta per inviare, così il server potrebbe rifiutare la ricezione di messaggi troppo grandi.

La sicurezza del protocollo SMTP

Una delle limitazioni del protocollo SMTP originario è che non gestisce l' autenticazione dei mittenti. Oltre al rischio di spam , esiste la possibilità di inviare e-mail facendo apparire come mittente l'indirizzo corrispondente ad un altro account. Senza accedere all'account di terzi, è possibile stabilire una connessione al mail-server e scrivere un messaggio in codice SMTP contenente i comandi relativi a mittente e destinatario, dare i relativi parametri e il corpo della e-mail.

Per ovviare a questi problemi è stata sviluppata un'estensione chiamata SMTP-AUTH .

Nonostante questo, lo spam rimane ancor oggi un grave problema della posta elettronica. Tuttavia, non si ritiene praticabile una revisione radicale del protocollo SMTP, per via del gran numero di implementazioni del protocollo attuale (ad esempio, è stato proposto Internet Mail 2000 come protocollo alternativo).

Per questo motivo sono stati proposti diversi protocolli ausiliari per assistere le transazioni SMTP. L' Anti-Spam Research Group dell' IETF sta lavorando su varie proposte di autenticazione e-mail centrate sulla flessibilità, leggerezza e scalabilità .

Gli standard RFC relativi

Pubblicato nel 2008, il RFC 5321 – "The Simple Mail Transfer Protocol" è il documento di specifica principale per quanto riguarda il protocollo SMTP e rende obsoleti il RFC 821 (conosciuto anche come STD 10), RFC 974 , RFC 1869 e RFC 2821 . Inoltre, i seguenti RFC estendono le funzionalità del protocollo SMTP: (in lingua originale)

  • RFC 1123 – Requirements for Internet Hosts—Application and Support (STD 3)
  • RFC 1870 – SMTP Service Extension for Message Size Declaration (rende obsoleto RFC 1653 )
  • RFC 2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
  • RFC 2920 – SMTP Service Extension for Command Pipelining (STD 60)
  • RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
  • RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (rende obsoleto RFC 2487 )
  • RFC 3461 – SMTP Service Extension for Delivery Status Notifications (rende obsoleto RFC 1891 )
  • RFC 3463 – Enhanced Status Codes for SMTP (rende obsoleto RFC 1893 )
  • RFC 3464 – An Extensible Message Format for Delivery Status Notifications (rende obsoleto RFC 1894 )
  • RFC 3798 - Message Disposition Notification
  • RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
  • RFC 4952 – Overview and Framework for Internationalized E-mail
  • RFC 4954 – SMTP Service Extension for Authentication (rende obsoleti RFC 2554 )
  • RFC 5068 – E-mail Submission Operations: Access and Accountability Requirements (BCP 134)
  • RFC 5322 – Internet Message Format (rende obsoleto RFC 822 aka STD 11, and RFC 2822 )
  • RFC 5336 - SMTP Extension for Internationalized Email Addresses (aggiorna RFC 2821 , RFC 2822 , and RFC 4952 )
  • RFC 5504 - Downgrading Mechanism for Email Address Internationalization
  • RFC 6409 – Message Submission for Mail (rende obsoleti RFC 4409 , RFC 2476 )
  • RFC 6522 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (rende obsoleti RFC 3462 , RFC 1892 )

(tradotti in italiano)

Note

  1. ^ RFC 778 , su tools.ietf.org .
  2. ^ a b c RFC 821 , su tools.ietf.org .
  3. ^ RFC 4409 , su tools.ietf.org .
  4. ^ Porte utilizzate per servizi Apple , su support.apple.com .
  5. ^ Lista porte - IANA ( TXT ), su iana.org .
  6. ^ Test comunicazione SMTP con telnet , su port25.com .
  7. ^ ( EN ) The History of Electronic Mail , su www.multicians.org . URL consultato il 6 dicembre 2017 .
  8. ^ RFC 196 , su tools.ietf.org .
  9. ^ ( EN ) MD Kudlick, Network mail meeting summary , su tools.ietf.org . URL consultato il 6 dicembre 2017 .
  10. ^ ( EN ) JE White, Proposed Mail Protocol , su tools.ietf.org . URL consultato il 6 dicembre 2017 .
  11. ^ ( EN ) Postel, J., Sluizer, S., Mail Transfer Protocol , su tools.ietf.org . URL consultato il 6 dicembre 2017 .
  12. ^ ( EN ) J. Postel, Simple Mail Transfer Protocol , su tools.ietf.org . URL consultato il 6 dicembre 2017 .
  13. ^ docs.freebsd.org , https://docs.freebsd.org/44doc/smm/09.sendmail/paper.pdf .
  14. ^ ( EN ) Randall Gellens, Message Submission , su tools.ietf.org . URL consultato il 6 dicembre 2017 .
  15. ^ RFC 2554 , su tools.ietf.org .
  16. ^ a b RFC 2476 , su tools.ietf.org .
  17. ^ a b RFC 5321 , su tools.ietf.org .
  18. ^ RFC 5322 , su tools.ietf.org .
  19. ^ The MAIL, RCPT, and DATA verbs , su cr.yp.to .
  20. ^ a b RFC 1985 , su tools.ietf.org .
  21. ^ RFC 6531 , su tools.ietf.org .
  22. ^ In Unix, what is an open mail relay? - Knowledge Base , su kb.iu.edu , 17 giugno 2007. URL consultato il 14 dicembre 2017 (archiviato dall' url originale il 17 giugno 2007) .
  23. ^ RFC 6409 , su tools.ietf.org .
  24. ^ RFC 2487 , su tools.ietf.org .
  25. ^ ( EN ) ISPs Pitch In to Stop Spam , su PCWorld . URL consultato il 14 dicembre 2017 .
  26. ^ RFC 1047 , su tools.ietf.org .
  27. ^ RFC 5321 sezione 4.5.3.2.6 , su tools.ietf.org .
  28. ^ Estensioni SMTP - RFC 1869 , su tools.ietf.org .
  29. ^ Parametri Mail ( TXT ), su iana.org .
  30. ^ RFC 1870 , su tools.ietf.org .

Voci correlate

Telematica Portale Telematica : accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete
Estratto da " https://it.wikipedia.org/w/index.php?title=Simple_Mail_Transfer_Protocol&oldid=120880865 "