Descrierea protocolului SMTP

Protocolul SMTP a fost conceput pentru a funcționa diverse rețele pentru transportul e-mailului. Cu toate acestea, Internetul a devenit unul dintre cele mai utilizate, cu o conexiune TCP/IP stabilită prin portul 25. Majoritatea versiunilor de sistem de operare Linux instalează automat un pachet software pentru a suporta SMTP la instalarea diverselor servicii. Pentru a asigura capacitatea server la distanță lucrează folosind protocolul SMTP, te poți conecta la portul 25 al acestuia folosind programul telnet. Dacă se primește un răspuns de la acest port, atunci protocolul SMTP rulează pe server. Pe un server local puteți face același lucru conectându-vă folosind telnet la portul 25 de pe localhost. Un exemplu de sesiune telnet cu un server bazat pe Linux este prezentat în Lista 5.1.

1 $ telnet localhost 25 2 Încerc 127.0.0.1... 3 Conectat la localhost. 4 Caracterul de evacuare este „^]”. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Miercuri, 25 Aug 1999 18:35:33 -0500 6 QUIT 7 221 shadrach.smallorg.org închiderea conexiunii 8 Conexiunea închisă de gazda străină. 9 USD Lista 5.1.

Linia 1 arată formatul comenzii telnet folosind localhost și portul TCP 25. Linia 5 arată un răspuns tipic de la un server Linux care rulează software SMTP. Numărul care începe răspunsul este codul de răspuns din trei cifre. Acest cod poate fi folosit pentru a depana problemele de e-mail. Ceea ce urmează este numele serverului SMTP și o descriere a pachetului software SMTP care este distribuit de Consorțiul Sendmail. Linia 6 conține comanda QUIT pentru a închide sesiunea telnet. Serverul SMTP ar trebui apoi să emită un mesaj de închidere a sesiunii și să încheie conexiunea TCP. Din acest exemplu putem concluziona că protocolul SMTP utilizează comenzi simple text ASCII și returnează răspunsuri la mesaje text codificate cu trei caractere. Protocolul SMTP este descris în Internet Request For Comment (RFC) numărul 821, care a fost dezvoltat de Internet Engineering Task Force (IETF) și publicat pe 21 august 1982. De atunci, a suferit mai multe modificări, dar în general comenzile de bază ale protocolului nu s-au schimbat.

Comenzi de bază pentru client SMTP

După ce se stabilește o sesiune TCP, serverul SMTP trimite clientului un mesaj special de stabilire a conexiunii (după cum se arată în Lista 5.1). Din acest moment, conexiunea dintre cele două computere este controlată de clientul conectat la server. Clientul controlează conexiunea folosind un set de comenzi speciale pe care le trimite către server. Serverul, la rândul său, trebuie să răspundă corespunzător la fiecare comandă trimisă acestuia. RFC 821 descrie comenzile de bază pentru un client SMTP la care serverul trebuie să răspundă într-un mod specific. Deși de la crearea acestui document au fost introduse mai multe extensii la protocolul SMTP, acestea nu sunt încă acceptate de toate serverele de e-mail. În această secțiune, vom evidenția doar comenzile SMTP de bază definite în RFC 821. Secțiunea „Extensii protocol SMTP” discută unele dintre completările implementate în ultimele versiuni Pachetul SMTP.

Formatul comenzii în SMTP este simplu:

comanda,

unde comanda este o comandă de protocol SMTP cu patru caractere, iar parametrul este un parametru opțional care specifică tipul de date din comandă. În tabel 5.1 prezintă comenzile de bază ale protocolului SMTP. În continuare ne vom uita la aceste comenzi mai detaliat.

Echipa HELO

Prin definiție, comenzile de protocol SMTP au patru caractere. Salutul trimis de client către server este comanda HELO. Formatul comenzii este următorul:

Nume de domeniu HELO

