Cum investighezi problema înainte să începi să modifici lucruri.
Scrii mesajul.
Atașezi documentul.
Apeși Send.
Ajunge.
Cel puțin aceasta este teoria.
În practică, uneori apeși Send, Outlook mută frumos mesajul în Sent, serverul tău pare perfect mulțumit de situație, iar după câteva minute primești un telefon:
„Nu am primit nimic.”
Verifici adresa.
Este corectă.
Mai trimiți o dată.
Tot nimic.
Și începe unul dintre jocurile clasice din IT:
La cine este problema?
Cazul #1: „Trebuie să vă actualizați DKIM”
Recent am primit un mesaj de la un partener:
„Mailurile de la dumneavoastră sunt blocate de către IT. Ni s-a spus că trebuie să vă actualizați DKIM records.”
Excelent.
Avem problema.
Avem cauza.
Avem chiar și soluția.
Mai lipsește doar butonul mare pe care scrie:
REPARĂ DKIM
Din păcate, butonul acela nu există.
Și, mai important, faptul că cineva ți-a trimis un diagnostic nu înseamnă automat că diagnosticul este corect.
Poate fi.
Dar trebuie verificat.
Așa că am verificat configurația DKIM și informațiile legate de modul în care trimiteam emailurile.
Apoi am transmis informațiile tehnice către departamentul IT al companiei respective pentru ca ei să poată continua investigația și din partea lor.
Ulterior, mailurile au început să ajungă.
Mi-ar plăcea să pot încheia povestea spunând:
„Am găsit problema. Am reparat DKIM. Case closed.”
Doar că nu asta pot demonstra.
Nu știu exact ce au modificat cei de la celălalt capăt.
Știu doar atât:
mailurile erau blocate → am verificat partea noastră → am transmis informațiile către IT-ul destinatarului → ulterior mailurile au început să ajungă.
Și asta este o distincție importantă.
Pentru că în troubleshooting există o diferență între:
„cred că asta este problema”
și
„am dovezi că asta este problema.”
La scurt timp după aceea am avut ocazia să văd și varianta a doua.
Cazul #2: Yahoo nu mai sugerează. Yahoo îți spune direct.
Un alt domeniu trimitea emailuri.
Către anumite adrese mesajele ajungeau.
Apoi s-a încercat trimiterea către Yahoo.
Yahoo a răspuns, în esență:
Nu.
De data aceasta însă aveam ceva foarte valoros:
un mesaj de eroare.
Iar serverul Yahoo nu era deloc misterios în privința motivului.
Mesajul spunea că expeditorul nu era autentificat corespunzător și oferea rezultatele verificărilor:
DKIM = FAILURE
SPF = FAILURE
Asta este o situație complet diferită.
Nu mai avem:
„IT-ul nostru crede că poate este DKIM.”
Avem serverul care a refuzat mesajul spunând:
„Am verificat aceste lucruri și au eșuat.”
Acum avem un punct real de plecare.
Și acesta este motivul pentru care mesajele de eroare sunt atât de importante.
Pot părea niște paragrafe scrise de două servere care se ceartă într-o limbă inventată special ca oamenii să nu o înțeleagă.
Dar, uneori, acolo este exact răspunsul de care ai nevoie.
Bun. Dar ce sunt SPF, DKIM și DMARC?
Pentru utilizator, un email este simplu:
De la: Andrei
Către: Client
Problema este că internetul nu poate spune:
„Scrie Andrei acolo. Pare un băiat de treabă. Îl credem.”
Oricine poate încerca să trimită un mesaj pretinzând că este altcineva.
Așa că serverele de mail încearcă să verifice identitatea expeditorului.
Și aici apar trei acronime care fac conversațiile despre email să devină brusc mult mai puțin distractive:
SPF, DKIM și DMARC.
Nu trebuie să fii administrator de mail ca să înțelegi ideea din spatele lor.
SPF: „Ai voie să trimiți în numele firmei?”
Imaginează-ți că la recepția unei clădiri apare cineva și spune:
„Sunt de la firma de mentenanță.”
Recepționerul verifică lista.
Dacă persoana este pe listă, foarte bine.
Dacă nu este…
probabil nu îi dai cheia de la camera serverelor doar pentru că pare foarte convingător.
SPF face ceva asemănător.
Domeniul spune ce sisteme sunt autorizate să trimită email în numele lui.
Serverul destinatarului poate verifica dacă mesajul vine printr-un sistem autorizat.
Simplificat:
„Ai voie să trimiți mail pentru domeniul acesta?”
DKIM: „Mesajul are semnătura potrivită?”
DKIM adaugă o semnătură digitală mesajului.
Serverul care îl primește poate verifica dacă acea semnătură este validă folosind informațiile publicate de domeniul expeditorului.
În termeni umani:
„Mesajul acesta chiar poartă o semnătură pe care o pot verifica?”
Nu este exact o semnătură cu pixul, evident.
Ar fi destul de dificil să convingem serverul să țină pixul.
Dar principiul este asemănător.
DMARC: „Și dacă lucrurile nu se potrivesc?”
DMARC leagă aceste mecanisme de identitatea domeniului pe care utilizatorul o vede în câmpul From și permite domeniului să publice o politică pentru mesajele care nu se autentifică sau nu se aliniază corespunzător.
Foarte simplificat:
„Dacă cineva pretinde că este mine, dar verificările nu se potrivesc, iată cum vreau să tratezi mesajul.”
Și mai oferă ceva foarte util: posibilitatea de a primi informații despre cine încearcă să trimită email folosind domeniul tău.
Aici lucrurile devin mai complicate decât par
Într-o companie nu trimite mail doar Outlook.
Poate trimite website-ul.
Poate trimite CRM-ul.
Poate trimite aplicația de facturare.
Poate trimite newsletter-ul.
Poate trimite multifuncționala.
Poate trimite un server.
Și, inevitabil, poate exista un serviciu configurat acum șapte ani de cineva care nu mai lucrează în companie și despre care toată lumea află exact în ziua în care nu mai funcționează.
Toate acestea pot folosi domeniul firmei.
De aceea:
„Configurăm SPF, DKIM și DMARC”
nu înseamnă neapărat trei bife și gata.
Trebuie să știi cine trimite email în numele domeniului tău.
Dacă SPF, DKIM și DMARC sunt corecte, mailul ajunge sigur?
Nu.
Ar fi prea simplu.
Autentificarea corectă nu înseamnă automat:
WELCOME TO INBOX.
Serverul destinatarului poate analiza și reputația expeditorului, conținutul mesajului, linkurile, atașamentele, volumul de email și propriile politici de securitate.
De aceea poți avea situația aparent absurdă în care:
mailul ajunge la Gmail;
ajunge la Microsoft;
ajunge la alți clienți;
dar la o anumită companie nu ajunge.
Și atunci fiecare parte spune propoziția tradițională:
„La noi merge.”
„Sent” nu înseamnă „Delivered”
O altă confuzie foarte comună apare când utilizatorul deschide folderul Sent.
„Uite. Apare aici. Deci a plecat.”
Da.
Dar există o diferență între:
„Am predat coletul curierului.”
și:
„Destinatarul are coletul pe birou.”
Faptul că mesajul apare în Sent nu demonstrează că a ajuns în Inbox-ul destinatarului.
Între cele două se pot întâmpla multe.
Mesajul poate fi respins.
Poate fi acceptat și filtrat.
Poate ajunge în spam.
Poate ajunge în carantină.
Poate fi blocat de o politică internă.
De aceea, când investighez o problemă de mail, mă interesează mai mult:
Ce spune serverul?
Există un mesaj de eroare?
Mesajul a fost acceptat?
A fost respins?
Care este motivul?
Aici diferența dintre cele două cazuri devine foarte clară.
În primul caz aveam diagnosticul transmis de o altă echipă IT.
În al doilea aveam serverul Yahoo spunând explicit:
SPF FAILURE. DKIM FAILURE.
Una este o ipoteză.
Cealaltă este o dovadă tehnică pe care poți începe să construiești investigația.
Nu repara înainte să verifici
Poate cea mai utilă regulă din toată povestea este foarte simplă:
Nu începe să modifici lucruri doar pentru că primul diagnostic sună suficient de tehnic.
„Este DKIM.”
Poate.
Verifică.
„Este firewall-ul.”
Poate.
Verifică.
„Este de la Microsoft.”
Posibil.
Verifică.
Pentru că există ceva mai rău decât să ai o configurație greșită:
să ai o configurație corectă și să o strici încercând să repari problema greșită.
AI-ul este foarte bun la tradus „limba serverelor”
Aici AI-ul poate fi extrem de util.
Ia un mesaj precum:
550 5.7.9 authentication failure… DKIM FAILURE… SPF FAILURE…
Pentru cineva care nu lucrează cu mail servere, arată ca o combinație între matematică și amenințare.
Un AI poate ajuta rapid la structurarea informației:
Ce spune eroarea?
Cine a respins mesajul?
Ce verificare a eșuat?
Ce trebuie verificat mai departe?
Este mult mai eficient decât să cauți fiecare bucată din eroare separat.
Dar aceeași regulă rămâne valabilă.
AI-ul poate interpreta dovada.
Nu ar trebui să inventeze dovada.
Emailul funcționează tocmai pentru că nu are încredere în tine
SPF, DKIM și DMARC par inutile cât timp mailul funcționează.
La fel ca mare parte din infrastructura IT.
Dar ele există pentru că internetul trebuie să rezolve o problemă fundamentală:
oricine poate pretinde că este altcineva.
Așa că serverele încearcă să răspundă la câteva întrebări:
Ai voie să trimiți pentru domeniul acesta?
Mesajul are o semnătură validă?
Identitatea folosită se potrivește cu mecanismele de autentificare?
Ce politică a publicat domeniul pentru mesajele care nu trec verificările?
Nu trebuie să memorezi toate acronimele ca utilizator.
Dar dacă administrezi emailul unei companii, trebuie să înțelegi ce încearcă ele să demonstreze.
Pentru că atunci când cineva spune:
„Mailurile voastre nu ajung.”
prima întrebare nu ar trebui să fie:
„Ce schimbăm?”
Ci:
„Ce dovezi avem?”
În primul nostru caz, am verificat și am transmis informațiile mai departe.
În al doilea, serverul Yahoo ne-a spus foarte clar ce verificări au eșuat.
Două probleme aparent identice:
„Mailul nu ajunge.”
Două niveluri complet diferite de informație.
Și exact de aici începe troubleshooting-ul.