DMARC - DMARC

Acest articol este despre un sistem de validare a e-mailurilor. Pentru punctul de joncțiune de telefonie, consultați punctul de demarcare .
Nu trebuie confundat cu dMarc Broadcasting .

DMARC ( Autentificare, raportare și conformitate a mesajelor bazate pe domeniu ) este un protocol de autentificare prin e-mail . Este conceput pentru a oferi proprietarilor de domenii de e-mail capacitatea de a-și proteja domeniul împotriva utilizării neautorizate, cunoscută în mod obișnuit sub denumirea de falsificare a e-mailurilor . Scopul și rezultatul principal al implementării DMARC este de a proteja un domeniu de a fi utilizat în atacuri de compromis prin e-mail de afaceri , e-mailuri de phishing , escrocherii prin e-mail și alte activități de amenințare cibernetică .

După publicarea intrării DNS DMARC , orice server de e-mail primitor poate autentifica e-mailurile primite pe baza instrucțiunilor publicate de proprietarul domeniului în cadrul intrării DNS. Dacă e-mailul trece autentificarea, acesta va fi livrat și poate fi de încredere. Dacă e-mailul nu reușește verificarea, în funcție de instrucțiunile deținute în înregistrarea DMARC, e-mailul poate fi livrat, pus în carantină sau respins. De exemplu, un serviciu de redirecționare a e-mailului livrează e-mailul, dar ca „De la: fără răspuns @ <serviciu de redirecționare>”.

DMARC extinde două mecanisme existente de autentificare prin e-mail, Sender Policy Framework (SPF) și DomainKeys Identified Mail (DKIM). Permite proprietarului administrativ al unui domeniu să publice o politică în înregistrările lor DNS pentru a specifica ce mecanism (DKIM, SPF sau ambele) este utilizat la trimiterea e-mailului din acel domeniu; cum se verifică From:câmpul prezentat utilizatorilor finali; modul în care receptorul ar trebui să facă față eșecurilor - și un mecanism de raportare pentru acțiunile efectuate în cadrul acestor politici.

DMARC este definit în documentul publicat de Internet Engineering Task Force RFC 7489, din martie 2015, ca „Informațional”.

Prezentare generală

O politică DMARC permite domeniului expeditorului să indice că e-mailurile lor sunt protejate de SPF și / sau DKIM și îi spune unui receptor ce trebuie să facă dacă nu trece niciuna dintre aceste metode de autentificare - cum ar fi să respingă mesajul sau să îl pună în carantină. Politica poate specifica, de asemenea, modul în care un receptor de e-mail poate raporta la domeniul expeditorului despre mesajele care trec și / sau eșuează.

Aceste politici sunt publicate în sistemul public de nume de domeniu (DNS) ca înregistrări text TXT .

DMARC nu abordează direct dacă un e-mail este sau nu spam sau altfel fraudulos. În schimb, DMARC poate solicita ca un mesaj să nu treacă doar validarea DKIM sau SPF, ci să transmită și alinierea . Sub DMARC un mesaj poate eșua chiar dacă trece SPF sau DKIM, dar nu reușește alinierea.

Configurarea DMARC poate îmbunătăți livrabilitatea mesajelor de la expeditori legitimi.

Aliniere

DMARC funcționează verificând dacă domeniul din câmpul mesajului From:(numit și "RFC5322.From") este "aliniat" cu alte nume de domenii autentificate. Dacă verificările de aliniere SPF sau DKIM trec, testul de aliniere DMARC trece.

Alinierea poate fi specificată ca strictă sau relaxată. Pentru alinierea strictă, numele domeniilor trebuie să fie identice. Pentru alinierea relaxată, „Domeniul organizațional” de nivel superior trebuie să se potrivească. Domeniul organizațional se găsește verificând o listă de sufixe DNS publice și adăugând următoarea etichetă DNS. De exemplu, „abcdexample.com.au” și „example.com.au” au același domeniu organizațional, deoarece există un registrator care oferă nume în „.com.au” clienților. Deși la momentul specificațiilor DMARC exista un grup de lucru IETF privind limitele domeniului, în prezent domeniul organizațional poate fi derivat doar din Lista Sufixelor Publice .

