Porturi, criptare și autentificare

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

Obiectivul lecției: După această lecție veți putea spune pentru fiecare port de e-mail la ce folosește, veți putea explica diferența dintre STARTTLS și TLS direct și veți putea explica o notificare de certificat sau o autentificare refuzată.

Noțiuni esențiale: portul 25, 587, 465, 993, 995, 143, 110, STARTTLS, TLS direct (implicit TLS, RFC 8314), certificat, nume de server, autentificare SMTP (SMTP AUTH), open relay, blocarea portului 25, parolă de aplicație, OAuth

Un port este o ușă

Un server are o singură adresă IP, dar multe uși. Fiecare serviciu ascultă pe propriul său port, un număr. Browserul dumneavoastră web bate la ușa portului 443, programul dumneavoastră de e-mail la portul 993 pentru a citi mesaje și la 587 sau 465 pentru a le trimite. Dacă alegeți ușa greșită, nimeni nu răspunde sau răspunde cineva care vorbește o altă limbă. Acest lucru generează mesaje de eroare vagi precum "nu se poate stabili conexiunea" sau "serverul nu răspunde".

Porturile de e-mail, pe rând:

De ce nu folosim pur și simplu portul 25 pentru trimitere?

Odinioară configurați portul 25 în programul dumneavoastră de e-mail. Acest lucru a devenit de domeniul trecutului din două motive.

În primul rând: pe portul 25, un server de e-mail acceptă mesaje de la oricine, pentru domeniile sale proprii. Nu se face nicio autentificare. Un server care, pe portul 25, redirecționează și mesaje de la oricine către alte domenii se numește open relay, și acesta este exploatat de spammeri în câteva ore. De aceea, trimiterea propriilor mesaje către întreaga lume a devenit un serviciu separat: submission, pe portul 587 (și 465), unde vă autentificați întotdeauna mai întâi.

În al doilea rând: mulți furnizori de internet blochează traficul ieșit către portul 25 de pe conexiunile de acasă. Astfel, un calculator infectat dintr-o locuință nu poate trimite spam direct către serverele de e-mail. Consecința pentru dumneavoastră: dacă încercați să trimiteți din programul dumneavoastră de e-mail prin portul 25, este posibil să nu funcționeze acasă, dar să funcționeze la birou, sau invers.

Rețineți: programele de e-mail trimit prin 587 sau 465, cu autentificare. Portul 25 este pentru comunicarea între servere.

STARTTLS sau TLS direct?

Există două moduri de a cripta o conexiune de e-mail.

TLS direct (implicit TLS): conexiunea este criptată încă de la primul octet, la fel ca un site web cu https. Acest lucru se întâmplă pe 465, 993 și 995.

STARTTLS: conexiunea începe necriptată. Serverul spune "pot cripta", clientul răspunde STARTTLS, iar din acel moment totul este criptat. Acest lucru se întâmplă pe 587 (și pe 25, 143 și 110).

Pentru securitate contează puțin, atât timp cât programul dumneavoastră impune STARTTLS în mod obligatoriu. Riscul STARTTLS se află la început: cineva aflat între dumneavoastră și server poate elimina oferta "pot cripta". Un program care apoi continuă în tăcere necriptat trimite parola dumneavoastră lizibilă pe linie. De aceea, RFC 8314 (2018) recomandă pentru programele de e-mail TLS direct (465, 993, 995) în locul STARTTLS. În practică, atât 587 cu STARTTLS, cât și 465 cu SSL/TLS sunt bune, dacă setați criptarea în programul dumneavoastră pe "obligatorie" și nu pe "dacă este disponibilă".

O greșeală frecventă este combinația greșită: portul 587 cu "SSL/TLS", sau portul 465 cu "STARTTLS". Programul se așteaptă atunci la altceva decât face serverul, iar conexiunea rămâne blocată sau eșuează. Rețineți perechile: 587 + STARTTLS și 465 + SSL/TLS. Programele numesc uneori TLS direct "SSL", "SSL/TLS" sau "TLS"; STARTTLS este uneori numit tot "TLS". Așadar, uitați-vă la port.

Certificatul și numele serverului

La fiecare conexiune criptată, serverul prezintă un certificat, care demonstrează că este cine pretinde că este. Programul dumneavoastră de e-mail verifică două lucruri: dacă certificatul a fost emis de o parte de încredere și dacă este încă valabil, și dacă numele pe care l-ați completat ca server apare în el.

Acest ultim aspect este cel mai des sursa problemelor. Dacă introduceți mail.example.com, dar în certificat apare doar server12.hosting.example, primiți o notificare precum "Nu se poate verifica identitatea serverului" sau "Numele principal al destinației este incorect". Conexiunea în sine este totuși criptată, dar programul dumneavoastră nu poate fi sigur că vorbește cu serverul autentic.