Scopul comenzii HELO este de a prezenta clientul serverului SMTP. Din păcate, această metodă de acces a fost dezvoltată în stadiul inițial al dezvoltării Internetului, când încă nu existau atât de multe încercări de pătrundere neautorizată în sistemele informatice. După cum puteți vedea, clientul își poate numi orice nume pe linia de comandă. Acest lucru a condus la faptul că în prezent majoritatea serverelor SMTP utilizează această comandă pur formal. Dacă încearcă să identifice clientul, atunci un mecanism de căutare inversă a DNS este activat pentru a determina numele de gazdă real al clientului de la adresa sa IP. De obicei, din motive de securitate, serverele SMTP vor refuza conexiunile la gazde a căror adresă IP nu se rezolvă într-un nume de gazdă corespunzător. Prin trimiterea acestei comenzi, clientul anunță serverul că dorește să stabilească o conexiune cu acesta. Răspunzând la această comandă, serverul, la rândul său, anunță că a fost stabilită o nouă conexiune cu clientul și este gata să accepte comenzile ulterioare de la acesta.

Utilizatori clienți și gazde clienți

Când lucrați cu protocolul SMTP, trebuie să faceți distincția între clienții SMTP. Utilizatorii clienți și gazdele client nu sunt același lucru. Atunci când creează un mesaj de e-mail, utilizatorul sistemului de e-mail este, de asemenea, un client al său localhost. Odată ce mesajul e-mail este trimis, acesta nu mai este un client al procesului SMTP. Acum computerul său gazdă local se ocupă de procesul de livrare a mesajelor și acționează ca un client SMTP. Când o gazdă locală se conectează la o gazdă la distanță pentru a transmite un mesaj utilizând protocolul SMTP, aceasta acționează ca un client al procesului SMTP. Comanda HELO declară numele ca client localhost, și nu utilizatorul real care a trimis mesajul. Destul de des aceste concepte sunt confuze, ceea ce face dificilă rezolvarea problemelor care apar în sistemele de e-mail.

Comanda MAIL

Comanda MAIL este folosită pentru a iniția o sesiune de e-mail cu serverul după ce comanda HELO a fost trimisă. Indică de la cine vine mesajul. Formatul comenzii MAIL este următorul:

MAIL cale inversă

Argumentul reverse-path nu numai că specifică expeditorul mesajului, dar specifică și o rută prin care mesajul poate fi returnat dacă nu poate fi livrat. Dacă expeditorul este utilizatorul de pe computerul client care a inițiat sesiunea SMTP, atunci formatul comenzii va fi următorul:

POSTA DE LA: [email protected]

Rețineți că câmpul FROM specifică adresa de e-mail a expeditorului mesajului, inclusiv numele complet al computerului gazdă client. Aceste informații trebuie să fie prezente în câmpul FROM al mesajului de e-mail (dar mai multe despre asta mai târziu). Dacă un mesaj de e-mail a trecut prin mai multe noduri pe drumul de la expeditor la destinatar, atunci fiecare dintre ele va adăuga informații despre sine în câmp . În acest fel, calea mesajului prin serverele de mail este documentată. Destul de des, e-mailul de la clienții rețelei private trebuie să treacă prin mai multe servere de e-mail înainte de a ajunge pe Internet. Informațiile conținute în câmpul de cale inversă sunt adesea utile în depanarea problemelor din sistemele de e-mail sau în identificarea serverelor de e-mail care încearcă să-și ascundă identitatea prin trimiterea de mesaje prin servere SMTP necunoscute.

Unul dintre elementele principale este configurația serverului SMTP. Să ne uităm la ce este și cum să facem setările necesare pentru diverse situații.

Ce este SMTP?

Abrevierea SMTP provine din expresia engleză, care înseamnă „protocol simplu de trimitere a e-mailurilor”. Aplicația sa este limitată în principal la rețelele bazate pe TCP/IP și la nivelul utilizatorului.