La fel ca SPF și DKIM, DMARC folosește conceptul de proprietar de domeniu, entitatea sau entitățile care sunt autorizate să facă modificări la un anumit domeniu DNS.

SPF verifică dacă adresa IP a serverului de trimitere este autorizată de proprietarul domeniului care apare în MAIL FROMcomanda SMTP . (Adresa de e-mail din MAIL FROM se mai numește și adresa bounce , envelope-from sau RFC5321.MailFrom.) În plus față de necesitatea trecerii verificării SPF, DMARC verifică dacă RFC5321.MailFrom se aliniază cu 5322.From.

DKIM permite părților unui mesaj de e-mail să fie semnate criptografic, iar semnătura trebuie să acopere câmpul De la. În cadrul antetului de poștă electronică DKIM-Signature, etichetele d=(domeniu) și s=(selector) specifică unde din DNS se extrage cheia publică pentru semnătură. O semnătură validă dovedește că semnatarul este proprietarul unui domeniu și că câmpul De la nu a fost modificat de la aplicarea semnăturii. Pe un mesaj de e-mail pot exista mai multe semnături DKIM; DMARC necesită o semnătură validă în care domeniul din d=etichetă se aliniază cu domeniul expeditorului menționat în From:câmpul antet.

Înregistrare DNS

Înregistrările DMARC sunt publicate în DNS cu o etichetă de subdomeniu _dmarc, de exemplu _dmarc.example.com. Comparați acest lucru cu SPF la example.comși DKIM la selector._domainkey.example.com.

Conținutul înregistrării resurselor TXT constă din name=valueetichete, separate prin punct și virgulă, asemănător cu SPF și DKIM. De exemplu: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"

Aici veste versiunea, peste politica (vezi mai jos), sppolitica subdomeniului, pctreprezintă procentul de e-mailuri „proaste” pe care să aplicați politica și ruaeste URI-ul pentru a trimite rapoarte agregate. În acest exemplu, entitatea care controlează domeniul DNS example.com intenționează să monitorizeze ratele de eșec SPF și / sau DKIM și nu se așteaptă ca e-mailurile să fie trimise din subdomeniile example.com. Rețineți că un subdomeniu își poate publica propria înregistrare DMARC; destinatarii trebuie să o verifice înainte de a reveni la înregistrarea domeniului organizațional.

Adopție pas cu pas

Protocolul prevede diverse clichete sau stări de tranziție, pentru a permite administratorilor de e-mail să treacă treptat de la neimplementarea DMARC deloc până la o configurare neclintită. Conceptul de adopție treptată presupune că scopul DMARC este cel mai puternic cadru, ceea ce nu este cazul pentru toate domeniile. Indiferent de intenție, aceste mecanisme permit o mai mare flexibilitate.

Politică

În primul rând, există trei politici:

  • niciuna nu este politica de bază. Recepționarii nu necesită tratament special, dar permite unui domeniu să primească rapoarte de feedback.
  • carantina solicită destinatarilor să trateze cu suspiciune mesajele care nu reușesc verificarea DMARC. Receptorii diferiți au mijloace diferite pentru a implementa acest lucru, de exemplu semnalizați mesajele sau le livrați în folderul spam.
  • respinge solicită receptoare pentru a respinge pur și simplu mesaje care nu trece de verificare DMARC.

Politica publicată poate fi atenuată prin aplicarea ei doar la un procent din mesajele care nu reușesc verificarea DMARC. Receptorii sunt rugați să selecteze procentul dat de mesaje printr-un algoritm simplu de eșantionare Bernoulli . Restul mesajelor ar trebui să fie supuse politicii inferioare; adică none if p=quarantine, carantină if p=reject. Dacă nu este specificat, pct implicit la 100% din mesaje. Cazul p=quarantine; pct=0;este folosit pentru a forța managerii listelor de discuții să rescrie câmpul De la: deoarece unii nu o fac atunci când p=none.

În cele din urmă, politica subdomeniului sp=și noua politică fără domeniu adăugată permit modificarea politicii pentru subdomenii specifice.

