Călătoria unui e-mail

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

Obiectiv de învățare: După această lecție veți putea descrie pas cu pas cum ajunge un e-mail de la expeditor la destinatar și, la fiecare pas, să precizați ce program sau ce server efectuează lucrul.

Noțiuni cheie: program de e-mail (MUA), server de trimitere (MSA, submission), server de poștă (MTA), înregistrare MX, coadă de așteptare, livrare (MDA), căsuță poștală, descărcare (IMAP/POP3), envelope, capete de mesaj

E-mailul este poștă, nu un mesaj de chat

Dacă trimiteți un mesaj de chat, acesta trece printr-o singură companie: aplicația expeditorului și aplicația destinatarului vorbesc cu aceleași servere. E-mailul funcționează altfel. Expeditorul și destinatarul pot avea fiecare un alt furnizor: unul la o companie de hosting, altul la Gmail, un al treilea la Microsoft 365 sau pe serverul propriei companii. Și totuși e-mailul ajunge la destinație. Acest lucru este posibil deoarece toate serverele de poștă din lume respectă aceleași convenții.

E-mailul se poate compara foarte bine cu poșta clasică. Scrieți o scrisoare (mesajul), o puneți într-un plic cu o adresă (envelope), o duceți la cutia poștală (serverul de trimitere), compania poștală stabilește unde se află adresa (căutarea MX), transportă scrisoarea la centrul de sortare potrivit (serverul de poștă al destinatarului) iar acesta o pune în cutia poștală a destinatarului (căsuța poștală). Destinatarul o ridică de acolo când îi convine.

Etapele, în ordine

Să presupunem că Anna trimite un e-mail de la anna@example.com către jan@example.net. Iată ce se întâmplă:

La furnizorii mici, MSA, MTA și MDA sunt adesea unul și același program pe un singur server. La furnizorii mari, acestea sunt clustere separate. Pentru dumneavoastră, acest lucru contează mai puțin: sunt roluri, nu aparate fizice distincte.

Observați diferența dintre pasul 1 și pasul 4. Ambele folosesc SMTP, Simple Mail Transfer Protocol (RFC 5321). Dar la pasul 1 vă autentificați și folosiți portul 587 sau 465; acest lucru se numește submission (RFC 6409). La pasul 4, două servere comunică între ele pe portul 25, fără autentificare: serverul de recepție acceptă mesaje pentru propriile domenii, indiferent de la cine provin. În lecția 1.4 veți vedea de ce există această separare.

Pasul 3 în detaliu: căutarea MX

Serverul de trimitere nu știe din proprie inițiativă unde primește example.net mesajele sale. Îl întreabă pe DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Cel mai mic număr are prioritate. Serverul încearcă mai întâi mx1, iar dacă acesta nu răspunde, încearcă mx2. Apoi interoghează adresa IP a acestui nume (înregistrare A sau AAAA) și se conectează.

Două cazuri speciale pe care le întâlniți în practică:

• Nicio înregistrare MX. Atunci expeditorul încearcă înregistrarea A sau AAAA a domeniului propriu-zis ("MX-ul implicit" din RFC 5321, paragraful 5.1). Aceasta este o rămășiță din trecut și nu funcționează în mod fiabil; fiecare domeniu care primește mesaje ar trebui să aibă o înregistrare MX.
• Un MX nul: 0 . Aceasta înseamnă: "acest domeniu nu primește niciodată mesaje" (RFC 7505). Domeniul example.com are unul dintre acestea. Un expeditor renunță imediat și trimite un mesaj de eroare, în loc să continue să încerce zile întregi.

Despre modul exact de funcționare a înregistrărilor MX și a priorităților citiți în lecția 4.1 din cursul de DNS.

Coada de așteptare: e-mailul poate dura puțin

Un mesaj nu ajunge întotdeauna în mai puțin de o secundă. Dacă serverul de recepție nu răspunde, sau spune "încercați din nou mai târziu" (un cod care începe cu 4), mesajul rămâne în coada de așteptare a serverului de trimitere. Acesta încearcă din nou mai târziu, de fiecare dată cu un interval ceva mai mare între încercări. RFC 5321 (paragraful 4.5.4.1) recomandă cel puțin 30 de minute între încercări și renunțarea abia după 4 până la 5 zile. Multe servere trimit deja după câteva ore o avertizare ("delayed", încă nelivrat) iar după câteva zile mesajul de eroare definitiv.

Acesta este un punct forte al e-mailului: dacă un server de poștă este nefuncțional timp de o oră, niciun mesaj nu se pierde. Este și motivul pentru care un mesaj ajunge uneori abia după câteva ore. În modulul 6 veți vedea cum recunoașteți o astfel de întârziere.