Nu ignorați o astfel de notificare făcând clic pentru a o închide. Soluția este un nume de server care apare efectiv în certificat (consultați lecția 2.1). La un server partajat, acesta este adesea numele serverului propriu-zis, pe care furnizorul dumneavoastră vi-l indică. O altă cauză cunoscută: un antivirus care "scanează" mesajele criptate și introduce propriul certificat în acest scop. În notificare apare atunci numele scanerului la "emis de".

Autentificarea la trimitere

Pe 587 și 465 trebuie să vă autentificați înainte ca serverul să vă trimită mesajele către exterior. Acest lucru se numește autentificare SMTP (SMTP AUTH). În programul dumneavoastră, opțiunea se numește "serverul de ieșire necesită autentificare", "autentificarea este necesară" sau "autentificare: parolă normală". De obicei folosiți același nume de utilizator și aceeași parolă ca pentru IMAP.

Dacă autentificarea este dezactivată sau numele de utilizator pentru serverul de ieșire a rămas necompletat, puteți citi mesaje, dar nu le puteți trimite. Serverul răspunde atunci cu ceva de genul 530 5.7.0 Authentication required sau 554 5.7.1 Relay access denied. Acesta este cel mai frecvent motiv pentru "primirea funcționează, trimiterea nu".

Un al doilea tip de refuz: 535 5.7.8 Authentication failed. Atunci combinația de nume de utilizator și parolă este greșită. Atenție: după un anumit număr de încercări eșuate, multe servere blochează adresa IP de unde provin aceste încercări, pentru a preveni ghicirea parolelor. Un telefon vechi cu o parolă veche poate astfel determina blocarea întregului dumneavoastră birou.

Parole de aplicație și OAuth

La furnizori mari precum Google și Microsoft, autentificarea folosind doar parola dumneavoastră obișnuită într-un program de e-mail separat funcționează din ce în ce mai rar. Aceștia folosesc OAuth: programul dumneavoastră vă trimite către o pagină de autentificare a furnizorului, vă autentificați acolo (eventual cu autentificare în doi pași), iar programul primește o cheie în locul parolei dumneavoastră. Programele care nu pot face acest lucru primesc uneori o parolă de aplicație: o parolă separată, lungă, valabilă doar pentru acel program și pe care o puteți revoca separat.

La o căsuță poștală obișnuită de la o companie de găzduire, de obicei vă autentificați cu parola căsuței poștale propriu-zise. Acest lucru face ca o parolă puternică și unică să fie cu atât mai importantă (lecția 3.4).

În practică: setările unei căsuțe poștale

La o căsuță poștală de la WebOké, setările sunt: IMAP 993 cu SSL/TLS, POP3 995 cu SSL/TLS, trimitere 587 cu STARTTLS sau 465 cu SSL/TLS, autentificare activată cu adresa dumneavoastră de e-mail completă și parola căsuței poștale. La alți furnizori funcționează similar: porturile sunt aproape peste tot aceleași, doar numele serverului diferă. Ce nume de server alegeți, aflați în lecția 2.1.

Rezumat

• Programele de e-mail trimit prin 587 (STARTTLS) sau 465 (TLS direct), întotdeauna cu autentificare. Portul 25 este pentru comunicarea între servere și este adesea blocat acasă.
• Citirea se face prin 993 (IMAP) sau 995 (POP3), ambele cu TLS direct.
• Combinați corect: 587 + STARTTLS, 465 + SSL/TLS. Setați criptarea pe obligatorie.
• O notificare de certificat înseamnă de obicei: numele de server pe care l-ați introdus nu apare în certificat. Închiderea notificării nu este o soluție.
• "Citirea funcționează, trimiterea nu" înseamnă aproape întotdeauna: autentificarea pentru serverul de ieșire este dezactivată sau necompletată.

Quiz

Exercițiu

Exercițiu Z1.4: Porturile și certificatul unui server de e-mail. Completați numele serverului de intrare și de ieșire pe care îl folosiți pentru propria dumneavoastră căsuță poștală (dacă nu aveți o căsuță poștală proprie, folosiți imap.gmail.com și smtp.gmail.com). Alegeți pentru portul 993 (intrare) și porturile 465 și 587 (ieșire) ce vă așteptați: TLS direct, STARTTLS sau inaccesibil, și indicați dacă credeți că numele apare în certificat. Programul se conectează singur la cele trei porturi și pune rezultatul alături de răspunsurile dumneavoastră.

Lectură suplimentară

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

• Manual DirectAdmin 8.1: Toate setările la un loc: servere, porturi și securitate
• Manual DirectAdmin 8.8: Trimiterea sau primirea e-mailurilor nu reușește: așa rezolvați problema
• Eroare de certificat la preluarea e-mailurilor
• Nu pot trimite e-mailuri (primirea funcționează)
• RFC 8314 (TLS direct pentru programele de e-mail), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)