Rapoarte

DMARC este capabil să producă două tipuri separate de rapoarte. Rapoartele agregate sunt trimise la adresa specificată după rua. Rapoartele criminalistice sunt trimise prin e-mail la adresa care urmează rufetichetei. Aceste adrese de e-mail trebuie specificate în format URI mailto (de exemplu, mailto: lucră[email protected]). Mai multe adrese de raportare sunt valide și trebuie să fie fiecare în format URI complet, separate printr-o virgulă.

Adresele de e-mail vizate pot aparține unor domenii externe. În acest caz, domeniul țintă trebuie să creeze o înregistrare DMARC pentru a spune că este de acord să le primească, altfel ar fi posibil să se exploateze raportarea pentru amplificarea spamului . De exemplu, să zicem că receiver.exampleprimește un mesaj poștal From: [email protected]și dorește să îl raporteze. Dacă găsește ruf=mailto:[email protected], caută o înregistrare DNS de confirmare în spațiul de nume administrat de țintă, astfel: 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

Rapoarte agregate

Rapoartele agregate sunt trimise ca fișiere XML , de obicei o dată pe zi. Subiectul menționează „Raport de domeniu“, care indică numele de domeniu DNS despre care a fost generat raportul, iar „Submitter“, care emite raportul entității. Sarcina utilă se află într-un atașament cu un nume de fișier lung format din elemente separate de bang, cum ar fi receptorul emitent de rapoarte, epocile de început și sfârșit ale perioadei raportate sub formă de timbre în stil Unix, un identificator unic opțional și o extensie care depinde de compresia posibilă (pe vremuri .zip).

De exemplu: example.com!example.org!1475712000!1475798400.xml.gz.

Conținutul XML constă dintr-un antet, care conține politica pe care se bazează raportul și metadatele raportului, urmate de un număr de înregistrări. Înregistrările pot fi plasate într-o bază de date ca relație și vizualizate într-o formă tabelară. Schema XML este definită în Anexa C a specificațiilor și o înregistrare brută este exemplificată în dmarc.org. Aici rămânem cu un exemplu relațional, care transmite mai bine natura datelor. Înregistrările DMARC pot fi, de asemenea, transformate direct în HTML prin aplicarea unei foi de stil XSL .

Rândurile DMARC ale unei înregistrări agregate afișate sub formă de tabel
IP sursă Numara Dispoziţie SPF DKIM Antet din Domeniul SPF (rezultat) Domeniul DKIM (rezultat)  
192.0.2.1 12 nici unul ✓  Treceți ✓  Treceți example.org example.org ( ✓  Pass ) example.org ( ✓  Pass )  
192.0.2.1 1 nici unul ✓  Treceți ✗  Nu reușesc example.org example.org ( ✓  Pass ) example.org ( ✗  Fail )  
192.0.2.28 42 nici unul ✗  Nu reușesc ✓  Treceți example.org example.org ( ✗  Fail ) example.org ( ✓  Pass ) forwarder.example ( ✓  Pass )
192.0.2.82 21 nici unul ✗  Nu reușesc ✗  Nu reușesc example.org discusslist.example ( ✓  Pass ) example.org ( ✗  Fail ) discusslist.example ( ✓  Pass )
...

Rândurile sunt grupate după IP sursă și rezultate de autentificare, trecând doar numărul fiecărui grup. Coloanele de rezultate din stânga, etichetate SPF și DKIM prezintă rezultate DMARC, fie trecere, fie eșec, luând în considerare alinierea. Cele din dreapta, cu etichete similare, arată numele domeniului care pretinde că participă la trimiterea mesajului și (între paranteze) starea de autentificare a acelei revendicări conform protocolului original, SPF sau DKIM, indiferent de Alinierea identificatorului. În partea dreaptă, SPF poate apărea cel mult de două ori, o dată pentru Return-Path:test și o dată pentru HELOtest; DKIM poate apărea o dată pentru fiecare semnătură prezentă în mesaj. În exemplu, primul rând reprezintă fluxul principal de e-mail din example.org, iar al doilea rând este o eroare DKIM, cum ar fi ruperea semnăturii din cauza unei modificări minore în tranzit. Al treilea și al patrulea rând arată moduri tipice de erori ale unui expeditor și, respectiv, ale unei liste de corespondență. Autentificarea DMARC a eșuat numai pentru ultimul rând; ar fi putut afecta dispoziția mesajului dacă example.org ar fi specificat o politică strictă.

