SMTP: conversația dintre serverele de e-mail

Modulul 1: Cum funcționează e-mailul · Timp de citire: 10 minute

Obiectiv de învățare: După această lecție veți putea citi o conversație SMTP, veți putea explica ce fac EHLO, MAIL FROM, RCPT TO și DATA și veți putea recunoaște după un cod de răspuns dacă o eroare este temporară sau definitivă.

Noțiuni-cheie: SMTP (RFC 5321), sesiune, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, cod de răspuns (2xx, 3xx, 4xx, 5xx), cod de stare extins, extensii (STARTTLS, AUTH, SIZE), null MX

O conversație în text simplu

SMTP este un protocol foarte vechi (prima versiune datează din 1982) și tocmai de aceea este foarte ușor de citit. Două servere își trimit reciproc rânduri de text. Expeditorul (clientul) trimite o comandă, iar destinatarul (serverul) răspunde cu un număr format din trei cifre și o scurtă explicație. O astfel de conversație poate fi citită literalmente într-un mesaj de eroare sau într-un jurnal, și tocmai de aceea merită să o înțelegeți.

Mai jos găsiți o conversație completă. S: este serverul care primește, C: este serverul care trimite. Mesajul merge de la anna@example.com la jan@example.net.

S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (de aici încolo conexiunea este criptată; clientul retrimite EHLO)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Offerte
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hoi Jan, hierbij de offerte.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

Comenzile, una câte una

Cea mai importantă constatare: tot ce precedă DATA este plicul (envelope), tot ce urmează după DATA este conținutul. Ceea ce apare în MAIL FROM și ceea ce apare în antetul From: sunt furnizate separat și nu trebuie să fie identice. Serverul livrează pe baza RCPT TO; antetul To: din conținut nu joacă niciun rol la livrare.

Codurile de răspuns

Prima cifră a codului este cea mai importantă:

După cele trei cifre, serverele moderne afișează un cod de stare extins sub forma class.subject.detail (RFC 3463), de exemplu 5.1.1. Prima cifră este din nou 2, 4 sau 5. A doua cifră arată despre ce este vorba: 1 = adresă, 2 = mailbox, 3 = sistem de e-mail, 4 = rețea și rutare, 5 = protocol, 6 = conținut, 7 = securitate și politică. Câteva exemple frecvent întâlnite:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (temporar)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (politică: spam, listă de blocare, DMARC)

În modulul 6 veți învăța să citiți un bounce complet și veți găsi un tabel cu codurile cele mai frecvente.

De ce contează atât de mult diferența dintre temporar și definitiv

Un server care are îndoieli răspunde adesea cu un cod 4xx. Un exemplu cunoscut este greylisting: un server care nu cunoaște încă un expeditor spune prima dată „încercați mai târziu”. Un server de e-mail real revine după câteva minute, dar multe programe de spam nu o fac. De asemenea, furnizorii mari folosesc coduri 4xx pentru a reduce ritmul atunci când nu au încă încredere într-o adresă IP. Pentru dumneavoastră, ca expeditor, acest lucru înseamnă: întârziere, dar nu pierdere. Sistemul rezolvă de obicei singur situația.

Un cod 5xx este diferit. În acest caz, expeditorul nu va mai încerca din nou. Dacă primiți un 5xx, cineva trebuie să schimbe ceva: adresa, conținutul sau setările domeniului expeditor.

O capcană: unele servere dau un 5xx chiar dacă problema este temporară (de exemplu, în cazul unei mailbox pline, 552 5.2.2), iar altele dau un 4xx pentru ceva ce nu va reuși niciodată. Prin urmare, citiți întotdeauna textul de după cod, nu doar numărul.

Cine este responsabil?

După ce se primește un 250 la punctul final al DATA, responsabilitatea trece la serverul destinatar. Dacă acesta nu reușește ulterior să plaseze mesajul în mailbox, trebuie să trimită el însuși un mesaj de eroare înapoi. Aceasta este sursa unui fenomen dificil numit backscatter. Un server care preia mai întâi totul și abia ulterior constată că adresa nu există trimite un bounce către expeditorul din plic. Dacă acea adresă a fost falsificată de un spammer, un terț nevinovat primește bounce-ul. Din acest motiv, serverele ar trebui să refuze deja la RCPT TO tot ce nu poate fi livrat (vedeți și catch-all în lecția 3.3).

În practică: SMTP în propriul dumneavoastră mediu

Un utilizator obișnuit vede rareori conversația SMTP în întregime, dar o vede în fragmente:

• într-un bounce apare ultimul rând al conversației, de exemplu Remote-MTA: mx1.mailprovider.example și Diagnostic-Code: smtp; 550 5.1.1 ...;
• în antetele unui mesaj primit apare, pentru fiecare server, un rând Received: cu numele EHLO și adresa IP (lecția 1.5);
• într-un panou cu jurnal de e-mail, precum E-mail Tracking din DirectAdmin la WebOké, vedeți răspunsul serverului destinatar pentru fiecare mesaj. La alți furnizori, un astfel de instrument se numește de exemplu urmărirea mesajelor sau jurnal de e-mail, iar conținutul este similar.

Așadar, nu trebuie să vă conectați personal la un server de e-mail pentru a putea citi aceste informații. Cine dorește totuși să încerce: cu openssl s_client -starttls smtp -connect server:25 puteți purta conversația manual, dar mulți furnizori de internet pentru rețele domestice blochează traficul de ieșire pe portul 25 (lecția 1.4).

Rezumat

• SMTP este o conversație ușor de citit: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Tot ce precedă DATA este plicul (livrare și mesaje de eroare), tot ce urmează este conținutul cu antetele pe care le vedeți.
• 2xx = reușit, 4xx = temporar (se încearcă din nou mai târziu), 5xx = definitiv (bounce).
• Codul extins X.Y.Z arată despre ce este vorba; X.1 adresă, X.2 mailbox, X.7 politică și securitate.
• Citiți întotdeauna textul de după cod; serverele nu sunt întotdeauna consecvente.

Quiz

Exercițiu

Exercițiu Z1.2: Un domeniu care nu primește e-mail. Căutați înregistrările MX ale domeniului example.com. Completați ce ați găsit și alegeți ce face un server expeditor cu un mesaj pentru info@example.com: (a) livrează către serverul cu prioritate 0, (b) încearcă înregistrarea A, (c) renunță imediat sau (d) încearcă din nou mai târziu. Programul verifică în timp real înregistrarea MX și validează răspunsul.

Lecturi suplimentare

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

• Cum funcționează trimiterea e-mailurilor / SMTP
• Livrarea mesajului a eșuat (Mail delivery failed): cum interpretați mesajul de eroare și ce înseamnă codurile
• Manual DirectAdmin 9.3: E-mail Tracking: unde a dispărut mesajul meu?
• RFC 5321 (SMTP), paragraful 3 și 4.2 (coduri de răspuns); RFC 3463 (coduri de stare extinse); RFC 7505 (null MX)