Branje poročil DMARC

Modul 4: Dostavljivost: SPF, DKIM in DMARC v praksi · Čas branja: 12 minut

Učni cilj: Po tej lekciji boste znali odpreti in prebrati zbirno poročilo DMARC, za vsako vrstico ugotoviti, kateri vir gre in zakaj uspe ali ne uspe, ter se odločiti, kaj popraviti, kaj lahko prezrete in kdaj lahko zaostrite svojo politiko.

Ključni pojmi: zbirno poročilo (aggregate report, RFC 9990), rua, XML, gzip ali zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selektor, poročilo o napakah (ruf, RFC 9991), storitev za poročila, zasebnost

Kaj prejmete

Če ste v svojem zapisu DMARC nastavili naslov rua (lekcija 4.4), Vam veliki ponudniki, kot so Google, Microsoft in Yahoo, pošljejo približno vsak dan zbirno poročilo. To je e-pošta s prilogo, običajno stisnjena XML-datoteka (gzip) z imenom, kot je:

receiver.example!example.com!1793923200!1794009599.xml.gz

To pomeni: od prejemnika receiver.example, o Vaši domeni example.com, za obdobje med dvema časovnima žigoma (sekunde od leta 1970; tukaj 6. november 2026, cel dan po UTC).

Poročilo ne vsebuje vsebine e-pošte, ne zadev in običajno ne naslovov prejemnikov. Vsebuje za vsak pošiljajoč strežnik število sporočil in izid SPF, DKIM in DMARC. Zato je zanesljiv pregled, kdo v imenu Vaše domene pošilja pošto, tudi viri, na katere ste morda pozabili, in goljufi.

Struktura poročila

Poročilo ima tri dele. Spodaj so najpomembnejši deli iz primera datoteke pri tej lekciji (dmarc-rapport-1.xml).

1. Kdo poroča, za katero obdobje

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Katero politiko je prejemnik našel pri Vas

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

To vedno preverite: če tukaj ne piše to, kar mislite, da je v Vašem DNS, je prejemnik prebral drug (ali star) zapis.

3. Za vsak vir: en zapis

Vsak record se nanaša na en pošiljajoč IP-naslov z eno kombinacijo izidov:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Najpomembnejša razlika: auth_results napram policy_evaluated

Tukaj je bistvo branja. V zgornjem primeru je v auth_results dvakrat zapisano pass: DKIM je uspel za mailer.example, SPF pa za bounce.mailer.example. Vendar je v policy_evaluated dvakrat zapisano fail. To ni protislovje: policy_evaluated šteje samo uspešno preverjanje, ki je usklajeno s header_from. Nobena od obeh domen ne spada pod example.com, zato DMARC ne uspe.

Tako preberete vsako vrstico:

1. Poglejte policy_evaluated. Ali pri dkim ali spf piše pass? Potem DMARC uspe in ta vir je v redu.
2. Ali vse ne uspe? Poglejte v auth_results domene. Ali gre za storitev, ki je Vaša, a uspe le za svojo lastno domeno? Potem morate pri tej storitvi vklopiti DKIM z lastno domeno (lekcija 4.3).
3. Ali tudi v auth_results ne uspe, ali DKIM sploh manjka? Ugotovite, čigav je IP-naslov (obratni DNS, lekcija 5.1, ali poizvedba whois). Če gre za enega od Vaših sistemov: popravite. Če je neznan in gre za sumljive količine: verjetno gre za ponarejanje.

Vzorci, ki jih boste redno videli

Bodite pozorni tudi na IPv6: lasten strežnik, ki včasih pošilja prek IPv6, medtem ko Vaš SPF navaja samo IPv4-naslov, bo pri teh vrsticah dal softfail. Z digitalnim podpisom DKIM DMARC kljub temu uspe, vendar je to znak, da je Vaš SPF nepopoln.

Od poročila do odločitve

Pripravljeni ste zaostriti svojo politiko (iz none na quarantine, nato na reject), ko:

• ima vsak vir, ki je Vaš, v policy_evaluated vsaj en pass;
• to velja že nekaj tednov, pri vseh velikih ponudnikih;
• tisto, kar še vedno ne uspe, je samo preusmerjena e-pošta z veljavnim digitalnim podpisom DKIM (ta kljub temu uspe) ali očitno ponarejanje.

Če ne uspe velik lasten vir, kot v primeru storitev za novičnik z 1250 sporočili, je še prezgodaj. Pri p=reject bi prejemnik tistih 1250 novičnikov zavrnil.

Kako narediti poročila berljiva

Eno poročilo v urejevalniku besedil je obvladljivo. Dvajset na dan ne. Obstajajo tri možnosti:

• Storitev za poročila (obstaja jih veliko, tudi z brezplačno različico). Njihov naslov vnesete v rua, oni pa iz tega naredijo grafe in sezname. Pozor: s tem tej storitvi omogočite vpogled v to, kateri strežniki pošiljajo v Vašem imenu, poleg tega je naslov za poročila na njihovi domeni (glejte potrditev prek _report._dmarc v lekciji 4.4). Izberite storitev, ki ji zaupate in ki upošteva GDPR.
• Lastno orodje: obstajajo odprtokodni programi, ki poročila pridobijo iz poštnega predala in jih uredijo v pregled.
• Branje na roko z XML-pregledovalnikom ali brskalnikom, za občasno uporabo.

Poročila o napakah (ruf, RFC 9991) so drugačna: za vsako neuspelo sporočilo posebej, včasih z deli e-pošte vred. Skoraj noben velik ponudnik jih ne pošilja, prav zaradi zasebnosti. Za pravilno uvedbo DMARC jih ne potrebujete.

V praksi: tako je videti

Pri WebOké lahko naslov za poročila vnesete v pomoči DMARC v DirectAdmin ali Moj WebOké (glejte lekcijo 4.4), sami pa izberete poštni predal, kamor poročila prihajajo; ločen naslov, kot je dmarc@, z lastno mapo prepreči, da bi se zaradi poročil izgubila Vaša običajna e-pošta. Branje opravite s storitvijo za poročila ali programom po lastni izbiri. To deluje enako pri vsakem ponudniku: poročilo je v standardni obliki.

Povzetek

• Zbirno poročilo je dnevna XML-datoteka (pogosto stisnjena) za vsakega prejemnika, ki za vsak pošiljajoč IP-naslov navaja število sporočil in izide.
• auth_results navaja surov izid SPF in DKIM; policy_evaluated pa samo, kaj je usklajeno uspelo. Pass v auth_results je lahko fail v DMARC.
• Preusmerjeno e-pošto prepoznate po DKIM pass s SPF fail; ponarejanje po tem, da vse ne uspe z neznanega IP-naslova.
• Politiko zaostrite šele, ko vsi Vaši lastni viri uspevajo že nekaj tednov.
• Poročila o napakah (ruf) so redka in niso potrebna.

Kviz

Naloga

Naloga Z4.5: Branje poročila DMARC. Odprite primer datoteke dmarc-rapport-1.xml (zbirno poročilo o example.com, z izmišljenimi podatki). Odgovorite na vprašanja: katero politiko je prejemnik našel, koliko sporočil je skupaj v poročilu, koliko od njih ni uspelo pri DMARC, katera vrstica je storitev za novičnike in kaj je treba tam storiti, katera vrstica je preusmerjena e-pošta, katera vrstica je verjetno ponarejanje, kaj se mora spremeniti v zapisu SPF glede na vrstico 6, katera vrstica uspe samo zahvaljujoč DKIM pri storitvi z lastnim Return-Path, in ali lahko domena zdaj preide na p=quarantine? Program Vaše odgovore preveri z ustaljenim ključem in za vsako vprašanje pojasni, katera vrstica poročila daje odgovor.

Za nadaljnje branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.

• Kaj je DMARC? Razlaga v preprostem jeziku
• Priročnik DirectAdmin 5.9: DMARC nastavitev
• Brezplačen tečaj DNS 4.5: DMARC: kaj morajo prejemniki narediti z lažno pošto
• RFC 9990 (DMARC Aggregate Reporting), s primerom poročila v Prilogi B; RFC 9991 (Failure Reporting)