DMARC

Ten artykuł dotyczy systemu sprawdzania poprawności wiadomości e-mail. Aby zapoznać się z punktem połączenia telefonicznego, zobacz punkt rozgraniczający .
Nie mylić z dMarc Broadcasting .

Domain-based Message Authentication, Reporting and Conformance ( DMARC ) to protokół uwierzytelniania wiadomości e-mail . Został zaprojektowany, aby dać właścicielom domen poczty e-mail możliwość ochrony ich domeny przed nieautoryzowanym użyciem, powszechnie znanym jako fałszowanie wiadomości e-mail . Celem i głównym rezultatem wdrożenia DMARC jest ochrona domeny przed wykorzystaniem jej w atakach na firmową pocztę e-mail , phishingu , oszustwach e-mail i innych działaniach związanych z cyberzagrożeniami .

opublikowaniu wpisu DNS DMARC każdy odbiorczy serwer poczty e-mail może uwierzytelnić przychodzącą wiadomość e-mail na podstawie instrukcji opublikowanych przez właściciela domeny we wpisie DNS. Jeśli wiadomość e-mail przejdzie uwierzytelnienie, zostanie dostarczona i można jej zaufać. Jeśli wiadomość e-mail nie przejdzie weryfikacji, w zależności od instrukcji przechowywanych w rejestrze DMARC wiadomość e-mail może zostać dostarczona, poddana kwarantannie lub odrzucona.

DMARC rozszerza dwa istniejące mechanizmy uwierzytelniania poczty e-mail, Sender Policy Framework (SPF) i DomainKeys Identified Mail (DKIM). Pozwala administratorowi domeny opublikować zasady w swoich DNS , aby określić sposób sprawdzania pola Od: prezentowanego użytkownikom końcowym; jak odbiorca powinien radzić sobie z awariami – oraz zapewnia mechanizm raportowania działań wykonanych w ramach tych polityk.

  DMARC jest zdefiniowany w opublikowanym dokumencie Internet Engineering Task Force RFC 7489 z marca 2015 r. jako „Informacyjny”.

Przegląd

Zasady DMARC pozwalają domenie nadawcy wskazywać, że jego wiadomości e-mail są chronione przez SPF i/lub DKIM, a także informują odbiorcę, co zrobić, jeśli żadna z tych metod uwierzytelniania nie powiedzie się – na przykład odrzucić wiadomość lub poddać ją kwarantannie. Zasady mogą również określać, w jaki sposób odbiorca wiadomości e-mail może przesyłać do domeny nadawcy raporty o pomyślnych i/lub niepomyślnych wiadomościach.

Zasady te są publikowane w publicznym systemie nazw domen (DNS) jako tekstowe rekordy TXT .

DMARC nie określa bezpośrednio, czy e-mail jest spamem lub w inny sposób oszukańczy. Zamiast tego DMARC może wymagać, aby wiadomość nie tylko przeszła weryfikację DKIM lub SPF, ale także przeszła wyrównanie . W przypadku DMARC wiadomość może zakończyć się niepowodzeniem, nawet jeśli przejdzie przez SPF lub DKIM, ale nie powiedzie się wyrównanie.

Skonfigurowanie DMARC może poprawić dostarczalność wiadomości od legalnych nadawców.

Wyrównanie

DMARC działa, sprawdzając, czy domena w polu Od: wiadomości (zwana także „RFC5322.From”) jest „wyrównana” z innymi uwierzytelnionymi nazwami domen. Jeśli testy wyrównania SPF lub DKIM zakończą się pomyślnie, test wyrównania DMARC zakończy się pomyślnie.

Wyrównanie może być określone jako ścisłe lub złagodzone. W celu ścisłego wyrównania nazwy domen muszą być identyczne. W celu swobodnego wyrównania „Domena organizacyjna” najwyższego poziomu musi być zgodna. Domenę organizacyjną można znaleźć, sprawdzając listę publicznych sufiksów DNS i dodając następną etykietę DNS. Na przykład „abcdexample.com.au” i „example.com.au” mają tę samą domenę organizacyjną, ponieważ istnieje rejestrator oferujący klientom nazwy w domenie „.com.au”. Chociaż w czasach specyfikacji DMARC istniała grupa robocza IETF zajmująca się granicami domen, obecnie domenę organizacyjną można wyprowadzić tylko z publicznej listy sufiksów .

Podobnie jak SPF i DKIM, DMARC wykorzystuje pojęcie właściciela domeny, podmiotu lub podmiotów upoważnionych do wprowadzania zmian w danej domenie DNS.