Dispoziția reflectă politica publicată de fapt , aplicat la mesaje, nici unul , carantină , sau respinge . Împreună cu acesta, neprezentat în tabel, DMARC prevede o suprascriere a politicii. Unele motive pentru care un destinatar poate aplica o politică diferită de cea solicitată sunt deja prevăzute în caietul de sarcini:

înaintat
păstrând aceeași adresă de respingere, de obicei nu rupe DKIM,
prelevat
deoarece un expeditor poate alege să aplice politica doar unui procent de mesaje,
expeditor de încredere
mesajul a sosit de la o sursă cunoscută local
listă de email-uri
receptorul a stabilit euristic că mesajul a sosit de pe o listă de discuții,
politica locală
destinatarii sunt, în mod evident, liberi să aplice politica care le place, este bine să anunțați expeditorii,
alte
dacă niciunul dintre cele de mai sus nu se aplică, un câmp de comentariu permite să spună mai multe.

Rapoarte criminalistice

Rapoartele criminalistice, cunoscute și sub denumirea de rapoarte de eșec, sunt generate în timp real și constau din copii redactate ale e-mailurilor individuale care nu au reușit SPF, DKIM sau ambele pe baza valorii specificate în foetichetă. Formatul lor, o extensie a formatului de raportare a abuzurilor , seamănă cu cel al reboturilor obișnuite, deoarece conține fie un „mesaj / rfc822”, fie un „text / rfc822-anteturi”.

Rapoartele criminalistice conțin, de asemenea, următoarele:

- Sursa de trimitere a adresei IP

- De la adresa de e-mail

- Adresa de e-mail destinatar

- Linia de subiect prin e-mail

- Rezultatele autentificării SPF și DKIM

- Timp primit

- Anteturi de mesaje de e-mail care includ gazda de trimitere, ID-ul mesajului de e-mail, Semnătura DKIM și orice alte informații de antet personalizate.

Compatibilitate

Expeditori

Există mai multe tipuri diferite de redirecționare a e-mailurilor , dintre care unele pot rupe SPF.

Lista de e-mail-uri

Listele de corespondență sunt o cauză frecventă a ruperii legitime a semnăturii DKIM a autorului original, de exemplu prin adăugarea unui prefix la antetul subiectului. Sunt posibile mai multe soluții, iar pachetele software ale listelor de corespondență lucrează la soluții.

Opriți toate modificările mesajelor

Această soluție păstrează fluxul de lucru standard al listei de corespondență și este adoptată de mai mulți operatori mari de listă de corespondență, dar împiedică lista să adauge subsoluri și prefixe ale subiectului. Acest lucru necesită o configurare atentă a software-ului de e-mail pentru a vă asigura că anteturile semnate nu sunt reordonate sau modificate. Un server de e-mail configurat greșit poate face List-id în DKIM-ul său de mesaje trimise către o listă de corespondență, iar apoi operatorul listei este obligat să-l respingă sau să facă De la: rescriere.

From: rescriere

Una dintre cele mai populare și mai puțin invazive soluții constă în rescrierea From:câmpului antet. Adresa autorului original poate fi apoi adăugată la Reply-To:câmp. Rescrierea poate varia de la doar adăugarea .INVALIDla numele domeniului, până la alocarea unui ID de utilizator temporar în cazul în care este utilizat un ID opac, aceasta păstrează adresa de e-mail „reală” a utilizatorului privată din listă. În plus, numele afișat poate fi schimbat astfel încât să arate atât autorul, cât și lista (sau operatorul listei). Aceste exemple ar avea ca rezultat, respectiv, unul dintre: 

From: John Doe <[email protected]>
From: John Doe <[email protected]>
From: John Doe via MailingList <[email protected]>
and
Reply-To: John Doe <[email protected]>

