Czytanie raportów DMARC: co naprawdę stoi w plikach XML

Wpis DMARC z rua= ma skutek uboczny, na który mało kto jest przygotowany: od następnego dnia codziennie przychodzą wiadomości z załączonymi plikami ZIP albo GZ — od Google, Microsoftu, Yahoo i od serwerów pocztowych, o których nazwach nigdy się nie słyszało. W środku jest XML. Większość osób zagląda dwa razy, po czym zakłada regułę zgarniającą całą stertę do jednego folderu.

Szkoda, bo te pliki odpowiadają na pytanie, na które nic innego nie odpowie: kto właściwie wysyła pocztę pod moją nazwą?

Co jest w raporcie — a czego nie ma

Raport zbiorczy to zestawienie liczbowe, nie zbiór wiadomości. Nie zawiera tematów, odbiorców ani treści. Dla jednego dnia i jednego odbierającego mówi: z tych adresów IP przyszło tyle a tyle wiadomości z Twoją domeną w polu From:, i tak się skończyły.

Budowa jest zawsze ta sama. Kto pozna ją raz, przeczyta plik również bez narzędzia.

Budowa jest w każdym raporcie identyczna. Liczy się odstęp między policy_evaluated a auth_results: jedno to wynik, drugie to uzasadnienie.

Jeden rekord w oryginale

Tak wygląda pojedynczy record, rozpakowany i wcięty:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>417</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>firma.pl</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>firma.pl</domain><result>pass</result></spf>
  </auth_results>
</record>

Czytane po ludzku: z adresu 198.51.100.24 przyszło tego dnia 417 wiadomości z firma.pl jako widocznym nadawcą. SPF przeszedł i był dopasowany, DKIM nie — tutaj podpisu w ogóle nie było. Ponieważ wystarczy jedna dopasowana droga, DMARC jest zaliczony. disposition: none mówi, że odbierający nie podjął żadnych kroków.

Pułapka: dwa wyniki o tych samych nazwach

Słowa spf i dkim występują w tym bloku dwukrotnie, w dwóch różnych miejscach i w dwóch różnych znaczeniach:

W auth_results stoi wynik surowy: czy sama weryfikacja przeszła?
W policy_evaluated stoi wynik po dopasowaniu: czy to przejście liczy się również dla DMARC?

pass u góry i fail u dołu to najczęstsze znalezisko w ogóle i nie opisuje sprzeczności, tylko źródło, które wysyła legalnie, ale pod cudzą domeną. Dlaczego tak jest, wyjaśnia artykuł o dopasowaniu.

Co zwykle wychodzi z pierwszego raportu

Kto włącza DMARC od zera, znajduje w pierwszych dwóch tygodniach więcej źródeł wysyłki, niż się spodziewał. Kandydaci powtarzają się w różnych organizacjach:

Źródło	Typowe ustalenie
Własny serwer pocztowy	SPF i DKIM dopasowane — część bez niespodzianek
Usługa newslettera	SPF bez dopasowania, DKIM na domenie dostawcy
System zgłoszeń albo CRM	wysyła pod domeną firmy, całkiem bez DKIM
Oprogramowanie do faktur albo sklep	własna droga wysyłki, często zapomniana od lat
Monitoring, kopie zapasowe, drukarki	małe liczby, stałe IP, zwykle z własnej sieci
Przekierowania	obce IP, SPF złamany, DKIM nienaruszony
Obcy nadawcy	zmienne adresy IP, oba sprawdzenia nieudane, małe liczby

Ostatni wiersz jest powodem, dla którego wdraża się DMARC — i z reguły jest najmniejszy. Praca tkwi w wierszach powyżej: każde uprawnione źródło trzeba znaleźć i skonfigurować, zanim politykę da się zaostrzyć.

Kolejność, która działa

Ustaw p=none z rua=. Nie zmienia to nic w doręczaniu i włącza wyłącznie raporty.
Zbieraj przez dwa do czterech tygodni. Nie krócej: comiesięczny przebieg fakturowania i newsletter wychodzący co trzy tygodnie inaczej się nie pojawią.
Wypisz źródła i przypisz każdemu nazwę. Każde IP, z którego przyszła więcej niż garstka wiadomości, musi zostać rozpoznane.
Doprowadź do dopasowania, z reguły przez DKIM u danego dostawcy.
Dopiero potem zaostrzaj — stopniowo, przez pct=, które ustala odsetek wiadomości objętych polityką.

Na trzecim kroku projekty grzęzną, i to z niewygodnego powodu: część źródeł da się ustalić tylko przez pytanie po firmie, kto sześć lat temu uruchomił jakąś usługę.

Raporty kryminalistyczne

Obok rua= istnieje ruf=: zgłoszenia o pojedynczych nieudanych wiadomościach, z nagłówkami i częściowo treścią. W praktyce nie przychodzi ich prawie wcale. Raporty zawierały dane osobowe osób trzecich i większość dużych dostawców z tego powodu wstrzymała ich wysyłkę. ruf= można ustawić; spodziewać się nie należy niczego.

Czy potrzeba do tego narzędzia?

Przy kilku domenach i umiarkowanym ruchu wystarczy rozpakować załączniki i przejrzeć rekordy — ciekawe są te z nieznanym source_ip i dwiema porażkami w policy_evaluated. Przy dwucyfrowej liczbie domen albo dużym wolumenie przestaje to być czytelne, a analiza scalająca raporty i rozwiązująca adresy IP oszczędza godziny.

Rzecz jednak w czym innym: te raporty nie są skomplikowane. Są tylko tak zapakowane, że wyglądają na skomplikowane.