Îmbunătățirea securității e-mailurilor: Stop Sender Fraud with SPF, DKIM, and DMARC

Nu există niciun fel de filtrare a adevărului: trebuie să protejați e-mailul companiei dumneavoastră.

În 2013, mai mult de 100 de miliarde de e-mailuri de afaceri au fost trimise și primite în fiecare zi. Doar unul din cinci dintre toate e-mailurile trimise în 2013 a fost legitim, iar 92% dintre toate e-mailurile nelegitime au inclus linkuri către conținut potențial malițios.

Există totuși semne de îmbunătățire; această lună este prima din ultimii 12 ani în care mai puțin de jumătate dintre e-mailurile clienților Symantec au fost spam.

Puteți mulțumi celor trei standarde de securitate a e-mailurilor (și altor inițiative) pentru reducerea numărului de spam: SPF, DKIM și DMARC. Cu toate acestea, riscurile de securitate sunt prevalente. Mi s-a spus recent o poveste despre un director financiar care a fost supus unei tentative de phishing. Încercarea a eșuat, dar dacă ar fi reușit, ar fi costat organizația 50.000 de dolari.

În ceea ce privește aceste standarde de e-mail, există încă o mare confuzie în jurul lor. Sper să pot oferi o oarecare claritate cu această postare, precum și să vă conduc prin modul de implementare a SPF, DKIM și DMARC.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, sau SPF, este bătrânul de la petrecerea de autentificare a e-mailurilor. SPF este un standard deschis care specifică o metodă de prevenire a falsificării adreselor expeditorului, potrivit openspf.org. Nu este vorba despre oprirea spam-ului; este vorba despre controlul și oprirea încercărilor de falsificare a expeditorului.

SPF vă permite să identificați sursele legitime de e-mail ale domeniului dvs. și împiedică sursele neautorizate să trimită mii – sau chiar milioane – de e-mailuri ilicite de pe domeniul dvs.

Există patru tipuri de abuzuri de e-mail asociate în mod obișnuit cu falsificarea expeditorului de e-mail:

• Spam (e-mailuri nesolicitate în masă & e-mailuri comerciale nesolicitate)
• Fraude (escrocherii 419)
• Malware (adware, zero days, viruși, troieni, etc.)
• Phisheri (spear-phishing)

Nu doriți ca domeniul organizației dvs. să fie asociat cu niciuna dintre acestea din motive evidente. SPF vă va ajuta să vă asigurați că mesajele de poștă electronică ale organizației dvs. provin de fapt de la dvs.

DomainKeys Identified Mail (RFC 6376, înlocuiește RFC 4871 și RFC 5672, care sunt acum depășite)

DKIM, sau DomainKeys Identified Mail, este o înregistrare TXT publicată în sistemul de nume de domeniu (DNS). Implică ceva ce toți administratorii IT ar trebui să învețe să iubească: chei – chei publice, mai exact.

Înainte de a ne scufunda în DKIM, este important să înțelegem ce sunt cheile și cum funcționează acestea. Cheile, în acest caz, criptografia cu chei publice, constă dintr-o cheie publică (cunoscută de toată lumea) și una privată (denumită adesea secretă). Cheile publice și private sunt legate matematic una de cealaltă, făcând posibilă comunicarea securizată pe canale publice.

Aceste chei sunt ca un sigiliu inviolabil pe un plic transparent. Nu ascundeți neapărat mesajul; doar autentificați cu o certitudine de 100% atât expeditorul, cât și mesajul.

Acum, să revenim la DKIM.

„Din punct de vedere tehnic, DKIM oferă o metodă de validare a identității unui nume de domeniu care este asociat cu un mesaj prin autentificare criptografică”, conform dkim.org. Cu alte cuvinte, DKIM folosește chei pentru a se asigura că un expeditor de e-mail este cine spune că este.

Cu DKIM, sunt generate perechi de chei publice și private pentru a menține autentificarea serverelor de e-mail și a comunicațiilor. Fiecare server SMTP (Simple Mail Transfer Protocol) de ieșire are nevoie de cheia privată și de prefixul corect pentru a se potrivi cu o înregistrare DNS publică pe care serverul de poștă electronică destinatar o verifică apoi.

