Cum citiți rapoartele agregate DMARC

Ce sunt rapoartele agregate

Când înregistrarea DMARC conține rua=mailto:..., destinatarii care acceptă raportarea trimit un rezumat periodic al mesajelor pe care le-au văzut folosind domeniul dumneavoastră în antetul From. Formatul este XML, definit în RFC 7489 Anexa C, iar intervalul obișnuit este de o zi. Fiecare raport vine de la un singur destinatar, de exemplu un furnizor mare de căsuțe poștale, și acoperă doar mesajele livrate acelui destinatar; prin urmare, un raport luat singur descrie o felie din traficul dumneavoastră, nu întregul.

Rapoartele conțin numărători, adrese IP, domenii și rezultate de autentificare. Ele nu conțin conținutul mesajelor, subiectele sau adresele destinatarilor, iar acesta este exact motivul pentru care majoritatea furnizorilor mari le trimit. Rapoartele de eșec (ruf) sunt cu totul altceva și se trimit foarte rar.

Fișierul și structura lui

Rapoartele sosesc ca atașamente, de obicei comprimate cu gzip sau zip. RFC 7489 §7.2.1.1 descrie numele fișierului drept domeniul destinatarului, domeniul politicii și începutul și sfârșitul perioadei de raportare ca marcaje de timp Unix, separate prin !. Detaliul pare mărunt, dar vă ușurează munca: puteți sorta fișierele după dată și după destinatar înainte de a le deschide.

<feedback>
  <report_metadata>
    <org_name>receiver.example.net</org_name>
    <email>noreply-dmarc@receiver.example.net</email>
    <report_id>1234567890</report_id>
    <date_range><begin>1789430400</begin><end>1789516799</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.25</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounces.esp.example.net</domain><scope>mfrom</scope><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

policy_evaluated față de auth_results

Această distincție explică majoritatea rândurilor derutante. În exemplul de mai sus, auth_results/spf spune pass, dar policy_evaluated/spf spune fail. SPF a trecut pentru bounces.esp.example.net, care nu este aliniat cu example.com, așa că, din punctul de vedere al DMARC, SPF nu a ajutat cu nimic la acest mesaj.

DKIM din același rând a trecut pentru example.com, care este aliniat, deci policy_evaluated/dkim este pass, iar mesajul a trecut de DMARC. Un mesaj trece atunci când oricare dintre cele două rezultate aliniate trece. Expeditorul acesta este în regulă, deși repararea alinierii SPF cu un domeniu de bounce propriu ar adăuga un al doilea strat de siguranță.

Împărțirea rândurilor în patru grupuri

1. Expeditorii dumneavoastră, care trec

Adresele IP ale furnizorului de căsuțe poștale, ale instrumentului de marketing sau ale serverelor proprii, cu un DKIM ori un SPF aliniat care trece. Acestea reprezintă starea dorită și nu cer nicio acțiune. Singurul lucru de făcut este să confirmați că volumele arată plauzibil în comparație cu ce trimiteți efectiv.

2. Expeditorii dumneavoastră, care eșuează

Adrese pe care le recunoașteți sau care aparțin unui serviciu folosit de dumneavoastră, unde ambele rezultate aliniate eșuează. Cauzele tipice sunt un serviciu care semnează cu domeniul propriu, un instrument nou pe care nu l-a configurat nimeni sau o cheie DKIM expirată. Reparați-le înainte de aplicare: exact acestea sunt mesajele pe care p=reject le-ar bloca.

3. Redirecționarea

IP-uri necunoscute, adesea ale unor universități, companii sau furnizori de e-mail, cu SPF care eșuează, dar cu DKIM aliniat care trece. În spatele lor stă de obicei un destinatar care vă redirecționează mesajele, iar serverul care face redirecționarea nu figurează, firesc, în înregistrarea SPF. Cât timp DKIM trece, trece și DMARC și nu aveți nimic de făcut.