Orice program de e-mail, adesea numit client de e-mail, are setări speciale, permițându-vă să configurați parametrii protocolului. Prin aceasta, toate e-mailurile sunt trimise către serverul de e-mail, unde așteaptă retransmiterea. Inițial, serverul SMTP folosește portul TCP numărul 25. Cu toate acestea, odată cu dezvoltarea serviciilor de e-mail, setările se pot schimba semnificativ.

Trebuie să configurez serverul când trimit o scrisoare de la un serviciu de e-mail?

De regulă, orice serviciul postal pe Internet, oferind utilizatorilor servicii de trimitere și primire a corespondenței electronice, este deja echipat cu un server SMTP preconfigurat. Adică, utilizatorul nu trebuie să producă nimic.

Serviciile în sine, pentru a se autentifica în propria cutie poștală, necesită doar utilizatorului să introducă datele de conectare și parola specificate în timpul înregistrării, iar configurarea, de exemplu, serverul SMTP Mail.Ru nu este necesară din singurul motiv că toate acestea a fost făcut inițial în serviciul în sine (fără acesta, serviciul pur și simplu nu ar funcționa). Dar ce să faci dacă utilizatorul, dintr-un motiv oarecare, nu folosește resursele de internet, dar preferă clienții standard precum Microsoft? Outlook Expressși Outlook sau terți produse software, în timp ce aveți o cutie poștală înregistrată în serviciul de Internet?

Configurarea unui server SMTP (Mail.Ru este serviciul de poștă în care este înregistrată cutia poștală)

Să ne uităm la parametrii standard cărora ar trebui să li se aplice acest serviciu. Indiferent de clientul de e-mail folosit, absolut toate setările vor fi identice.

Deci, pentru a configura corect serverul SMTP Mail.Ru, ar trebui să setați următorii parametri:

• server de corespondență de ieșire - smtp.mail.ru;
• nume de utilizator - numele complet al adresei de e-mail înregistrată în serviciu;
• parola - combinația curentă de coduri de litere, cifre și simboluri utilizate pentru a intra în căsuța poștală;
• portul la selectarea protocolului de criptare SSL/TLS - 465.

După ce aceste setări vor intra în vigoare, e-mailurile pot fi primite direct în aplicația utilizată programul utilizatorului. După cum puteți vedea, portul serverului SMTP diferă de cel standard (25), dar acesta este deja asociat cu protocoalele TCP/IP.

Configurarea unui server SMTP pe Yandex

Serviciul Yandex.Ru nu este mai puțin popular. Serverul SMTP pentru acesta este configurat într-un mod complet similar.

Cu toate acestea, pentru serverul de mesaje de ieșire, se folosește adresa smtp.yandex.ru, portul este setat la 465, dar setările de securitate sunt setate exclusiv la TLS.

Instalarea unui server SMTP pentru corespondență

Acum să trecem la situații mai complexe când utilizatorul, dintr-un motiv oarecare (de exemplu, pentru a-și promova propria afacere sau site-ul web) trebuie să efectueze mailing-uri în masă. Nu are rost să faceți acest lucru manual folosind servicii online sau clienți de e-mail, fie și doar din motivul că este nevoie de prea mult timp și efort. Prin urmare, puteți face acest lucru în două moduri - cumpărați un server SMTP configurat gata făcut sau configurați-l singur.

În primul caz, dacă este achiziționat un server „alb”, acest lucru va necesita costuri semnificative, precum și respectarea tuturor condițiilor dezvoltatorului sau vânzătorului. Puteți, desigur, să achiziționați un server „gri”, dar nu există nicio garanție că acesta nu va fi inclus în bazele de date de spam motoarele de căutare. Acest lucru este plin doar de faptul că, atunci când Yandex primește scrisori de la sursele specificate, pur și simplu le va filtra și le va trimite la secțiunea de spam, în timp ce Mail.Ru și Google marchează corespondența cu indexul „spam” corespunzător. Configurarea manuală a unui server SMTP pare atât mai fiabilă, cât și mai economică în ceea ce privește costurile financiare.