SPF sprawdza, czy adres IP serwera wysyłającego jest autoryzowany przez właściciela domeny, który pojawia się w poleceniu SMTP MAIL FROM . (Adres e-mail w MAIL OD jest również nazywany adresem zwrotnym , adresem koperty od lub RFC5321.MailFrom). Oprócz wymagania pozytywnego wyniku kontroli SPF, DMARC sprawdza, czy RFC5321.MailFrom jest wyrównany z 5322.Od.

DKIM umożliwia kryptograficzne podpisywanie części wiadomości e-mail, przy czym podpis musi zakrywać pole Od. W nagłówku wiadomości DKIM-Signature d= (domena) i s= (selektor) określają, gdzie w DNS ma zostać pobrany klucz publiczny do podpisu. Prawidłowy podpis dowodzi, że sygnatariusz jest właścicielem domeny i że pole Od nie zostało zmodyfikowane od czasu zastosowania podpisu. Wiadomość e-mail może zawierać kilka podpisów DKIM; DMARC wymaga jednego ważnego podpisu, w którym domena w d= jest zgodna z domeną nadawcy podaną w polu nagłówka Od:.

rekord DNS

Rekordy DMARC są publikowane w DNS z etykietą subdomeny _dmarc , na przykład _dmarc.example.com . Porównaj to z SPF na example.com i DKIM na selector._domainkey.example.com .

Treść rekordu zasobu TXT składa się z tagów nazwa=wartość oddzielonych średnikami, podobnie jak SPF i DKIM. Na przykład: 

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

Tutaj v to wersja, p to polityka (patrz poniżej), sp polityka subdomeny, pct to procent „złych” wiadomości e-mail, do których należy zastosować politykę, a rua to identyfikator URI, do którego należy wysyłać zbiorcze raporty. W tym przykładzie podmiot kontrolujący domenę DNS example.com zamierza monitorować współczynniki błędów SPF i/lub DKIM i nie oczekuje wysyłania wiadomości e-mail z subdomen example.com. Pamiętaj, że subdomena może publikować swój własny rekord DMARC; odbiorcy muszą to sprawdzić, zanim powrócą do rekordu domeny organizacji.

Adopcja krok po kroku

Protokół przewiduje różne zapadki lub stany przejściowe, aby umożliwić administratorom poczty stopniowe przejście od całkowitego braku implementacji DMARC do nieustępliwej konfiguracji. Koncepcja stopniowej adopcji zakłada, że ​​celem DMARC jest najsilniejsze ustawienie, co nie ma miejsca we wszystkich domenach. Niezależnie od intencji, mechanizmy te pozwalają na większą elastyczność.

Polityka

Przede wszystkim trzy zasady:

  • żadna nie jest polityką na poziomie podstawowym. Odbiorcy nie wymagają specjalnego traktowania, ale umożliwiają domenie otrzymywanie raportów zwrotnych.
  • kwarantanna prosi odbiorców o podejrzane traktowanie wiadomości, które nie przejdą kontroli DMARC. Różni odbiorcy mają różne sposoby, aby to wdrożyć, na przykład oflagować wiadomości lub dostarczyć je do folderu ze spamem.
  • odrzuć prosi odbiorców o całkowite odrzucenie wiadomości, które nie przejdą kontroli DMARC.

Opublikowane zasady można złagodzić, stosując je tylko do odsetka wiadomości, które nie przejdą kontroli DMARC. Odbiorcy proszeni są o wybranie podanego procentu wiadomości za pomocą prostego próbkowania Bernoulliego . Reszta wiadomości powinna podlegać niższym zasadom; to znaczy brak, jeśli p=quarantine , kwarantanna, jeśli p=reject . Jeśli nie zostanie określony, wartość pct domyślnie wynosi 100% wiadomości. Przypadek p=kwarantanna; procent=0; jest używany do zmuszenia menedżerów list dyskusyjnych do przepisania pola From:, ponieważ niektórzy tego nie robią, gdy p=none .

Wreszcie, polityka subdomen, sp= i nowo dodana polityka no-domain pozwalają dostosować politykę dla określonych subdomen.

Raporty

DMARC jest w stanie wygenerować dwa oddzielne typy raportów. Zbiorcze raporty są wysyłane na adres podany po rua . Raporty kryminalistyczne są wysyłane pocztą elektroniczną na adres następujący po ruf . Te adresy e-mail muszą być określone w URI mailto (np. mailto:[email protected] ). Wiele adresów raportowania jest prawidłowych i każdy musi mieć pełny format URI, oddzielony przecinkiem.