Envelope și capete de mesaj: două adrese

La fel ca la poșta clasică, un mesaj are două tipuri de adrese:

• Envelope-ul. Acestea sunt adresele pe care serverele le folosesc între ele în cadrul conversației SMTP: MAIL FROM (expeditorul pentru mesajele de eroare, vizibil ulterior ca Return-Path) și RCPT TO (destinatarul). Serverele livrează pe baza envelope-ului.
• Capetele de mesaj (headers). Acestea reprezintă ceea ce se află în scrisoarea propriu-zisă: From:, To:, Cc:, Subject:, Date:. Programul dumneavoastră de e-mail le afișează.

De obicei acestea coincid, dar nu întotdeauna. Un destinatar în BCC apare în envelope, dar nu în capetele de mesaj; de aceea ceilalți nu îl văd. Un serviciu de newsletter își plasează propria adresă ca expeditor în envelope, astfel încât mesajele de eroare ajung la serviciu, în timp ce în From: apare adresa dumneavoastră. Iar un escroc poate scrie în From: orice dorește.

De ce contează acest lucru: SPF verifică expeditorul din envelope, utilizatorul vede From:. De aceea există DMARC, care leagă aceste două elemente (modulul 4).

Unde poate apărea o problemă

Cu această imagine de ansamblu puteți întreba, pentru orice problemă: la ce etapă apare greșeala?

• Trimiterea nu reușește (eroare imediat în programul dumneavoastră): pasul 1 sau 2. Aproape întotdeauna sunt setări: port, autentificare, parolă (modulul 2).
• Primiți un mesaj bounce: pasul 4 sau 5. Serverul de recepție a refuzat mesajul, sau adresa nu există (modulul 6).
• Mesajul ajunge, dar în folderul de spam: pasul 5. Destinatarul nu are încredere în mesaj (modulele 4 și 5).
• Destinatarul nu vede nimic, iar dumneavoastră nu primiți nicio eroare: mesajul se poate afla încă într-o coadă de așteptare, sau a fost filtrat silențios la destinatar. Aici ajută jurnalele (logs) serverului de trimitere (modulul 6).
• Mesajele nu ajung deloc pentru domeniul dumneavoastră: pasul 3. Înregistrările MX nu sunt corecte, de exemplu după o mutare (modulul 8).

În practică: cum arată la un pachet de hosting

La un pachet de hosting WebOké, un singur server pe pachet îndeplinește toate rolurile: programul dumneavoastră de e-mail predă mesajul pe acel server (pasul 1 și 2), serverul îl trimite mai departe (pasul 3 și 4) și primește mesaje pentru domeniul dumneavoastră (pasul 5). În DirectAdmin puteți folosi E-mail Tracking pentru a vedea, pentru fiecare mesaj, dacă a fost livrat. La alți furnizori funcționează similar; acolo o astfel de funcție se numește, de exemplu, "urmărire mesaje" sau "mail log".

Rezumat

• Un mesaj trece de la programul dumneavoastră de e-mail (MUA) prin serverul de trimitere (MSA/MTA) către serverul de recepție (MTA/MDA) și de acolo la programul de e-mail al destinatarului.
• Trimiterea din programul dumneavoastră este SMTP-submission cu autentificare (587/465); serverele comunică între ele prin SMTP pe portul 25; descărcarea se face prin IMAP sau POP3.
• Serverul de trimitere caută înregistrările MX ale domeniului de după @. Un MX nul (0 .) înseamnă: acest domeniu nu primește mesaje.
• Un mesaj care nu poate fi livrat imediat rămâne în coada de așteptare și este reîncercat timp de câteva zile.
• Envelope (Return-Path) și capetele de mesaj (From) sunt doi expeditori diferiți. SPF verifică primul, utilizatorul vede al doilea.

Quiz

Exercițiu

Exercițiu Z1.1: Găsirea primului server de e-mail. Căutați înregistrările MX ale gmail.com (sau ale propriului dumneavoastră domeniu). Completați care server este încercat primul, cu numărul său de prioritate, și o adresă IP (IPv4 sau IPv6) a acelui server. Programul interoghează aceleași date în timp real și le verifică.

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
• Manual DirectAdmin 8.7: IMAP sau POP3: care este diferența?
• Curs gratuit de DNS 4.1: Înregistrări MX și prioritate
• RFC 5321 (SMTP), paragraful 5.1 (MX și MX implicit) și 4.5.4.1 (reîncercare); RFC 7505 (MX nul)