Te-ai întrebat vreodată de ce apare pictograma de blocare în Gmail atunci când primești mesaje de la eBay, Paypal sau banca ta? Aceasta este DKIM și un pic de DMARC (pe care îl vom aborda în scurt timp). Mai jos, mailed-by arată corespondența SPF, iar signed-by arată corespondența DKIM. DKIM și DMARC nu sunt încă esențiale, dar, la fel ca și IPv6, trec rapid de la laboratorul de testare la mai bine-avut.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, sau Domain-based Message Authentication, Reporting, and Conformance, ajută expeditorii și destinatarii să colaboreze pentru a crea comunicații prin e-mail mai sigure. DMARC a fost creat de un grup de organizații pentru a limita abuzurile bazate pe e-mail „prin rezolvarea câtorva probleme operaționale, de implementare și de raportare de lungă durată legate de protocoalele de autentificare a e-mailurilor”, conform dmarc.org.

DMARC permite expeditorului mesajului să indice faptul că mesajele sale sunt protejate cu SPF și/sau DKIM. O politică DMARC aplică instrucțiuni clare pe care destinatarul mesajului trebuie să le urmeze în cazul în care un e-mail nu trece de autentificarea SPF sau DKIM – de exemplu, să-l respingă sau să-l trimită la gunoi.

De asemenea, DMARC trimite un raport către expeditor cu privire la mesajele care TRECUTĂ și/sau EȘUEVĂ evaluarea DMARC.

Cum să implementați SPF, DKIM și DMARC

Acum că avem o mai bună înțelegere a fiecăruia dintre aceste trei standarde (și de ce sunt importante), haideți să aruncăm o privire la modul în care vă puteți îmbunătăți securitatea e-mailurilor prin implementarea lor.

Nota: De dragul acestei prezentări pas cu pas, să pretindem că sunteți șeful IT de la 301 Moved, o mică firmă de design web care folosește Google Apps.

Recent, ați avut unele probleme cu roboții de spam ruși. Utilizatorii dvs. finali s-au plâns că au primit notificări de respingere a e-mailurilor de la adrese pe care nu le-au văzut sau la care nu au trimis niciodată mesaje. Vă dați seama că cineva trimite în mod clar e-mailuri frauduloase de pe domeniul dumneavoastră.

Atunci cum îi opriți?

Nota: Am inclus formatul standard BIND în text simplu și o captură de ecran a modului în care arată înregistrarea în GoDaddy DNS. În GoDaddy, toate înregistrările pentru domeniul de nivel superior 301Moved.com folosesc gazda „@”, gazda dvs. va fi probabil diferită. În scopul acestui exercițiu, voi discuta doar despre corespondența de ieșire, nu despre modul în care tratăm aceste standarde în legătură cu corespondența de intrare de la expeditori externi.

Implementarea SPF

Primul pas: Ghidul Google pentru configurarea înregistrărilor SPF pentru a funcționa cu Google Apps este un bun punct de plecare. Urmând aceste instrucțiuni, adăugăm o nouă înregistrare TXT la DNS-ul nostru public.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved folosește, de asemenea, Zendesk, un sistem de ticketing care trimite e-mailuri direct din domeniul dvs. Trebuie să vă asigurați că nici de acolo nu se trimite spam.

Pasul doi: Găsiți și adăugați înregistrarea SPF a lui Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Este important să rețineți că nu adăugăm o a doua înregistrare SPF, care va strica lucrurile; în schimb, le combinăm într-o singură înregistrare, făcându-le mai lungi pe măsură ce sunt adăugați mai mulți expeditori.

Rețineți: Puteți adăuga doar o singură înregistrare SPF per domeniu sau subdomeniu.

Știți, de asemenea, că 301 Moved are un gateway de e-mail vechi în incintă care gestionează unele lucruri vechi, așa că să adăugăm și blocul lor IP. 301 Moved folosește mecanismul „IP4” pentru a defini blocul IP pe care îl deține-198.51.100.0/24 (192.51.100.0-254).