Docelowe adresy e-mail mogą należeć do domen zewnętrznych. W takim przypadku domena docelowa musi skonfigurować rekord DMARC, aby wyrazić zgodę na ich otrzymywanie, w przeciwnym razie możliwe byłoby wykorzystanie raportowania do wzmacniania spamu . Załóżmy na przykład, że odbiorca.example odbiera wiadomość e-mail Od: ktoś@nadawca.example i chce to zgłosić. Jeśli znajdzie ruf=mailto:[email protected] , szuka potwierdzającego rekordu DNS w przestrzeni nazw administrowanej przez cel, na przykład: 

nadawca.przyklad._raport._dmarc.strona trzecia.przyklad IN TXT "v=DMARC1;"

Zbiorcze raporty

Raporty zbiorcze są wysyłane jako pliki XML , zazwyczaj raz dziennie. Temat wymienia „Domenę raportu”, która wskazuje nazwę domeny DNS, o której został wygenerowany raport, oraz „Dostawcę”, czyli podmiot wystawiający raport . Ładunek znajduje się w załączniku z długą nazwą pliku składającą się z elementów oddzielonych hukiem, takich jak odbiorca wysyłający raport, epoka początku i końca raportowanego okresu jako znaczniki czasu w stylu Uniksa, opcjonalny unikalny identyfikator i rozszerzenie, które zależy od możliwa kompresja (kiedyś .zip ).

Na przykład: przyklad.com!example.org!1475712000!1475798400.xml.gz .

Treść XML składa się z nagłówka zawierającego zasady, na których opiera się raport, oraz metadane raportu, po których następuje liczba rekordów. Rekordy można umieścić w bazie danych jako relację i przeglądać w formie tabelarycznej. Schemat XML jest zdefiniowany w Dodatku C do specyfikacji, a nieprzetworzony rekord jest przedstawiony w dmarc.org. Tutaj trzymamy się relacyjnego przykładu, który lepiej oddaje naturę danych. Rekordy DMARC można również bezpośrednio przekształcić w HTML, stosując arkusz stylów XSL .

Wiersze DMARC rekordu zbiorczego przedstawione w formie tabelarycznej
Adres IP źródła Liczyć Usposobienie SPF DKIM Nagłówek z Domena SPF (wynik) Domena DKIM (wynik)  
192.0.2.1 12 nic   ✓ Przepustka   ✓ Przepustka przykład.org   example.org ( ✓ Pass )   example.org ( ✓ Pass )  
192.0.2.1 1 nic   ✓ Przepustka   ✗ Niepowodzenie przykład.org   example.org ( ✓ Pass )   example.org ( ✗ Niepowodzenie )  
192.0.2.28 42 nic   ✗ Niepowodzenie   ✓ Przepustka przykład.org   example.org ( ✗ Niepowodzenie )   example.org ( ✓ Pass )   spedytor.example ( ✓ Pass )
192.0.2.82 21 nic   ✗ Niepowodzenie   ✗ Niepowodzenie przykład.org   lista dyskusyjna.example ( ✓ Pass )   example.org ( ✗ Niepowodzenie )   lista dyskusyjna.example ( ✓ Pass )
...

Wiersze są pogrupowane według źródłowego adresu IP i wyników uwierzytelniania, przekazując tylko liczbę każdej grupy. Skrajne lewe kolumny wyników, oznaczone SPF i DKIM , pokazują wyniki zgodne z DMARC, pozytywne lub negatywne, z uwzględnieniem wyrównania. Te najbardziej po prawej, z podobnymi etykietami, pokazują nazwę domeny, która twierdzi, że bierze udział w wysyłaniu wiadomości oraz (w nawiasach) status uwierzytelnienia tego roszczenia zgodnie z oryginalnym protokołem, SPF lub DKIM, niezależnie od wyrównania identyfikatora. Po prawej stronie SPF może pojawić się najwyżej dwa razy, raz w Return-Path: i raz w teście HELO ; DKIM może pojawić się raz dla każdego podpisu znajdującego się w wiadomości. W tym przykładzie pierwszy wiersz reprezentuje główny przepływ poczty z example.org, a drugi wiersz to usterka DKIM, na przykład uszkodzenie podpisu z powodu niewielkiej zmiany podczas przesyłania. Wiersze trzeci i czwarty przedstawiają odpowiednio typowe tryby awarii spedytora i listy mailingowej. Uwierzytelnianie DMARC nie powiodło się tylko dla ostatniego wiersza; mogłoby to wpłynąć na dyspozycję wiadomości, gdyby witryna example.org określiła ścisłą politykę.