Mai întâi trebuie să cumpărați Server VPS cu versiunea sistemului de operare Centos nu mai mică de versiunea șase. Acordați atenție imediat dacă este posibil să introduceți o înregistrare PTR, care vă va permite să identificați cu exactitate numele de domeniu canonic de către serverul de primire.

Apoi, trebuie să instalați panoul Vesta. Ca exemplu, folosim utilitarul PuTTY, care trebuie descărcat, instalat și lansat. În setări, introducem imediat adresa IP a serverului, apoi facem clic pe butonul Deschide și introducem numele de utilizator root și parola furnizate la achiziționarea serverului VPS.

Acum introduceți secvențial următoarele comenzi:

curl -O http://vestacp.com/pub/vst-install.sh

bash vst-install.sh

Dacă apare o eroare, o rezolvăm folosind combinația:

bash vst-install-rhel.sh --force

După aceea, introduceți o adresă validă caseta de e-mailși numele gazdei. După 5-10 minute panoul va fi instalat.

https://serverIP:8083

Apare o fereastră în care trebuie să introduceți numele de utilizator root și parola furnizată.

În etapa următoare, înregistrați domeniul și mergeți la panoul de setări DNS, unde schimbăm A.

Așteptăm ca zonele DNS să fie actualizate și mergem la fila WEB din panoul Vesta, unde adăugăm domeniul înregistrat.

După aceasta, înregistrați conturile SMTP în secțiunea Mail. Pentru a verifica în aceeași secțiune pe care o folosim Deschide fila Webmail. În fereastra serverului EXIM care apare, introduceți parametrii SMTP-ului creat și trimiteți o scrisoare de test. Dacă totul este bine, te poți felicita.

Vă rugăm să rețineți că, în unele cazuri, trimiterea în masă poate necesita o semnătură digitală (a nu se confunda cu o înregistrare PTR, care este responsabilă doar de autenticitatea domeniului sau gazdei). Dacă este absent, unele servicii de primire pot fi neîncrezători în corespondență, iar corespondența primită în sine va fi marcată ca îndoielnică. Deci, trebuie să aveți grijă de acest lucru în avans.

În loc de postfață

Rămâne de adăugat că configurarea unui server SMTP pentru clienții de e-mail nu este atât de dificilă pe cât ar părea la început. Dar pentru corespondențe în masă Va trebui să lucrați din greu la setări, așa cum se spune. Și puteți folosi nu numai opțiunea care a fost prezentată mai sus. Unii dezvoltatori oferă deja sisteme automate pentru crearea și configurarea unor astfel de servere la o taxă foarte rezonabilă (sau chiar gratuită).

Și alți agenți de redirecționare a mesajelor folosesc SMTP pentru a trimite și a primi mesaje e-mail, rulând la nivelul clientului utilizatorului aplicații de e-mail de obicei, utilizați SMTP numai pentru a trimite mesaje către un server de e-mail pentru retransmitere. Aplicațiile client folosesc de obicei fie POP pentru a primi mesaje. Protocolul Oficiului Poștal- protocol oficiu poștal), sau IMAP (ing. Internet Message Access Protocol ), sau sisteme proprietare (cum ar fi Microsoft Exchange și Lotus Notes/Domino) de accesat cont cutia ta poștală de pe server.

Poveste

În anii 1960 au fost folosite diferite tipuri comunicatii electronice. Oamenii au comunicat între ei folosind sisteme concepute pentru anumite computere mainframe. Când totul mai multe calculatoare au devenit interconectate, în special în rețeaua guvernului SUA, ARPANET, au fost dezvoltate standarde astfel încât utilizatorii de pe diferite sisteme să poată scrie mesaje electronice între ei. Aceste standarde, dezvoltate în anii 1970, au devenit baza pentru SMTP.

