Aliasuri, redirecționare și catch-all: utile, dar cu riscuri

Modulul 3: Gestionarea căsuței dvs. de e-mail · Timp de citire: 11 minute

Obiectiv de învățare: După această lecție veți putea alege între o mailbox, un alias, o redirecționare și un catch-all, și veți putea explica de ce redirecționarea către o adresă externă și un catch-all pot afecta livrarea mesajelor dumneavoastră.

Noțiuni-cheie: mailbox, alias, forwarder (redirecționare), redirecționare internă și externă, SPF se întrerupe la redirecționare, SRS (Sender Rewriting Scheme), DKIM la redirecționare, ARC (RFC 8617), catch-all, atac de tip dicționar, backscatter, trimiterea în numele altei adrese

Patru moduri de a face o adresă funcțională

Dacă doriți ca offerte@example.com să funcționeze, aveți patru opțiuni:

În unele panouri, un alias este din punct de vedere tehnic identic cu un forwarder către o adresă de pe același server. Diferența care contează este aceasta: mesajul rămâne pe același server, sau pleacă în exterior?

Redirecționarea în interiorul propriului domeniu: fără probleme

Dacă redirecționați offerte@example.com către info@example.com, iar ambele se află pe același server, serverul livrează pur și simplu mesajul în mailbox-ul info@. Nimic nu trece prin internet, nimic nu este reverificat. Acest lucru este sigur și de încredere.

Redirecționarea către exterior: unde apar problemele

Situația este diferită atunci când redirecționați către o adresă aflată la un alt furnizor, de exemplu o adresă personală la Gmail sau Outlook.com. În acest caz, serverul dumneavoastră trimite din nou mesajul, de data aceasta către Gmail. Iar Gmail verifică mesajul ca și cum ar proveni de pe serverul dumneavoastră.

Să presupunem că klant@example.net trimite un mesaj către info@example.com. Serverul dumneavoastră îl redirecționează către Gmail. Ce vede Gmail?

• Expeditor (From): klant@example.net.
• Expeditorul din plic (envelope sender): tot klant@example.net, cu excepția cazului în care serverul dumneavoastră îl rescrie.
• Server expeditor: serverul dumneavoastră, de exemplu 192.0.2.25.

Gmail verifică înregistrarea SPF a domeniului example.net. Serverul dumneavoastră, bineînțeles, nu apare acolo. SPF eșuează. Dacă example.net are o politică DMARC p=reject, și mesajul nu are o semnătură DKIM validă, atunci Gmail respinge mesajul. Serverul dumneavoastră primește înapoi un bounce, care ajunge la... expeditorul original, care acum primește o eroare de la serverul dumneavoastră.

Există trei mecanisme care atenuează această problemă:

1. DKIM supraviețuiește (de obicei)

O semnătură DKIM (lecția 4.3) se află chiar în mesaj. Dacă serverul dumneavoastră redirecționează mesajul nemodificat, semnătura domeniului example.net rămâne validă. DMARC reușește atunci pe baza DKIM, chiar dacă SPF eșuează. De aceea DKIM este atât de important: este singurul lucru care supraviețuiește redirecționării.

Dar lucrurile merg prost dacă serverul care redirecționează modifică mesajul: adaugă un text la final ("redirecționat de..."), modifică subiectul (adaugă [SPAM] în față) sau convertește formatarea. În acest caz, semnătura nu mai este validă.

2. SRS rescrie expeditorul din plic

Cu SRS (Sender Rewriting Scheme), serverul care redirecționează schimbă expeditorul din plic (envelope sender) într-o adresă de pe propriul domeniu, de exemplu:

SRS0=HHH=TT=example.net=klant@example.com

Acum Gmail verifică înregistrarea SPF a domeniului example.com, unde serverul dumneavoastră chiar apare. SPF reușește. Dacă apare un bounce, serverul dumneavoastră poate retraduce adresa și trimite bounce-ul către expeditorul real.

Atenție: SRS rezolvă SPF, dar nu și DMARC. Alinierea (lecția 4.4) compară domeniul expeditorului din plic cu adresa From. Acum este example.com față de example.net: nealiniate. DMARC trebuie deci în continuare să reușească pe baza DKIM.

3. ARC: o declarație a intermediarului

ARC (Authenticated Received Chain, RFC 8617, experimental) permite unui intermediar să consemneze ce a observat: "atunci când acest mesaj a ajuns la mine, SPF, DKIM și DMARC au reușit". Serverul care redirecționează semnează această declarație. Destinatarul final poate decide să aibă încredere în această declarație dacă are încredere în intermediar. Furnizori mari precum Gmail și Microsoft folosesc ARC, dar nu vă puteți baza pe el: este o favoare, nu un drept.

Și spamul?

Mai există o problemă, și adesea este cea mai mare. Filtrul dumneavoastră de spam nu oprește totul. Tot spamul care trece este acum redirecționat de serverul dumneavoastră către Gmail. Pentru Gmail, pare că serverul dumneavoastră trimite spam. Acest lucru afectează reputația serverului dumneavoastră (iar la găzduirea partajată: a tuturor clienților de pe acel server). Gmail va plasa apoi și mesajele dumneavoastră legitime mai repede în spam.

Ce este mai bine?