Dyspozycja odzwierciedla opublikowaną politykę faktycznie stosowaną do wiadomości, brak , kwarantanna lub odrzucenie . Wraz z nim, nie pokazanym w tabeli, DMARC zapewnia obejście zasad. Niektóre powody, dla których odbiorca może zastosować politykę inną niż wnioskowana, zostały już uwzględnione w specyfikacji:

przekazywana
dalej z zachowaniem tego samego adresu zwrotnego, zwykle nie psuje DKIM,
próbkowana
, ponieważ nadawca może zdecydować się na zastosowanie polityki tylko do procentu wiadomości,
zaufany spedytor
wiadomość dotarła z lokalnie znanej źródłowej
listy mailingowej
odbiorca określany heurystycznie że wiadomość dotarła z listy mailingowej,
lokalni
odbiorcy polityki mogą oczywiście zastosować taką politykę, jaka im się podoba, po prostu fajnie jest poinformować nadawców,
inne
, jeśli żadne z powyższych nie ma zastosowania, pole komentarza pozwala powiedzieć więcej.

Raporty kryminalistyczne

Raporty kryminalistyczne, znane również jako raporty o błędach, są generowane w czasie rzeczywistym i składają się z zredagowanych kopii pojedynczych wiadomości, które nie powiodły się SPF, DKIM lub obu na podstawie wartości określonej w tagu fo . Ich format, będący rozszerzeniem Abuse Reporting Format , przypomina format zwykłych odrzuceń, ponieważ zawiera „message/rfc822” lub „text/rfc822-headers”.

Raporty kryminalistyczne zawierają również:

  • Źródło wysyłanego adresu IP
  • z adresu email
  • Adres e-mail odbiorcy
  • Temat wiadomości e-mail
  • Wyniki uwierzytelniania SPF i DKIM
  • Otrzymany czas
  • Nagłówki wiadomości e-mail, które obejmują wysyłającego hosta, identyfikator wiadomości e-mail, podpis DKIM i wszelkie inne niestandardowe informacje nagłówka.

Zgodność

Spedytorzy

Istnieje kilka różnych typów przekazywania poczty e-mail , a niektóre z nich mogą uszkodzić SPF. Jeden z powodów, dla których przekazywanie wiadomości e-mail może wpływać na wyniki uwierzytelniania DMARC.

Listy mailingowe

Listy mailingowe są częstą przyczyną uzasadnionego złamania podpisu DKIM domeny pierwotnego autora, na przykład poprzez dodanie prefiksu do nagłówka tematu. Możliwych jest wiele obejść, a pakiety oprogramowania list dyskusyjnych pracują nad rozwiązaniami.

Wyłącz wszystkie modyfikacje wiadomości

To obejście zachowuje standardowy przepływ pracy listy adresowej i jest stosowane przez kilku dużych operatorów list adresowych, ale wyklucza dodanie do listy stopek i prefiksów tematu. Wymaga to starannej konfiguracji oprogramowania pocztowego, aby upewnić się, że podpisane nagłówki nie zostaną zmienione ani zmodyfikowane. Źle skonfigurowany serwer pocztowy może umieszczać List-id w swoim DKIM wiadomości wysyłanych na listę mailingową, a następnie operator listy jest zmuszony go odrzucić lub przepisać From:.

Od: przepisywanie

Jednym z najpopularniejszych i najmniej inwazyjnych obejść jest przepisanie pola nagłówka From:. Adres pierwotnego autora można następnie dodać do pola Reply-To:. Przepisywanie może obejmować zwykłe dołączenie .INVALID do nazwy domeny, a także przydzielenie tymczasowego identyfikatora użytkownika, w którym używany jest nieprzejrzysty identyfikator, który utrzymuje „prawdziwy” adres e-mail użytkownika jako prywatny z listy. Ponadto nazwę wyświetlaną można zmienić tak, aby wyświetlała zarówno autora, jak i listę (lub operatora listy). Przykłady te skutkowałyby odpowiednio jedną z następujących sytuacji: 

   
   
     
    Od:  John  Doe  <uż[email protected]>  Od:  John  Doe  <[email protected]>  Od:  John  Doe  przez  MailingList  <[email protected]>  Odpowiedz do:  John  Doe  <user@ przykład.com>