Rădăcinile SMTP pot fi urmărite până la două implementări descrise în 1971 - Mail Box Protocol și SNDMSG, care a fost „inventat” de Ray Tomlinson de la BBN Technologies pentru calculatoarele TOPS-20/TENEX care trimiteau mesaje prin ARPANET (la acea vreme erau conectat la mai puțin de 50 de gazde).

Alte implementări includ FTP Mail and Mail Protocol, dezvoltat în 1973. Dezvoltarea a continuat de-a lungul anilor 1970 până când ARPANET a evoluat în Internetul modern în jurul anului 1980. În același an, Jon Postel a propus Mail Transport Protocol, datorită căruia FTP a încetat să mai fie baza pentru trimiterea corespondenței. SMTP a fost publicat în RFC 821 (scris și de Postel) în august 1982.

Standardul SMTP a fost dezvoltat cam în același timp cu Usenet, o rețea de date cu unele asemănări cu SMTP. SMTP a intrat în uz pe scară largă la începutul anilor 1980. La acea vreme, era un add-on pentru programul de corespondență bazat pe Unix Unix Copy Program (UUCP), care era mai potrivit pentru gestionarea transmisiilor. e-mailuriîntre dispozitivele conectate periodic. Pe de altă parte, SMTP funcționează excelent atunci când atât dispozitivele de expediere, cât și cele de recepție sunt conectate în mod constant la rețea. Ambele dispozitive folosesc un mecanism de stocare și redirecționare și sunt exemple de tehnologie push. Deși grupurile de știri Usenet sunt încă distribuite între servere folosind UUCP, e-mailul UUCP a dispărut efectiv împreună cu „calea bang” (secvența de gazde din rețea pe care ar trebui să o ia un mesaj pentru a ajunge la destinație), care au fost folosite ca antete de rutare. Articolul despre Sender Rewrite oferă informații tehnice de bază despre istoria SMTP-ului timpuriu și a rutării sursei înainte de RFC 1123.

Deoarece acest protocol avea inițial o interfață text (ASCII), nu a funcționat bine cu fișiere binare și caractere din multe limbi non-engleze. Standarde precum Multifunctional Poștă Internet Extensiile (MIME) au fost dezvoltate pentru codare fișiere binare pentru transfer prin SMTP. Agenții de expediere dezvoltați după Sendmail au implementat de obicei și o opțiune pură de 8 biți, astfel încât o strategie alternativă „trimite opt” ar putea fi utilizată pentru a transfera date text arbitrare (în orice codificare de caractere asemănătoare ASCII de opt biți) prin SMTP. Cu toate acestea, a existat încă problema krakozyabr, cauzată de diferite afișări de seturi de caractere între producători, deși adresele poștale în sine permiteau încă utilizarea exclusiv a ASCII. Astăzi, redirecționarea pură pe 8 biți acceptă de obicei extensia 8BITMIME, permițând transferul fișierelor binare aproape la fel de ușor ca textul simplu. Recent, extensia SMTPUTF8 a fost creată pentru a suporta text codificat UTF-8, făcând posibilă includerea de conținut și adrese internaționale folosind alfabete precum chirilic sau chineză.

Mulți oameni de seamă au contribuit la specificația de bază SMTP, inclusiv Jon Postel, Eric Allman, Dave Crocker, Ned Fried, Randall Jellens, Jon Klensin și Keith Moore.

Model de procesare a corespondenței

E-mailul este trimis de un client de e-mail (MUA, agent de utilizator de e-mail) către un server de e-mail (MSA, agent de trimitere a e-mailului) folosind SMTP pe portul TCP 587. De acolo, MSA livrează e-mail-ul agenților săi de transfer de mesaje (MTA). agent de transfer). Adesea, acești doi agenți sunt pur și simplu instanțe diferite ale aceluiași software care rulează cu setări diferite pe același dispozitiv. Prelucrarea locală poate fi efectuată fie pe o mașină separată, fie împărțită între ele diverse dispozitive; în primul caz, procesele implicate au acces general la fișiere, în al doilea caz SMTP este folosit pentru a redirecționa mesajul intern, fiecare gazdă fiind configurată să folosească următorul dispozitiv ca gazdă intermediară. Fiecare proces este un MTA în sine, adică un server SMTP.