Doriți să citiți mesajele dumneavoastră de serviciu în aplicația Gmail sau Outlook? Adăugați mailbox-ul ca și cont IMAP (modulul 2). Aplicația preia mesajele direct de pe serverul dumneavoastră. Nu se redirecționează nimic, nu eșuează nicio verificare și nu pleacă spam spre exterior. Dacă totuși trebuie să redirecționați, configurați filtrul de spam să fie strict înainte de redirecționare.

Catch-all: de ce aproape niciodată

Un catch-all captează toate mesajele către adrese care nu există. O greșeală de tastare precum inof@example.com ajunge atunci totuși la destinație. Sună util, dar:

• Spam. Spammerii trimit masiv mesaje către adrese inventate pe domenii existente (a.jansen@, sales2@, xkq7@). Aceasta se numește un atac de tip dicționar. Fără catch-all, serverul dumneavoastră respinge toate acestea imediat. Cu catch-all, totul ajunge, adesea sute pe zi.
• Nu mai există mesaj de eroare. Cine greșește adresa dumneavoastră nu primește un bounce și crede că mesajul a ajuns. Fără catch-all, acesta știe imediat că adresa este greșită.
• Redirecționarea înrăutățește lucrurile. Un catch-all care redirecționează către Gmail trimite tot acel spam către Gmail.
• Backscatter. Un server care acceptă mai întâi totul și abia mai târziu descoperă că o adresă nu există trimite un bounce către expeditorul (falsificat). Aceasta se numește backscatter: mesaje de eroare trimise unor persoane nevinovate, și un motiv pentru a ajunge pe o listă de blocare.

Doriți să captați câteva adrese suplimentare, cum ar fi o greșeală de tastare frecventă sau o adresă veche? Creați aliasuri sau forwardere separate pentru acestea. Folosiți o adresă proprie pentru fiecare site sau magazin online (webshop-x@), pentru a vedea cine vă revinde adresa? Creați acea adresă ca alias în momentul în care o folosiți.

Trimiterea de pe un alias

Un alias poate fi și un expeditor. De exemplu, doriți să răspundeți ca offerte@example.com în timp ce sunteți autentificat ca info@. Acest lucru este posibil, dar:

• Multe servere de e-mail verifică astăzi ce adresă de expeditor corespunde cu ce login. Puteți trimite atunci doar de pe propria adresă și de pe aliasurile sau forwarderele care indică spre mailbox-ul dumneavoastră. O adresă aleatorie, diferită, va fi respinsă ("account can not send emails from ..."). Acest lucru protejează împotriva abuzurilor.
• În programul dumneavoastră de e-mail, adăugați aliasul ca identitate suplimentară (Thunderbird: Gestionare identități; Apple Mail: adrese suplimentare la cont, separate prin virgule; Outlook: afișarea câmpului From și introducerea adresei).
• SPF, DKIM și DMARC funcționează normal, atâta timp cât aliasul se află pe același domeniu și trimiteți prin propriul server.

În practică: cum arată într-un panou

În DirectAdmin creați redirecționările la E-mail Manager, Forwarders. Catch-all-ul se află la Advanced Features, Catch-All E-mail; acolo "dezactivare catch-all" este poziția recomandată (mesajele către adrese inexistente sunt respinse). Dacă aveți doar un nume de domeniu fără pachet, redirecționările se află în Contul meu WebOké la Domeniile mele, Redirecționări. Alte panouri (cPanel, Plesk, Microsoft 365, Google Workspace) au secțiuni similare, uneori denumite "aliasuri", "redirecționare" sau "grupuri".

Rezumat

• Un alias sau o redirecționare în interiorul aceluiași server este sigură.
• Redirecționarea către exterior întrerupe SPF. SRS repară SPF, dar nu și alinierea DMARC; doar o semnătură DKIM intactă salvează mesajul, iar ARC poate ajuta.
• Spamul redirecționat afectează reputația serverului dumneavoastră. Este de preferat să citiți mesajele externe prin IMAP în aplicație.
• Un catch-all atrage spam, ascunde greșelile de tastare și poate provoca backscatter. Folosiți aliasuri separate.
• Trimiterea de pe un alias este posibilă, în limitele regulilor serverului dumneavoastră.

Quiz

Exercițiu

Exercițiu O3.3: Inventarul adreselor dumneavoastră. Realizați o listă cu toate adresele de pe domeniul dumneavoastră: mailboxuri, aliasuri, redirecționări și dacă este activat un catch-all. Notați la fiecare redirecționare dacă rămâne în interiorul propriului dumneavoastră domeniu sau pleacă spre exterior (Gmail, Outlook.com, o altă companie). Răspundeți apoi: ce redirecționare externă poate fi înlocuită cu un cont IMAP în aplicație, și există un catch-all activat care poate fi dezactivat? Completați lista de verificare.

Lectură suplimentară

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

• Manual DirectAdmin 7.5: Forwarders: redirecționarea e-mailurilor către o altă adresă
• Manual DirectAdmin 7.6: Catch-All E-mail: mesaje către adrese inexistente
• Redirecționarea e-mailurilor către o altă adresă (redirecționări, adresa catch-all nu este recomandată)
• Trimiterea de e-mailuri de pe mai multe aliasuri, eroarea: Account xxx can not send emails from
• Manual WebOké 5.9: Redirecționări de e-mail și de domeniu
• Curs gratuit de DNS 4.3: SPF: cine are voie să trimită e-mailuri în numele domeniului dumneavoastră?
• RFC 8617 (ARC), RFC 7208 anexa D (SPF și intermediari precum serviciile de redirecționare)