DMARC - DMARC

DMARC ( Domain-based Message Authentication, Reporting and Conformance ) to protokół uwierzytelniania poczty e-mail . Został zaprojektowany, aby dać właścicielom domen pocztowych 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 atakami na firmową pocztę e - mail , phishingiem , oszustwami e- mail i innymi działaniami związanymi z cyberzagrożeniami .

Po opublikowaniu wpisu DMARC DNS każdy odbierający serwer 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 uwierzytelnianie, zostanie dostarczona i można jej zaufać. Jeśli wiadomość e-mail nie przejdzie kontroli, w zależności od instrukcji zawartych w rekordzie DMARC wiadomość e-mail może zostać dostarczona, poddana kwarantannie lub odrzucona. Na przykład jedna usługa przekazywania poczty e-mail dostarcza pocztę, ale jako „Od: brak odpowiedzi@<usługa przekazywania>”.

DMARC rozszerza dwa istniejące mechanizmy uwierzytelniania poczty elektronicznej, Sender Policy Framework (SPF) i DomainKeys Identified Mail (DKIM). Pozwala właścicielowi administracyjnemu domeny opublikować zasady w swoich rekordach DNS, aby określić, który mechanizm (DKIM, SPF lub oba) jest stosowany podczas wysyłania wiadomości e-mail z tej domeny; jak sprawdzić From:pole prezentowane użytkownikom końcowym; sposób, w jaki odbiorca powinien radzić sobie z awariami – oraz mechanizm raportowania działań wykonywanych w ramach tych polityk.

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

Przegląd

Zasady DMARC pozwalają domenie nadawcy wskazać, że jego wiadomości e-mail są chronione przez SPF i/lub DKIM, i mówią odbiorcy, co zrobić, jeśli żadna z tych metod uwierzytelniania nie przejdzie – 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 zgłaszać do domeny nadawcy wiadomości, które przeszły i/lub zakończyły się niepowodzeniem.

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

DMARC nie odnosi się bezpośrednio do tego, czy wiadomość e-mail jest spamem lub w inny sposób oszukańcza. Zamiast tego DMARC może wymagać, aby wiadomość nie tylko przeszła weryfikację DKIM lub SPF, ale również przeszła wyrównanie . W systemie DMARC wiadomość może się nie powieść, nawet jeśli przejdzie pomyślnie SPF lub DKIM, ale nie powiedzie się wyrównanie.

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

Wyrównanie