MTA-ul edge trebuie să găsească gazda țintă. Utilizează sistemul de nume de domeniu (DNS) pentru a căuta înregistrările de schimb de e-mail (MX) ale domeniului destinatarului (partea adresei din dreapta simbolului @). Înregistrarea MX de e-mail returnată conține numele gazdei țintă. MTA se conectează apoi la serverul de schimb ca client SMTP.

Odată ce ținta MX acceptă mesaj primit, îl transmite agentului de livrare a e-mailului (MDA) pentru livrarea locală a mesajului. MDA oferă posibilitatea de a salva mesaje în formatul corespunzător de cutie poștală. Recepția e-mailului, din nou, poate fi efectuată fie de mai multe, fie de un singur computer - imaginea arată cele mai apropiate două cutii poștale pentru fiecare caz. MDA poate livra mesaje direct în stocare sau le poate transmite prin rețea folosind SMTP sau orice alte mijloace, inclusiv Local Mail Protocolul de transfer- LMTP) - un derivat al SMTP, destinat acestui scop.

Odată livrat la serverul de e-mail local, mesajul este stocat pentru căutarea în lot împotriva clienților de e-mail autentificat (MUA). Mesajul este preluat de aplicațiile utilizatorului final (clienți de e-mail) folosind Internet Message Access Protocol (IMAP, care facilitează accesul la mesaje și gestionează e-mailurile stocate) sau folosind Post Office Protocol (POP), care utilizează de obicei fișierul mbox tradițional format sau sisteme de marcă precum Microsoft Exchange/Outlook sau Lotus Notes/Domino. Clienții de corespondență de rețea pot folosi oricare dintre metode, dar protocolul de căutare adesea nu este conform standardelor oficiale.

SMTP determină transmiterea unui mesaj, nu conținutul acestuia. Astfel, specifică ambalajul mesajului și parametrii acestuia (cum ar fi expeditorul wrapper-ului), dar nu antetul sau corpul mesajului în sine. STD 10 și RFC 5321 definesc SMTP (wrapper), în timp ce STD 11 și RFC 5322 definesc mesajul (header și body), denumit oficial Internet Message Format.

Prezentare generală a protocolului

SMTP este un protocol text bazat pe conexiune în care expeditorul unui mesaj comunică cu destinatarul emitând linii de comandă și primind datele necesare printr-un canal de încredere, care este de obicei o conexiune TCP (Transmission Control Protocol). O sesiune SMTP constă din comenzi trimise de clientul SMTP și răspunsuri corespunzătoare de la serverul SMTP. Când o sesiune este deschisă, serverul și clientul își schimbă parametrii. O sesiune poate include zero sau mai multe operațiuni SMTP (tranzacții).

O operație SMTP constă din trei secvențe de comandă/răspuns (vezi exemplul de mai jos). Descrierea secvențelor:

• POSTA DE LA- setează adresa de retur (adică Return-Path, 53121.From, mfrom). Aceasta este adresa pentru scrisorile returnate.

• RCPT TO- stabilește destinatarul a acestui mesaj. Această comandă poate fi dată de mai multe ori, o dată pentru fiecare destinatar. Aceste adrese fac, de asemenea, parte din shell.

• DATE- pentru a trimite textul mesajului. Acesta este conținutul scrisorii în sine, spre deosebire de plicul ei. Acesta constă dintr-un antet de mesaj și un corp de mesaj separate printr-o linie goală. DATA este în esență un grup de comenzi, iar serverul răspunde de două ori: mai întâi la comanda DATA în sine, pentru a indica faptul că este gata să accepte text; și a doua oară după sfârșitul secvenței de date pentru a accepta sau a respinge întreaga scrisoare.