4. Falsificare și zgomot

IP-uri necunoscute la care eșuează și SPF, și DKIM, adesea în numere mici, venind din multe rețele diferite. Sunt mesaje care se dau drept ale dumneavoastră sau, ocazional, un sistem legitim despre care nu v-a spus nimeni. Confirmați a doua posibilitate cu proprietarul rețelei înainte de aplicare; după aceea, aplicarea este exact ceea ce oprește acest grup.

Ca să identificați un IP, căutați DNS-ul lui invers cu Căutare DNS și rețeaua din care face parte cu Informații IP. Un nume PTR precum mail-out.esp.example.net sau un ASN deținut de un furnizor cunoscut lămurește majoritatea rândurilor în câteva secunde.

Deschiderea rapoartelor în browser

XML-ul brut este greu de citit cu ochiul, iar răspunsul obișnuit este să încredințați fișierele unui serviciu terț. Analizorul de rapoarte DMARC face același lucru fără încărcare: lăsați în pagină atașamentele .xml, .xml.gz sau .zip, așa cum au sosit, iar el le analizează local. Rapoartele rămân pe calculatorul dumneavoastră, ceea ce contează, pentru că ele numesc adresa IP a fiecărui sistem care trimite în numele domeniului dumneavoastră.

Mai multe fișiere sunt îmbinate într-o singură vedere, așa că o săptămână de rapoarte de la patru destinatari se citește ca un singur tabel, nu ca douăzeci și opt de atașamente. Fiecare rând este o sursă, cu volumul ei, verdictul DMARC și rezultatele SPF și DKIM împreună cu alinierea lor, iar un grafic al volumului pe zi face ușor de observat un expeditor nou sau un val brusc de eșecuri. Tabelul se exportă în CSV, iar rândurile analizate în JSON.

Identificarea unei surse cere totuși o căutare, așa că interogarea pentru un IP este opțională: când întrebați despre o adresă, doar acea adresă ajunge la serverul XGM, iar raportul în sine nu este încărcat niciodată. Două limite merită știute înainte să vă bazați pe el. Nu preia rapoartele din căsuța dumneavoastră poștală, deci atașamentele tot dumneavoastră le descărcați, și nu citește rapoartele de eșec (ruf).

Rezumarea rapoartelor cu un script

Pentru un domeniu mic, un script care totalizează mesajele pe IP sursă și pe rezultat este suficient. Exemplul de mai jos folosește doar biblioteca standard Python și citește un director cu fișiere .xml, .xml.gz și .zip. Afișează mai întâi rândurile care nu au trecut de DMARC, pentru că exact acelea sunt cele care au nevoie de atenție.

import gzip, sys, zipfile
from collections import Counter
from pathlib import Path
import xml.etree.ElementTree as ET

def open_report(path):
    if path.suffix == ".gz":
        return gzip.open(path).read()
    if path.suffix == ".zip":
        with zipfile.ZipFile(path) as archive:
            return archive.read(archive.namelist()[0])
    return path.read_bytes()

totals = Counter()
for path in Path(sys.argv[1]).iterdir():
    root = ET.fromstring(open_report(path))
    org = root.findtext("report_metadata/org_name")
    for record in root.iter("record"):
        ip = record.findtext("row/source_ip")
        count = int(record.findtext("row/count") or 0)
        dkim = record.findtext("row/policy_evaluated/dkim")
        spf = record.findtext("row/policy_evaluated/spf")
        passed = "pass" in (dkim, spf)
        totals[(passed, ip, dkim, spf, org)] += count

for (passed, ip, dkim, spf, org), count in sorted(totals.items()):
    print(f"{'PASS' if passed else 'FAIL'} {ip:<39} dkim={dkim:<4} spf={spf:<4} {count:>6}  {org}")