DMARC działa, sprawdzając, czy domena w polu wiadomości From:(zwana również „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.

Dopasowanie może być określone jako ścisłe lub rozluźnione. W celu dokładnego wyrównania nazwy domen muszą być identyczne. W celu ułatwienia wyrównania górna domena „Domena organizacyjna” musi być zgodna. Domenę organizacyjną można znaleźć, sprawdzając listę publicznych sufiksów DNS i dodając kolejną etykietę DNS. Na przykład „abcdexample.com.au” i „example.com.au” mają tę samą domenę organizacyjną, ponieważ istnieje rejestrator, który oferuje klientom nazwy w „.com.au”. Chociaż w czasie specyfikacji DMARC istniała grupa robocza IETF ds. granic domen, obecnie domena organizacyjna może być wyprowadzona tylko z Publicznej Listy Sufiksów .

Podobnie jak SPF i DKIM, DMARC wykorzystuje koncepcję właściciela domeny, czyli 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óra pojawia się w MAIL FROMpoleceniu SMTP . (Adres e-mail w MAIL FROM jest również nazywany adresem zwrotnym , koperta-z lub RFC5321.MailFrom.) Oprócz wymagania przejścia sprawdzania SPF, DMARC sprawdza, czy RFC5321.MailFrom jest zgodny z 5322.From.

DKIM umożliwia kryptograficzne podpisanie części wiadomości e-mail, a podpis musi zakrywać pole Od. W nagłówku poczty DKIM-Signature tagi d=(domena) i s=(selektor) określają, gdzie w systemie DNS ma zostać pobrany klucz publiczny podpisu. Prawidłowy podpis dowodzi, że osoba podpisująca 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 prawidłowego podpisu, w którym domena w d=tagu jest zgodna z domeną nadawcy podaną w From:polu nagłówka.

rekord DNS

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

Zawartość rekordu zasobu TXT składa się ze name=valueznaczników oddzielonych średnikami, podobnie jak w przypadku SPF i DKIM. Na przykład:

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

Oto vwersja, ppolityka (patrz poniżej), sppolityka subdomeny, pctprocent „złych” wiadomości e-mail, do których należy zastosować politykę, oraz ruaidentyfikator URI, do którego należy wysyłać raporty zbiorcze. W tym przykładzie jednostka kontrolująca domenę DNS example.com zamierza monitorować współczynniki niepowodzeń SPF i/lub DKIM i nie oczekuje wysyłania e-maili z subdomen domeny example.com. Pamiętaj, że subdomena może publikować swój własny rekord DMARC; odbiorcy muszą to sprawdzić przed powrotem do rekordu domeny organizacji.

Adopcja krok po kroku

Protokół zapewnia różne tryby zapadkowe lub stany przejściowe, aby umożliwić administratorom poczty stopniowe przejście od niewdrażania DMARC w ogóle do nieustępliwej konfiguracji. Koncepcja stopniowej adopcji zakłada, że ​​celem DMARC jest najsilniejsze ustawienie, co nie dotyczy wszystkich domen. Niezależnie od intencji mechanizmy te pozwalają na większą elastyczność.

Polityka

Przede wszystkim istnieją trzy zasady:

• żadna nie jest polityką na poziomie podstawowym. Odbiorcy nie wymagają specjalnego traktowania, ale umożliwiają domenie otrzymywanie raportów z opiniami.
• kwarantanna prosi odbiorców o traktowanie z podejrzeniem wiadomości, które nie przejdą sprawdzenia DMARC. Różni odbiorcy mają do tego różne sposoby, na przykład oznaczanie wiadomości lub dostarczanie ich do folderu spamu.
• Odrzuć prosi odbiorców o odrzucenie wiadomości, które nie przejdą sprawdzenia DMARC.

Opublikowane zasady można złagodzić, stosując je tylko do odsetka wiadomości, które nie przejdą sprawdzenia DMARC. Odbiorcy są proszeni o wybranie określonego procentu wiadomości za pomocą prostego algorytmu próbkowania Bernoulliego . Pozostałe wiadomości powinny podlegać niższej polityce; to znaczy brak, jeśli p=quarantine, poddaj kwarantannie, jeśli p=reject. Jeśli nie określono, pct domyślnie 100% wiadomości. Ten przypadek p=quarantine; pct=0;jest używany do zmuszania menedżerów list dyskusyjnych do przepisywania pola Od:, ponieważ niektórzy nie robią tego, gdy p=none.

Wreszcie polityka subdomen sp=i nowo dodana polityka braku domeny pozwalają dostosować politykę dla określonych subdomen.

Raporty

DMARC może generować dwa oddzielne typy raportów. Raporty zbiorcze są wysyłane na adres podany po rua. Raporty kryminalistyczne są wysyłane e-mailem na adres następujący po ruftagu. Te adresy e-mail muszą być określone w formacie 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 raportów do wzmocnienia spamu . Na przykład, powiedzmy, że receiver.exampleotrzymuje wiadomość e-mail From: [email protected]i chce ją zgłosić. Jeśli znajdzie ruf=mailto:[email protected], szuka potwierdzającego rekordu DNS w przestrzeni nazw administrowanej przez cel, na przykład:

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

Raporty zbiorcze

Raporty zbiorcze są wysyłane jako pliki XML , zazwyczaj raz dziennie. Przedmiotem wzmianki „Zgłoś domena”, który wskazuje nazwę domeny DNS, o którym raport został wygenerowany, a „Nadesłał”, która jest podmiotem wydawania raportu. Ładunek znajduje się w załączniku o długiej nazwie pliku składającej się z elementów oddzielonych od siebie, takich jak odbiorca wydający raport, początek i koniec okresu raportowanego jako znaczniki czasu w stylu Uniksa, opcjonalny unikalny identyfikator i rozszerzenie, które zależy od możliwa kompresja (kiedyś .zip).

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

Zawartość XML składa się z nagłówka zawierającego zasady, na których opiera się raport, oraz metadanych raportu, po których następuje szereg rekordów. Rekordy mogą być umieszczane w bazie danych jako relacja i przeglądane w formie tabelarycznej. Schemat XML jest zdefiniowany w Załączniku C specyfikacji, a surowy rekord jest zilustrowany w dmarc.org. Tutaj trzymamy się relacyjnego przykładu, który lepiej oddaje charakter danych. Rekordy DMARC można również bezpośrednio przekształcić w HTML, stosując arkusz stylów XSL .

Wiersze są pogrupowane według źródłowego adresu IP i wyników uwierzytelniania, przekazując tylko liczbę każdej grupy. Kolumny wyników znajdujące się najbardziej po lewej stronie, oznaczone SPF i DKIM, pokazują wyniki zgodne z DMARC, pozytywne lub negatywne, z uwzględnieniem wyrównania. Te z prawej strony, z podobnymi etykietami, pokazują nazwę domeny, która twierdzi, że bierze udział w wysłaniu wiadomości oraz (w nawiasach) status uwierzytelnienia tego roszczenia zgodnie z oryginalnym protokołem, SPF lub DKIM, niezależnie od dopasowania identyfikatora. Po prawej stronie SPF może pojawić się co najwyżej dwa razy, raz dla Return-Path:testu i raz dla HELOtestu; DKIM może pojawić się raz dla każdego podpisu zawartego 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 złamanie podpisu spowodowane drobną zmianą w tranzycie. Trzeci i czwarty wiersz pokazują typowe tryby awarii odpowiednio forwardera i listy mailingowej. Uwierzytelnianie DMARC nie powiodło się tylko dla ostatniego wiersza; mogło to wpłynąć na dyspozycję wiadomości, gdyby example.org określiła ścisłą politykę.

Dyspozycja odzwierciedla politykę opublikowany faktycznie zastosowane do wiadomości, nikt , kwarantannie lub odrzucić . Wraz z nim, nie pokazane w tabeli, DMARC zapewnia nadpisanie zasad. Niektóre powody, dla których odbiorca może zastosować inną politykę niż ta, o którą prosi, są już podane w specyfikacji:

przekazane

zachowując ten sam adres zwrotny, zwykle nie psuje DKIM,

próbkowane

ponieważ nadawca może zastosować zasadę tylko do procentu wiadomości,

zaufany spedytor

wiadomość przyszła z lokalnie znanego źródła

Lista mailingowa

odbiorca heurystycznie ustalił, że wiadomość pochodzi z listy mailingowej,

polityka lokalna

odbiorcy mają oczywiście swobodę w stosowaniu polityki, którą lubią, fajnie jest poinformować nadawców,

inny

jeśli żadne z powyższych nie ma zastosowania, pole komentarza pozwala powiedzieć więcej.

Raporty kryminalistyczne

Raporty śledcze, znane również jako raporty o niepowodzeniach, są generowane w czasie rzeczywistym i składają się z redagowanych kopii poszczególnych e-maili, których SPF, DKIM lub oba te błędy nie zadziałały, w zależności od wartości określonej w fotagu. Ich format, będący rozszerzeniem Abuse Reporting Format , przypomina zwykłe odrzucenia, ponieważ zawierają „message/rfc822” lub „text/rfc822-headers”.

Raporty kryminalistyczne zawierają również:

- Źródło wysyłania adresu IP

- Z adresu email

- Adres e-mail odbiorcy

- Wiersz tematu wiadomości e-mail

- Wyniki uwierzytelniania SPF i DKIM

- Otrzymany czas

- Nagłówki wiadomości e-mail, które zawierają hosta wysyłającego, 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 , z których niektóre mogą łamać SPF.

Listy mailingowe

Listy mailingowe są częstą przyczyną legalnego złamania podpisu DKIM domeny oryginalnego autora, na przykład poprzez dodanie prefiksu do nagłówka tematu. Możliwe są różne obejścia, a pakiety oprogramowania do obsługi list mailingowych pracują nad rozwiązaniami.

Wyłącz wszystkie modyfikacje wiadomości

To obejście zachowuje standardowy przepływ pracy listy dyskusyjnej i jest stosowane przez kilku dużych operatorów list dyskusyjnych, ale uniemożliwia dodawanie stopek i przedrostków tematu do listy. Wymaga to starannej konfiguracji oprogramowania pocztowego, aby upewnić się, że podpisane nagłówki nie są zmieniane ani modyfikowane. Źle skonfigurowany serwer pocztowy może list-id w swoim DKIM wiadomości wysłanych na listę dyskusyjną, a następnie operator listy jest zmuszony do odrzucenia lub przepisania From:.

From: przepisanie

Jedno z najpopularniejszych i najmniej inwazyjnych obejść polega na przepisaniu From:pola nagłówka. Następnie do Reply-To:pola można dodać oryginalny adres autora . Przepisywanie może wahać się od dodania .INVALIDdo nazwy domeny, do przydzielania tymczasowego identyfikatora użytkownika, gdy używany jest nieprzezroczysty identyfikator, dzięki czemu „prawdziwy” adres e-mail użytkownika pozostaje prywatny na liście. Ponadto nazwę wyświetlaną można zmienić tak, aby wyświetlał zarówno autora, jak i listę (lub operator listy). Te przykłady skutkowałyby odpowiednio jednym z:

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

Ostatnia linia, Reply-To:, musi być zaprojektowana w celu dostosowania funkcji odpowiedzi do autora w przypadku, gdy funkcja odpowiedzi na listę jest objęta poprzednią zmianą w From:polu nagłówka. 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. Przerywa również zautomatyzowane korzystanie z niego. Istnieją społeczności, które używają list mailingowych do koordynowania swojej pracy i wdrażają narzędzia, które wykorzystują to From:pole do przypisywania autorstwa do załączników.

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. Niewprowadzanie żadnych zmian jest prawdopodobnie najbardziej oczywistym rozwiązaniem, z wyjątkiem tego, że w niektórych krajach wydaje się, że jest to prawnie wymagane, a rutynowa utrata uwierzytelniania SPF może sprawić, że ogólne uwierzytelnienie będzie bardziej kruche.

Pole nadawcy

Wprowadzanie zmian w From:polu nagłówka w celu przekazania wyrównania DKIM może spowodować, że wiadomość będzie niezgodna z sekcją 3.6.2 RFC 5322: „Pole „Od:” określa autora (autorów) wiadomości, czyli skrzynki pocztowe. osoby (osób) lub systemu (systemów) odpowiedzialnych za napisanie wiadomości." Skrzynka pocztowa odnosi się do adresu e-mail autora. Sender:Nagłówek jest dostępny, aby wskazać, że e-mail został wysłany w imieniu innej osoby, ale DMARC polityka sprawdza tylko dla Od domeny i ignoruje domeny nadawcy.

Zarówno ADSP, jak i DMARC odrzucają użycie pola Nadawca na podstawie nietechnicznej, ponieważ wiele programów użytkownika nie wyświetla tego odbiorcy.

Historia

Projekt specyfikacji DMARC jest utrzymywany od 30 stycznia 2012 roku.

W październiku 2013 wydano GNU Mailman 2.1.16 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 czysto transakcyjnych domen pocztowych).