Utilizați Dmarcian’s SPF Surveyor pentru a vă vizualiza înregistrările SPF.

Pasul trei: Adăugați adrese IPv4 unice pe cont propriu și blocuri de rețea în notația Classless Inter-Domain Routing (CIDR). 198.51.100.0 pentru o singură adresă IP (nu aveți nevoie de un /32) și 198.51.100.0/24 pentru subrețele.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Adăugarea vechii pasarele de e-mail se va asigura că e-mailurile ieșite din pasarelă vor fi autorizate SPF.

Mecanismele de mai sus sunt cele mai frecvent utilizate, dar există opt în total – inclusiv cele ciudate și depreciate. Aceste mecanisme definesc doar domeniul de aplicare al potrivirii, nu și acțiunile în sine.

Calificatorii din secțiunea următoare reprezintă locul unde pot fi definite acțiunile PASS, SOFTFAIL și FAIL – o potrivire ar duce la declanșarea uneia dintre cele trei acțiuni (PASS, SOFTFAIL și FAIL).

• ALL: Se potrivește tot ceea ce nu este deja definit de un alt mecanism se va potrivi cu mecanismul all
• A: Dacă numele de domeniu are o înregistrare de adresă (A sau AAAA) care poate fi rezolvată la adresa expeditorului, se va potrivi.
• IP4: Dacă expeditorul se află într-un anumit interval de adrese IPv4, se va potrivi.
• IP6: Dacă expeditorul se află într-un anumit interval de adrese IPv6, se va potrivi.
• IP6: Dacă expeditorul se află într-un anumit interval de adrese IPv6, se va potrivi.
• MX: Dacă numele de domeniu are o înregistrare MX care se rezolvă la adresa expeditorului, se va potrivi (adică poșta electronică provine de la unul dintre serverele de poștă electronică de intrare ale domeniului).
• PTR: Dacă numele de domeniu (înregistrare PTR) pentru adresa clientului se află în domeniul dat și acel nume de domeniu se rezolvă la adresa clientului (DNS inversat cu confirmare directă), se va potrivi. Acest mecanism este depreciat și nu ar trebui să mai fie utilizat.
• EXISTS: Dacă numele de domeniu dat se rezolvă la orice adresă, acesta se va potrivi (indiferent de adresa la care se rezolvă). Acest lucru este rar utilizat. Împreună cu limbajul macro SPF, oferă potriviri mai complexe, cum ar fi DNSBL-queries.
• INCLUDE: Dacă politica inclusă (un termen impropriu) trece testul, acest mecanism se potrivește. Acesta este utilizat în mod obișnuit pentru a include politicile mai multor ISP.

În continuare sunt calificativele. Există un milion de moduri de a le combina cu un model de listă neagră și/sau de listă albă, dar pentru scopurile noastre aici, vom include doar cele trei mecanisme de căutare pe care le-am menționat mai sus cu un singur calificativ la sfârșit pentru a face o listă albă. Cei patru calificatori ai noștri sunt:

• + pentru un rezultat PASS. Acesta poate fi omis; de exemplu, +mx este același lucru cu mx.
• ? pentru un rezultat NEUTRAL interpretat ca NONE (fără politică).
• ~ (tilde) pentru SOFTFAIL, un ajutor de depanare între NEUTRAL și FAIL. De obicei, mesajele care returnează un SOFTFAIL sunt acceptate, dar etichetate.
• – (minus) pentru FAIL, poșta trebuie respinsă (vezi mai jos).

Pasul patru: Aplicați politica SOFTFAIL.

Pentru moment, 301 Moved folosește tilda pentru SOFTFAIL. Prin utilizarea tildei, toate e-mailurile care nu corespund Google, Zendesk sau blocului IP menționat vor fi SOFTFAIL. Mailul va fi în continuare livrat, dar va fi probabil trimis în dosarul Spam sau Junk. Totuși, acest lucru depinde în întregime de serverul de e-mail al destinatarului. Nu este definit de niciun standard.