Analizați doar rapoartele primite la propria adresă de raportare și tratați fișierele ca pe o intrare în care nu aveți încredere. Analizorul din biblioteca standard nu preia entități externe, dar fișierele foarte mari sau malformate venite de la expeditori necunoscuți ar trebui totuși ignorate, nu procesate orbește.

Un exemplu concret

Mai jos este o săptămână rezumată de rapoarte pentru example.com, un domeniu care publică p=none și folosește un furnizor de căsuțe poștale, un serviciu de newsletter și un server de aplicație. Adresele provin din intervalele rezervate pentru documentație în RFC 5737, deci țin locul unor rețele reale. Fiecare rând este un singur IP sursă, cu numărul total de mesaje adunat de la toți destinatarii.

Primul rând este starea dorită. Serviciul de newsletter trece doar prin DKIM, ceea ce este suficient pentru DMARC; setarea unui domeniu de bounce propriu ar adăuga și alinierea SPF, dar rămâne opțională. Rândul universității este o redirecționare și nu cere nimic, pentru că semnătura DKIM supraviețuiește drumului.

Rămân două rânduri care cer o decizie. Serverul de aplicație trece de SPF, dar nu și de DKIM, așa că chitanțele lui vor pica la DMARC imediat ce un client le redirecționează, deci trebuie să activați semnarea DKIM pe releul pe care îl folosește. Ultimul rând eșuează la tot, dintr-o rețea pe care nu o recunoaște nimeni, ceea ce înseamnă falsificare tipică și exact ceea ce va opri aplicarea politicii.

Când rapoartele nu sosesc

Tăcerea nu este un semn bun. Un domeniu care trimite e-mail către furnizori mari ar trebui să vadă primele rapoarte în una-două zile de la publicarea rua. Dacă nu sosește nimic, parcurgeți pe rând cauzele de mai jos, începând chiar cu înregistrarea.

1. Verificați că la _dmarc.example.com există exact o înregistrare DMARC și că aceasta se analizează corect; o a doua înregistrare îi face pe destinatari să le ignore pe amândouă.
2. Verificați sintaxa rua: fiecare adresă are nevoie de prefixul mailto:, iar mai multe adrese se separă prin virgulă.
3. Dacă adresa este pe alt domeniu, confirmați că acel domeniu publică example.com._report._dmarc.<domeniul lui> cu v=DMARC1.
4. Confirmați că acea căsuță poștală acceptă atașamente comprimate mari și că nu filtrează rapoartele ca mesaje nedorite.
5. Nu uitați că destinatarii raportează doar mesajele pe care le-au primit: un domeniu care nu a trimis nimic către un furnizor nu primește niciun raport de la el.

Securitatea e-mailului acoperă primele trei puncte într-o singură rulare, inclusiv căutarea autorizării externe. Pentru al patrulea, trimiteți un mesaj de test cu un atașament mare la adresa de raportare și confirmați că ajunge.

Instrument în browser, script propriu sau serviciu de raportare

Toate cele trei abordări citesc același XML, deci alegerea ține de volum și de efort. Un domeniu mic, cu o mână de expeditori, este bine servit de analizor sau de un script rulat săptămânal. Un domeniu cu mulți furnizori, cu mai multe branduri sau cu cerințe stricte de conformitate câștigă vizibil de pe urma unui serviciu care păstrează istoricul, rezolvă proprietarii adreselor IP și alertează la schimbări.

Indiferent ce alegeți, păstrați o vreme rapoartele brute. Când un serviciu clasifică greșit o sursă sau când un script are o eroare, fișierele XML sunt singura dovadă la care vă puteți întoarce.

Subdomenii, mai multe domenii și intervale de timp

Un raport acoperă domeniul de politică pentru care a fost generat, dar rândurile pot include și mesaje venite de la subdomeniile care moștenesc acea politică. Câmpul identifiers/header_from arată domeniul From exact pentru fiecare rând, așa că filtrați după el atunci când vreți să vedeți doar news.example.com. Subdomeniile cu propria înregistrare DMARC și cu propria adresă rua primesc rapoarte separate.