În plus față de răspunsurile intermediare pentru comanda DATA, fiecare răspuns de server poate fi pozitiv (cod de răspuns 2xx) sau negativ. Acestea din urmă, la rândul lor, pot fi permanente (cod 5xx) sau temporare (cod 4xx). Eșecul serverului SMTP de a transmite un mesaj este o eroare permanentă; în acest caz clientul trebuie să trimită o scrisoare de retur. După o resetare - un răspuns pozitiv, cel mai probabil mesajul va fi respins. Serverul poate indica, de asemenea, că sunt așteptate date suplimentare de la client (cod 3xx).

Gazda inițială (clientul SMTP) poate fi fie clientul de e-mail al utilizatorului final (definit funcțional ca agent de e-mail - MUA), fie un agent de transfer de mesaje (MTA) pe server, de exemplu. serverul acționează ca un client în sesiunea corespunzătoare pentru a transmite mesajul. Serverele complet funcționale acceptă cozi de mesaje pentru a retransmite mesajele în caz de erori.

MUA cunoaște serverul SMTP pentru e-mailurile trimise din setările sale. Serverul SMTP, acționând ca un client, adică redirecționând mesaje, determină la ce server să se conecteze, analizând înregistrările DNS MX (Mail eXchange) de resurse pentru domeniul fiecărui destinatar. În cazul în care înregistrarea MX nu este găsită, MTA-urile compatibile (nu toate) revin la o înregistrare A simplă. Serverele de redirecționare pot fi, de asemenea, configurate să utilizeze o gazdă inteligentă.

Serverul SMTP, acționând ca un client, stabilește o conexiune TCP la server pe portul 25 proiectat de SMTP. MUA trebuie să folosească portul 587 pentru a se conecta la agentul de furnizare a mesajelor (MSA). Principala diferență dintre MTA și MSA este că autentificarea SMTP este necesară doar pentru cel din urmă.

SMTP și preluarea mesajelor

SMTP este doar un protocol de livrare. Nu poate prelua mesaje de la un server la distanță la cerere. Alte protocoale, cum ar fi POP și IMAP, au fost dezvoltate pentru preluarea e-mailurilor și gestionarea cutiei poștale. Cu toate acestea, SMTP oferă posibilitatea de a porni coada de mesaje pe un server la distanță, astfel încât sistemul solicitant să poată primi toate mesajele direcționate către acesta (consultați Pornirea listei de mesaje la distanță de mai jos). POP și IMAP sunt preferate atunci când computerul utilizatorului nu este pornit constant sau este conectat temporar la Internet.

Începe coada de mesaje de la distanță

Pornirea cozii de mesaje de la distanță este o caracteristică a SMTP care permite unei gazde la distanță să înceapă procesarea unei cozi de mesaje pe server, astfel încât să poată primi mesaje destinate acestuia folosind comanda TURN. Cu toate acestea, această caracteristică a fost considerată nesigură și a fost extinsă în RFC 1985 prin comanda ETRN, care funcționează mai sigur datorită metodei de autentificare bazată pe informații DNS.

Releu de corespondență la cerere

ODMR (On-Demand Mail Relay) este o extensie SMTP standardizată în RFC 2645 care permite transmiterea mesajelor către un utilizator autentificat.

Internaționalizarea

Mulți utilizatori al căror set de caractere diferă de alfabetul latin se confruntă cu cerința unei adrese de e-mail în latină. Pentru a rezolva această problemă, a fost creat RFC 6531, oferind capabilități de internaționalizare pentru SMTP - o extensie la SMTPUTF8. RFC 6531 oferă suport pentru multiocteți și caractere non-ASCII V adresa postala, de exemplu: δοκιμή@παράδειγμα.δοκιμή sau 测试@测试.测试. Suportul actual este limitat, dar există un mare interes pentru adoptarea pe scară largă a RFC 6531 și a RFC-urilor aferente în țări cu baze mari de utilizatori pentru care latină nu este un alfabet nativ.