A „-” (minus) în această situație ar FALIMENTA (și, probabil, ar respinge în întregime corespondența care nu se potrivește. Puteți activa acest lucru odată ce începeți să obțineți mai multă vizibilitate în corespondența dvs. de ieșire (așteptați DMARC) și odată ce vă simțiți mai confortabil cu infrastructura dvs. de poștă electronică.

SPF este grozav pentru că nu există nicio modificare a serverelor de poștă electronică în sine. Antetele rămân aceleași. Doar o simplă înregistrare TXT (tipul de înregistrare SPF propriu-zisă, dedicată, nu a fost niciodată atât de populară și este acum depreciată) și puteți instrui majoritatea serverelor de poștă electronică din lume care ar trebui să vă afișeze numele.

La sfârșitul zilei, serverul SMTP destinatar verifică IP-ul expeditorului în raport cu înregistrarea dvs. SPF pe care a interogat-o, apoi aplică politica pe baza instrucțiunilor dvs. Cu alte cuvinte, vă autorizați pe dvs. și pe furnizorii dvs. să trimiteți e-mailuri (în mare parte) de încredere, deoarece publicați o listă de control al accesului (ACL) pentru public.

Cu toate acestea, mesajele pot fi totuși modificate în tranzit, iar falsificatorii și phisherii vicleni se pot strecura în jurul SPF în unele moduri interesante (poate un subiect pentru o altă zi). Este SMTP: TLS de la un capăt la altul nu este garantat, așa că trebuie să presupunem întotdeauna că este vorba de cleartext. Mesajele pot fi manipulate sau falsificate.

Dar intrați în scenă la dreapta…

Implementarea DomainKeys Identified Mail

Când se trimite un e-mail, 301Moved.com semnează (fără a cripta) e-mailul cu cheia privată. De acum înainte, orice modificare a mesajului, inclusiv a corpului, a antetelor sau a atașamentelor, va rupe semnătura și va face mesajul invalid. Din nou, ne uităm la Google, folosind articolul lor Autentificați e-mailul cu DKIM

Pasul cinci: Adăugați cheia publică la înregistrarea dvs. DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Care înregistrare DKIM are un prefix selector unic, ceea ce înseamnă că putem publica mai multe. În loc să le combinăm într-o singură înregistrare, așa cum am făcut cu SPF, puteți folosi selectori unici și să publicați atâtea chei publice câte aveți nevoie. Acest lucru ne permite să adăugăm un număr mare de servere autorizate DKIM fără limite superioare.

Vă veți da seama că prefixul de mai sus este „google”, valoarea implicită pe care Google Apps o folosește atunci când generează o înregistrare DKIM pe care să o publicați. Puteți schimba acest lucru în Google, precum și în majoritatea celorlalte configurații, așa că, dacă ați dorit prefixul „dkimawesome”, nimic nu vă oprește.

Câțiva furnizori de cloud fac acest lucru diferit. În loc să genereze perechi de chei unice pentru fiecare chiriaș cloud, ei semnează toate e-mailurile de ieșire pentru toate domeniile cu aceeași cheie – în timp ce vă pun să publicați în schimb un nume canonic (CNAME) pentru cheia lor.

Zendesk face acest lucru, noi CNAME două chei diferite pe DNS-ul nostru către DNS-ul lor. Zendesk are un articol de ajutor excelent- Semnarea digitală a e-mailurilor cu DKIM sau DMARC (Plus și Enterprise)

Pasul șase (dacă este cazul): CNAME cheile de pe DNS-ul dumneavoastră către DNS-ul lor. Orice interogare DNS care caută zendesk1._domainkey.301Moved.com va fi redirecționată de către DNS-ul dvs. către zendesk1._domainkey.zendesk.com. Zendesk servește apoi cheile DKIM în mod direct.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Potem vedea cum arată acest lucru pentru alte servere folosind instrumentul nslookup (pentru Unix sau Windows) la nivel local.

Nu toți expeditorii ieșeni acceptă DKIM. Evident, Google Apps o face, dar este posibil ca serverele dvs. de poștă electronică tradiționale să nu o facă.

Implementarea Autentificării, raportării și conformității mesajelor bazate pe domeniu

DMARC, sau Domain-based Message Authentication, Reporting, and Conformance (Autentificare, raportare și conformitate a mesajelor bazate pe domeniu), este ultimul instrument pe care îl avem la dispoziție pentru a combate e-mailurile malițioase. Pentru serverele de poștă care ascultă, DMARC, retransmite cum să trateze SPF și DKIM, precum și cum să vă raporteze, oferindu-vă vizibilitatea atât de necesară în ceea ce privește ratele de livrare și conformitatea înregistrărilor.

Și da, DMARC este o altă înregistrare TXT.

Pasul șapte: Configurați o politică DMARC, identificați adresa mailto, configurați modul de aliniere și identificați procentul de mesaje cărora ar trebui să li se aplice politica (nu vă faceți griji, este mai simplu decât pare).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Politica de mai sus este desemnată ca p=none. Deocamdată nu modificăm deloc fluxul de corespondență – pur și simplu configurăm politica și raportarea sa relevantă. Adresa la care vor fi trimise rapoartele XML ale stării DMARC este desemnată cu rua=.

Serverele de poștă electronică receptoare vor trimite atașamente XML care arată modul în care mesajele de la – și cele care pretind a fi de la – domeniul dvs. au fost comparate cu mănușa SPF, DKIM și DMARC pe care o impun majoritatea serverelor de poștă electronică moderne.

Aceste rapoarte arată, pentru fiecare plic în parte, dacă SPF a trecut, a eșuat sau a fost softfailed. Acestea arată dacă DKIM a eșuat, a eșuat alinierea sau a reușit – și cum au fost aplicate politicile de mai sus.

În cele din urmă, aceste rapoarte arată dispoziția finală de livrare a mesajului. Există câteva instrumente excelente care vă pot ajuta să le analizați. Chiar dacă nu aplicați politici mesajelor, este ca în cazul jurnalelor de firewall, DNS și IDS/IPS – este întotdeauna bine să aveți ceva la care să vă puteți întoarce și să vă uitați.

Adkim=r specifică modul de aliniere DKIM relaxat, „r” este pentru relaxat și „s” pentru strict. Modul relaxat permite domeniilor DKIM d= autentificate în cadrul unui domeniu organizațional comun în antetul de mail-From: să treacă verificarea DMARC. Modul strict necesită o potrivire perfectă între domeniul DKIM d= și adresa antet-From a unui e-mail. Gândiți-vă la subdomenii, dacă le folosiți.

aspf=r face exact același lucru, cu excepția verificărilor SPF.

Pct=100 este procentul de mesaje care sunt tratate efectiv conform politicii DKIM. Ales la întâmplare, serverul de poștă electronică destinatar va aplica politica la acest procent de mesaje de la domeniul dumneavoastră. Deocamdată folosim 100 pentru că nu aplicăm o politică, încă.

Înainte de a aplica o politică, vom reduce această valoare la cinci, astfel încât doar unul din 20 de mesaje să aibă politica aplicată, deoarece transformăm indicatorul de politică p= în carantină sau respingere. În acest fel, dacă o dăm complet în bară, 95% din e-mailurile noastre vor fi totuși livrate, în loc de 0% livrate dacă am fi început la pct=100.

Mesajele care nu trec de verificarea DMARC, sau de modurile de aliniere adkim= și aspf= pe care le-am setat mai sus, sunt apoi redirecționate în mod soft, ca mai sus, pentru o politică de carantină, sau redirecționate în întregime atunci când sunt setate pe reject.

Este foarte important să rețineți că DMARC va aproba mesajul dacă fie SPF, fie DKIM trece, și va respinge mesajul doar dacă atât SPF, cât și DKIM nu trec. În acest fel, mesajele doar cu SPF și și doar cu DKIM pot trece DMARC, dar mesajele fără SPF/DKIM vor fi întotdeauna FAIL. Aceasta este o veste grozavă dacă aveți sisteme de poștă electronică care suportă numai SPF sau numai DKIM.

Utilizați DMARC Inspector DMARC al lui Dmarcian pentru a verifica și vizualiza înregistrările DMARC.

Dmarcian este un instrument plătit care vă permite să vă gestionați cu ușurință rapoartele DMARC, există multe altele, dar se întâmplă ca Dmarcian să fie preferatul meu.

Update: Am primit câteva e-mailuri (compatibile cu DMARC!) care ne-au întrebat despre politica de subdomeniu sp=none. Cu o politică care include sp=none nu specificați o politică DMARC pentru niciun subdomeniu. Acest lucru se face manual prin configurarea unei înregistrări DMARC corespunzătoare pentru fiecare subdomeniu specific sau inclusă în înregistrarea DMARC principală cu un sp=quarantine sau sp=reject.

Configurare minimă

Dacă doriți să încercați acest lucru, vă recomand să începeți foarte deschis și să rămâneți simplu până când aveți suficiente rapoarte DMARC pentru a începe să impuneți ceva.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Definiți furnizorii mari cu un „include:” și orice blocuri IP de la care puteți trimite e-mailuri cu un „IP4 „sau „IP6”. Folosiți „MX” pentru a vă autoriza serverele de e-mail de intrare. Și, cu excepția cazului în care trimiteți e-mail direct din aceeași cutie/server care vă găzduiește site-ul web (apropo, o practică proastă, proastă), puteți sări peste mecanismul „A” menționat mai sus. „?” nu aplică nicio politică mesajelor dumneavoastră, dar face ca înregistrarea dumneavoastră SPF să fie disponibilă, astfel încât DMARC să o poată recunoaște.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Obțineți selectorul corect, „google” în acest caz, și cheia corectă. Țineți minte, puteți publica mai mult de una.

Nota: Vă rugăm să nu publicați această cheie reală sau voi putea să vă semnez DKIM mailurile.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Pentru DMARC, nu avem nicio politică aplicată, suntem în modul relaxat, dar cerem ca rapoartele XML să fie trimise către o căsuță poștală pe care o putem accesa. De aici, DMARC ne oferă un feedback destul de rapid (nu în timp real) cu privire la modul în care putem înăspri diferitele politici din toate cele trei înregistrări.

Dar stați, cum rămâne cu TLS?

Transport Layer Security, sau TLS, nu face parte din standardul DMARC și nu este o înregistrare DNS.

În schimb, TLS este doar un Secure Socket Layer (SSL) maturizat pe care serverele de poștă electronică îl pot folosi pentru a trimite mesaje între ele prin conexiuni publice. Este SMTP învelit în TLS, la fel cum puteți face multe alte lucruri în interiorul/pe TLS-SNMP pe TLS și FTP pe TLS fiind exemple comune. TLS criptează mesajele doar în tranzit, nu și în repaus.

Dacă trimitem un mesaj semnat DKIM prin TLS, acesta este semnat pe toată durata sa de viață, dar este criptat doar în timp ce trece de la Google Apps la Cisco Ironport sau oriunde tranzitează corespondența. TLS mai mult ca sigur că nu protejează mesajele în repaus, deși este, de asemenea, utilizat pentru sesiunea HTTPS:// către webmail în timp ce citiți același mesaj, dar, din nou, acesta este în tranzit.

TLS este ceva ce ar trebui să folosiți ori de câte ori este posibil, dar, de asemenea, să fiți pregătiți să vorbiți în clar cu alte sisteme publice de poștă electronică. Chiar și în 2015, unele servere de poștă electronică nu suportă STARTTLS (limbajul serverelor pentru a începe handshake-ul TLS).

Puteți impune utilizarea TLS cu anumite domenii externe în Google Apps cu o simplă modificare de configurare. Este un lucru bun de activat pentru afacerile externe asociate, partenerii și alte organizații, dar impuneți TLS numai după ce sunteți sigur că este fiabil și că este suportat de toate serverele de poștă electronică de pe acel domeniu specific.

Importanța securității e-mailurilor și evitarea fraudei expeditorului

Dacă sunteți un administrator IT veteran sau sunteți la început de drum, aceste trei standarde au aceeași importanță. Desigur, ceea ce face fiecare dintre ele și modul în care funcționează împreună poate deveni un pic aglomerat, dar implementarea lor este relativ simplă – iar beneficiile merită timpul dumneavoastră.

.