Dacă administrați mai multe domenii, îndreptați-le pe toate către aceeași adresă de raportare și grupați rândurile după policy_published/domain. O singură căsuță poștală cu un analizor consecvent este mai ușor de menținut în funcțiune decât un proces separat pentru fiecare domeniu. În schimb, fiecare adresă externă are în continuare nevoie de înregistrarea ei de autorizare pentru fiecare domeniu care o folosește.

Valorile date_range sunt marcaje de timp Unix în UTC, iar majoritatea destinatarilor acoperă o zi UTC completă. Când comparați rapoartele cu propriile jurnale de trimitere, convertiți mai întâi ambele surse la UTC. O campanie trimisă seara târziu într-un fus orar aflat înaintea UTC apare în raportul din ziua precedentă, ceea ce explică de cele mai multe ori nepotrivirile aparente.

Confidențialitate, volum și păstrare

Rapoartele agregate listează adresele IP ale serverelor care trimit și, uneori, domeniul destinatarului din plic. În general nu sunt date cu caracter personal despre destinatari individuali, dar rămân date operaționale pe care ar trebui să le țineți într-o căsuță poștală controlată. Stabiliți de la început cât timp le păstrați; câteva luni de istoric sunt de obicei suficiente pentru a observa tendințele.

Un domeniu cu trafic mare primește multe rapoarte pe zi, de la mulți destinatari diferiți. O căsuță poștală pe care nu o citește nimeni devine repede o povară, așa că fie automatizați rezumatul, fie folosiți un serviciu de raportare. Dacă serviciul este pe alt domeniu, verificați cu Securitatea e-mailului că acesta autorizează rapoartele dumneavoastră.

• Folosiți o adresă dedicată pentru rua, nu o căsuță personală.
• Excludeți această căsuță poștală din sistemele de marketing și de ticketing.
• Fiți atenți la scăderile bruște de volum: o adresă rua stricată sau o greșeală de scriere în DNS oprește fluxul în tăcere.
• Comparați policy_published din rapoarte cu înregistrarea dumneavoastră după fiecare modificare DNS.

Surprize frecvente

• IP-urile propriului furnizor eșuează: semnarea DKIM nu este activată pentru domeniul dumneavoastră în consola de administrare a furnizorului, așa că în mesaj apare doar semnătura furnizorului.
• Mesaje pe care nu le-ați trimis niciodată trec de DMARC: un serviciu vechi mai are o cheie DKIM validă sau un include SPF pentru domeniul dumneavoastră; revocați tot ce nu mai folosiți.
• Numere mult mai mici decât ce trimiteți: rapoartele vin doar de la destinatarii care raportează și doar pentru mesajele livrate efectiv la ei.
• Același IP cu rezultate diferite: mesaje diferite plecate de pe același server au urmat drumuri diferite, de exemplu livrare directă și redirecționare.
• Un `disposition` de `none` sub o politică de aplicare: destinatarul a aplicat o excepție locală, de exemplu pentru o listă de discuții cunoscută, și o spune în elementul reason.

Niciuna dintre acestea nu cere panică, dar fiecare merită un rând în notițele dumneavoastră. Tiparele care se repetă săptămână de săptămână sunt cele care merită reparate.

Transformarea rapoartelor în acțiuni

Când grupul al doilea rămâne gol pe o fereastră completă de raportare, sunteți gata să aplicați politica. Planul de la p=none la p=reject descrie etapele și modul de revenire.

Întrebări frecvente

Surse

• RFC 7489: DMARC, §7 Raportare și Anexa C (schema XML)
• RFC 7208: SPF
• RFC 6376: Semnături DKIM
• Draft IETF: raportare agregată DMARC (DMARCbis)
• Documentația Python: xml.etree.ElementTree