W kwietniu 2014 r. Yahoo zmieniło swoją politykę DMARC na p=reject, co spowodowało niewłaściwe zachowanie na kilku listach mailingowych. Kilka dni później firma AOL zmieniła również swoją politykę DMARC na p=reject. Te posunięcia spowodowały znaczne zakłócenia, a dostawcy skrzynek pocztowych zostali oskarżeni o narzucanie osobom trzecim kosztów własnych awarii bezpieczeństwa. Od 2020 r. FAQ na oficjalnej wiki DMARC zawiera kilka sugestii dotyczących list dyskusyjnych do obsługi wiadomości z domeny ze ścisłą polityką DMARC, z których najszerzej zaimplementowaną jest zmiana nagłówka „Od” na adres w jej własna domena.

Grupa robocza IETF została utworzona w sierpniu 2014 r. w celu zajęcia się kwestiami DMARC, zaczynając od problemów z interoperacyjnością i ewentualnie kontynuując zmodyfikowaną standardową specyfikację i dokumentację. Tymczasem 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ółtwórcami specyfikacji DMARC są:

• Odbiorniki: AOL , Comcast , Google ( Gmail ), Mail.ru , Microsoft ( Outlook.com , Hotmail ), NetEase (163.com, 126.com, 188.com, yeah.net) XS4ALL , Yahoo , Yandex
• Nadawcy: American Greetings , Bank of America , Facebook , Fidelity Investments , JPMorganChase , LinkedIn , PayPal , Twitter
• Pośrednicy i dostawcy: Agari (założyciel/CEO Patrick R. Peterson), Cloudmark, Red Sift , ReturnPath , Trusted Domain Project

Zobacz też

• Uwierzytelniony łańcuch odebrany (ARC)
• Autorskie praktyki podpisywania domen
• Zidentyfikowana poczta DomainKeys (DKIM)
• Potwierdzenie email
• Certyfikowany e-mail
• Serwery pocztowe z DMARC
• Zasady dotyczące nadawców (SPF)

Uwagi

Bibliografia

Zewnętrzne linki

• Oficjalna strona internetowa
• Wiki The Anti Spam Research Group: Łagodzenie szkód DMARC dotyczących poczty od osób trzecich