Ostatni wiersz, Reply-To: , musi być zaprojektowany w celu dostosowania funkcji odpowiedzi do autora, w którym to przypadku funkcja odpowiedzi do listy jest objęta poprzednią zmianą w polu nagłówka From :. W ten sposób pierwotne znaczenie tych pól zostaje odwrócone.

Zmiana autora jest generalnie niesprawiedliwa i może zerwać oczekiwany związek między znaczeniem a wyglądem tego punktu odniesienia. Psuje również automatyczne korzystanie z niego. Istnieją społeczności, które używają list adresowych do koordynowania swojej pracy i wdrażają narzędzia, które używają Od: do przypisywania autorstwa załącznikom.

Inne obejścia

Zawijanie wiadomości działa dobrze dla tych, którzy używają klienta poczty e-mail, który rozumie opakowane wiadomości. Niedokonywanie żadnych zmian jest prawdopodobnie najbardziej oczywistym rozwiązaniem, z wyjątkiem tego, że wydaje się, że są one prawnie wymagane w niektórych krajach, a rutynowa utrata uwierzytelnienia SPF może sprawić, że ogólne uwierzytelnienie będzie bardziej kruche.

Pole nadawcy

Dokonanie zmian w polu nagłówka Od: w celu przejścia wyrównania DKIM może spowodować, że wiadomość nie będzie zgodna z RFC 5322 sekcja 3.6.2: „Pole „Od:” określa autora (autorów) wiadomości, czyli skrzynkę pocztową ( es) osoby lub systemu odpowiedzialnego za napisanie wiadomości." Skrzynka pocztowa odnosi się do adresu e-mail autora. Nagłówek Sender: jest dostępny, aby wskazać, że wiadomość e-mail została wysłana w imieniu innego podmiotu, ale DMARC sprawdza zasady tylko dla domeny nadawcy i ignoruje domenę nadawcy.

Zarówno ADSP, jak i DMARC odrzucają użycie pola nadawcy z powodów nietechnicznych, ponieważ wiele programów klienckich nie wyświetla tego odbiorcy.

Historia

Projekt specyfikacji DMARC jest utrzymywany od 30 stycznia 2012 r.

W październiku 2013 GNU Mailman 2.1.16 został wydany z opcjami obsługi plakatów z domeny z polityką DMARC p=reject . Zmiana miała na celu przewidzenie problemów z interoperacyjnością oczekiwanych w przypadku zastosowania restrykcyjnych zasad do domen z użytkownikami ludzkimi (w przeciwieństwie do domen pocztowych czysto transakcyjnych).

W kwietniu 2014 r. Yahoo zmieniło swoją politykę DMARC na p=reject , powodując w ten sposób niewłaściwe zachowanie na kilku listach mailingowych. Kilka dni później AOL zmienił również swoją politykę DMARC na p=reject . Te posunięcia spowodowały znaczne zakłócenia, a ci dostawcy skrzynek pocztowych zostali oskarżeni o przerzucanie kosztów własnych awarii bezpieczeństwa na strony trzecie. Od 2020 r. FAQ na oficjalnej wiki DMARC zawiera kilka sugestii dotyczących list mailingowych do obsługi wiadomości z domeny o surowych zasadach DMARC, z których najczęściej wdrażaną jest lista mailingowa zmieniająca nagłówek „Od” na adres w swoim własna domena.

Grupa robocza IETF została utworzona w sierpniu 2014 r. W celu rozwiązania problemów DMARC, zaczynając od kwestii interoperacyjności i ewentualnie kontynuując poprawioną standardową specyfikację i dokumentację. W międzyczasie istniejąca specyfikacja DMARC osiągnęła stan redakcyjny uzgodniony i wdrożony przez wielu. Został opublikowany w marcu 2015 r. W strumieniu Independent Submission w kategorii „Informacyjne” (niestandardowe) jako RFC 7489.

W marcu 2017 roku Federalna Komisja Handlu opublikowała badanie dotyczące wykorzystania DMARC przez firmy. Spośród 569 firm badanie wykazało, że około jedna trzecia wdrożyła dowolną konfigurację DMARC, mniej niż 10% używało DMARC do instruowania serwerów, aby odrzucały nieuwierzytelnione wiadomości, a większość wdrożyła SPF.

Współtwórcy

Współautorzy specyfikacji DMARC to:

Zobacz też

Notatki

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=DMARC&oldid=1138765095 ”