Server SMTP de e-mail de ieșire

Clientul de e-mail trebuie să cunoască adresa IP a serverului SMTP, care este setată ca parte a configurației (de obicei sub forma unui nume DNS). Serverul va livra mesajele trimise în numele utilizatorului.

Restricții privind accesul la serverul de e-mail de ieșire

Administratorii serverului trebuie să controleze ce clienți pot folosi serverul. Acest lucru le permite să combată abuzurile precum spam-ul. Două soluții sunt utilizate în mod obișnuit:

• În trecut, multe sisteme impuneau restricții privind locația clientului, permițând utilizarea doar de către cei a căror adresă IP se număra printre cele controlate de administratori.
• Serverele moderne oferă de obicei un sistem alternativ care necesită autentificarea clienților pentru a obține acces.

Restricționați accesul în funcție de locație

În acest caz, serverul SMTP al ISP-ului nu va permite accesul utilizatorilor „în afara” rețelei furnizorului. Mai exact, serverul poate admite doar acei utilizatori a căror adresă IP este furnizată de un anumit ISP, ceea ce echivalează cu necesitatea unei conexiuni la Internet prin acel ISP. Un utilizator mobil se poate găsi adesea într-o altă rețea decât furnizorul său și, prin urmare, mesajele nu vor fi trimise.

Acest sistem are mai multe varietăți. De exemplu, serverul SMTP al unei organizații ar putea permite accesul numai utilizatorilor din aceeași rețea, blocând alți utilizatori. Serverul poate efectua, de asemenea, o serie de verificări asupra adresei IP a clientului. Aceste metode au fost utilizate în mod obișnuit de organizații și instituții, cum ar fi universități, pentru utilizarea serverelor interne. Cu toate acestea, majoritatea dintre ei folosesc acum metodele de autentificare descrise mai jos.

Datorită restricțiilor de acces anumite adrese, administratorii serverului pot determina cu ușurință adresa oricărui atacator. Dacă un utilizator poate folosi diferiți ISP pentru a se conecta la Internet, acest tip de restricție devine nepractic, iar modificarea adresei serverului SMTP de e-mail de ieșire configurată nu este practic. Este foarte de dorit să se poată utiliza informații de configurare a clientului care nu trebuie modificate.

Autentificarea clientului

În loc de restricția de locație descrisă mai devreme, serverele SMTP moderne necesită de obicei autentificarea utilizatorului înainte de a obține acces. Acest sistem, fiind mai flexibil, suportă utilizatorii de telefonie mobilăși le oferă o alegere fixă ​​de server de e-mail de ieșire configurat.

Deschide Rayleigh

Un server care este accesibil unei rețele extinse și nu oferă aceste tipuri de restricții de acces se numește un releu deschis. Acum, astfel de servere sunt considerate în formă proastă.

Porturi

Administratorii serverului aleg ce port vor folosi clienții pentru a retransmite mesajele de ieșire - 25 sau 587. Specificațiile și multe servere acceptă ambele porturi. Deși unele servere acceptă portul 465 pentru SMTP securizat, este de preferat să folosiți porturi standard și comenzi ESMTP dacă este necesară o sesiune securizată între client și server.

Unele servere sunt configurate să respingă toate releele de pe portul 25, dar utilizatorii autentificați pe portul 587 au voie să trimită mesaje la orice adresă validă.

Unii ISP-uri interceptează portul 25, redirecționând traficul către propriul lor server SMTP, indiferent de adresa de destinație. Astfel, utilizatorii lor nu pot accesa serverul în afara rețelei furnizorului pe portul 25.

Unele servere acceptă acces autentificat pe un alt port suplimentar decât 25, permițând utilizatorilor să se conecteze la ele chiar dacă portul 25 este blocat.

Un exemplu de sesiune SMTP simplă

C: - client, S: - server