Ultima linie, Reply-To:trebuie să fie proiectată pentru a se potrivi funcționalității de răspuns la autor, în cazul în care funcția de răspuns la listă este acoperită de modificarea precedentă în From:câmpul antet. În acest fel, sensul original al acestor câmpuri este inversat.

Modificarea autorului nu este corectă în general și poate rupe relația așteptată dintre semnificație și apariția acelei date. De asemenea, întrerupe utilizarea automată a acestuia. Există comunități care folosesc liste de corespondență pentru a-și coordona munca și implementează instrumente care folosesc From:câmpul pentru a atribui autorul atașamentelor.

Alte soluții

Înfășurarea mesajului funcționează frumos, pentru cei care utilizează un client de e-mail care înțelege mesajele înfășurate. Faptul că nu face nicio modificare este probabil cea mai evidentă soluție, cu excepția faptului că acestea par a fi legal datorate în unele țări și că pierderea obișnuită a autentificării SPF poate face autentificarea generală mai fragilă.

Câmpul expeditorului

Efectuarea modificărilor From:câmpului antet pentru a trece alinierea DKIM poate scoate mesajul în conformitate cu RFC 5322 secțiunea 3.6.2: „Câmpul„ De la: ”specifică autorul (autorii) mesajului, adică cutia poștală (e) a persoanei sau a sistemului (sistemelor) responsabil de scrierea mesajului. " Cutia poștală se referă la adresa de e-mail a autorului. Sender:Antetul este disponibil pentru a indica faptul că un e - mail a fost trimis în numele unei alte părți, dar DMARC politica verifică doar din domeniu și ignoră domeniul expeditorului.

Atât ADSP, cât și DMARC resping utilizarea câmpului Expeditor pe bază non-tehnică, deoarece mulți agenți de utilizator nu afișează acest lucru destinatarului.

Istorie

Un proiect de specificație DMARC a fost menținut începând cu 30 ianuarie 2012.

În octombrie 2013, GNU Mailman 2.1.16 a fost lansat cu opțiuni pentru a gestiona postere dintr-un domeniu cu politica DMARC de p=reject. Schimbarea a încercat să anticipeze problemele de interoperabilitate așteptate în cazul în care politicile restrictive au fost aplicate domeniilor cu utilizatori umani (spre deosebire de domeniile de poștă pur tranzacționale).

În aprilie 2014, Yahoo și-a schimbat politica DMARC p=reject, provocând astfel un comportament necorespunzător în mai multe liste de corespondență. Câteva zile mai târziu, AOL și-a schimbat politica DMARC în p=reject. Aceste mișcări au dus la o cantitate semnificativă de perturbări, iar acei furnizori de căsuțe poștale au fost acuzați că au forțat costurile propriilor eșecuri de securitate către terți. Începând cu 2020, Întrebările frecvente din wiki-ul oficial DMARC conțin mai multe sugestii pentru listele de e-mail pentru a gestiona mesajele dintr-un domeniu cu o politică strictă DMARC, dintre care cea mai implementată este lista de e-mail care schimbă antetul „De la” la o adresă din domeniu propriu.

Un grup de lucru IETF a fost format în august 2014 pentru a aborda problemele DMARC, pornind de la preocupările de interoperabilitate și, eventual, continuând cu o specificație și o documentație standard revizuite. Între timp, specificația DMARC existentă ajunsese la o stare editorială convenită și implementată de mulți. A fost publicat în martie 2015 pe fluxul de trimiteri independente din categoria „Informațional” (non-standard) sub denumirea RFC 7489.

În martie 2017, Comisia Federală pentru Comerț a publicat un studiu privind utilizarea DMARC de către întreprinderi. Din 569 de companii, studiul a constatat că aproximativ o treime a implementat orice configurație DMARC, mai puțin de 10% au folosit DMARC pentru a instrui serverele să respingă mesajele neautentificate și o majoritate a implementat SPF.

Colaboratori

Contribuții la specificația DMARC includ:

Vezi si

Note

Referințe

linkuri externe