ARC (Authenticated Received Chain) to standard uwierzytelniania poczty, który pozwala pośrednikowi, takiemu jak lista mailingowa czy usługa przekazywania wiadomości, zapisać wyniki SPF, DKIM i DMARC, które zaobserwował, zanim zmodyfikował lub przekazał wiadomość dalej. Powstał, ponieważ przekazywanie poczty rutynowo psuje SPF i DKIM, przez co legalne wiadomości nie przechodzą kontroli DMARC w miejscu docelowym. ARC nie zastępuje DMARC. Daje końcowemu odbiorcy kryptograficznie podpisany zapis tego, jak wyglądało uwierzytelnianie wcześniej na drodze dostarczania, dzięki czemu wiadomość od zaufanego serwera przekazującego może przetrwać rygorystyczną politykę.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Problem, który rozwiązuje ARC
Uwierzytelnianie poczty zostało zaprojektowane z myślą o bezpośrednim dostarczaniu: serwer wysyłający łączy się z serwerem odbierającym, a zarówno SPF, jak i DKIM są oceniane względem tego pojedynczego przeskoku. Rzeczywisty ruch pocztowy jest bardziej skomplikowany. Wiadomości są przekazywane na nowy adres, przepisywane przez listę mailingową lub przesyłane przez bramę bezpieczeństwa. Każdy z tych pośredników może zepsuć uwierzytelnianie w sposób, którego pierwotny nadawca nigdy nie zamierzał.
- SPF sprawdza łączący się IP względem autoryzowanych nadawców domeny. Gdy serwer przekazujący przesyła wiadomość dalej, łączący się IP to teraz ten serwer, a nie pierwotny nadawca, więc SPF zawodzi. Zagadnienie to szczegółowo omawia dlaczego przekazywanie poczty psuje SPF.
- DKIM podpisuje konkretne nagłówki i treść wiadomości. Lista mailingowa, która dopisuje stopkę, przepisuje temat lub zmienia kodowanie, unieważnia skrót treści DKIM, więc podpis przestaje się weryfikować. Ta awaria wygląda identycznie jak niezgodność skrótu treści DKIM spowodowana jakąkolwiek inną zmianą w trakcie tranzytu.
Gdy zarówno SPF, jak i DKIM zawodzą przy ostatnim przeskoku, DMARC nie ma czego dopasować, więc wiadomość nie przechodzi kontroli. Jeśli nadawca publikuje p=reject, taka przekazana wiadomość jest odrzucana lub poddawana kwarantannie, choć była w pełni legalna. ARC powstał, aby zamknąć tę lukę.
Co ARC właściwie robi
ARC jest zdefiniowany w RFC 8617, opublikowanym w lipcu 2019 roku ze statusem eksperymentalnym. Podstawowa idea jest prosta: każdy uczestnik ARC, który obsługuje wiadomość, zapisuje zaobserwowane wyniki uwierzytelniania oraz kryptograficznie podpisuje zarówno ten zapis, jak i stan wszelkich wcześniejszych zapisów. Rezultatem jest uporządkowany, odporny na manipulacje łańcuch pieczy nad wiadomością.
Gdy odbiorca na końcu drogi weryfikuje łańcuch, może odczytać wyniki uwierzytelniania widziane przez pierwszego uczestnika ARC, zanim doszło do jakiegokolwiek przekazywania czy przetwarzania przez listę. Jeśli DKIM nadawcy przeszedł kontrolę w momencie, gdy wiadomość po raz pierwszy trafiła do zaufanego serwera przekazującego, końcowy odbiorca może to zobaczyć, mimo że podpis nie weryfikuje się już po dodaniu stopki.
ARC nigdy sam z siebie nie uwierzytelnia pierwotnego autora. Uwierzytelnia pośredników i zachowuje zebrane przez nich dowody. Zaufanie wciąż trzeba sobie wypracować: odbiorca korzysta z ARC tylko wtedy, gdy ufa pośrednikom, którzy zapieczętowali łańcuch.
Trzy pola nagłówka ARC
Każdy uczestnik ARC dodaje zestaw ARC: trzy pola nagłówka, które współdzielą ten sam numer instancji, przenoszony w znaczniku i=. Pierwszy pośrednik używa i=1, drugi i=2 i tak dalej. RFC 8617 ogranicza wartość instancji do 50, więc łańcuch może zawierać najwyżej 50 zestawów ARC, zanim odbiorcy przestaną go przetwarzać.
| Pole nagłówka | Skrót | Przeznaczenie |
|---|---|---|
ARC-Authentication-Results | AAR | Zamrożona migawka wyników SPF, DKIM i DMARC zaobserwowanych na tym przeskoku |
ARC-Message-Signature | AMS | Podpis podobny do DKIM obejmujący nagłówki i treść wiadomości w postaci widzianej na tym przeskoku |
ARC-Seal | AS | Podpis wiążący bieżący AAR i AMS ze wszystkimi wcześniejszymi zestawami ARC |
ARC-Authentication-Results (AAR)
AAR to w istocie kopia standardowego nagłówka Authentication-Results, zachowana w przestrzeni nazw ARC, aby późniejsze przeskoki nie mogły jej po cichu odrzucić. Podaje, co zaobserwował pośrednik: na przykład że spf=pass i dkim=pass dla pierwotnej domeny wysyłającej. Jeśli już wiesz, jak czytać zwykły nagłówek wyników, AAR będzie ci znajomy. Przewodnik jak czytać nagłówek Authentication-Results ma tu bezpośrednie zastosowanie.
ARC-Message-Signature (AMS)
AMS działa jak podpis DKIM. Podpisuje nagłówki i treść wiadomości w postaci istniejącej na tym przeskoku, używając własnej domeny i selektora pośrednika. Ponieważ utrwala stan wiadomości w momencie pieczętowania, późniejszy weryfikator może potwierdzić, że treść nie zmieniła się od chwili, gdy ten pośrednik obsłużył wiadomość. AMS używa tej samej struktury znaczników co DKIM, w tym d= dla domeny podpisującej i s= dla selektora.
ARC-Seal (AS)
ARC-Seal to element, który czyni z łańcucha łańcuch. Podpisuje pola nagłówków ARC-Seal, ARC-Message-Signature i ARC-Authentication-Results wszystkich instancji, aż do bieżącej włącznie. Właśnie dlatego żaden pośrednik nie może usunąć ani zmienić kolejności wcześniejszych zestawów ARC bez zerwania pieczęci.
ARC-Seal przenosi znacznik cv= (chain validation), który zapisuje wynik weryfikacji łańcucha istniejącego już w chwili, gdy ten przeskok otrzymał wiadomość:
cv=none: nie było wcześniejszego łańcucha ARC. Jest to wymagane dla pierwszego zestawu,i=1.cv=pass: istniejący łańcuch został pomyślnie zweryfikowany. Wymagane dla każdego zestawu, w którymijest większe niż 1.cv=fail: istniejący łańcuch nie przeszedł weryfikacji.
Dwie reguły utrzymują poprawny łańcuch w uczciwości. Wartość cv= przy i=1 musi wynosić none, a dla każdego kolejnego zestawu musi wynosić pass, więc poprawnie przechodzący łańcuch nigdzie nie zawiera cv=fail. Gdy pośrednik otrzymuje wiadomość, której przychodzący łańcuch jest już zepsuty, może mimo to dodać końcowy zestaw ARC oznaczony cv=fail, aby zapisać niepowodzenie. Ten pieczętujący zestaw obejmuje wyłącznie własne nagłówki, a nie zepsute zestawy pod nim, i oznacza łańcuch jako martwy: żaden uczestnik nie dodaje kolejnych zestawów na wierzch cv=fail, a odbiorcy poniżej traktują taki łańcuch jako niezaufany.
Jak odbiorca korzysta z ARC
W miejscu docelowym serwer odbierający pocztę uruchamia DMARC jak zwykle. Jeśli zarówno SPF, jak i DKIM zawiodą i DMARC w innym razie by nie przeszedł, odbiorca może wówczas spojrzeć na łańcuch ARC jako na dodatkowy sygnał. Proces wygląda następująco:
- Zweryfikuj cały łańcuch ARC, sprawdzając po kolei każdą pieczęć ARC-Seal i potwierdzając, że każda wartość
cv=przestrzega powyższych reguł. - Jeśli łańcuch się weryfikuje, odczytaj najwcześniejszy AAR, aby zobaczyć pierwotne wyniki SPF, DKIM i DMARC.
- Zdecyduj, czy pośrednicy, którzy zapieczętowali łańcuch, są zaufani. Zweryfikowany łańcuch od nieznanego serwera przekazującego jest wart niewiele; zweryfikowany łańcuch od znanego, cieszącego się dobrą reputacją serwera przekazującego jest wart bardzo dużo.
- Opcjonalnie zastosuj lokalne nadpisanie polityki: dostarcz wiadomość mimo niepowodzenia DMARC, ponieważ dowody ARC pokazują, że została poprawnie uwierzytelniona, zanim zaufany serwer przekazujący ją zmodyfikował.
Dlatego właśnie ARC jest narzędziem lokalnej polityki, a nie automatycznym nadpisaniem. Specyfikacja celowo pozostawia decyzję o zaufaniu odbiorcy. Duzi dostawcy realizują to za pomocą list zaufanych podmiotów pieczętujących. Zarówno Google Workspace, jak i Microsoft 365 pozwalają administratorom wyznaczyć konkretne domeny pieczętujące ARC jako zaufane, a tylko łańcuchy zapieczętowane przez te domeny wpływają na decyzję o dostarczeniu. Bez relacji zaufania weryfikujący się łańcuch jest odnotowywany, ale nie zmienia wyniku.
ARC i DMARC razem
ARC najlepiej rozumieć jako warstwę naprawczą dla martwego pola DMARC związanego z przekazywaniem poczty. DMARC nadal rządzi polityką: czy nieuwierzytelniona poczta ma być dostarczona, poddana kwarantannie czy odrzucona i dokąd wysyłane są raporty. Wdrożenie ARC w żaden sposób nie zmienia twojego rekordu DMARC ani przejścia od p=none do p=reject.
| Warstwa | Co sprawdza | Co ją psuje | Co dodaje ARC |
|---|---|---|---|
| SPF | Łączący się IP wobec autoryzowanych nadawców | Przekazywanie zmienia IP | Zachowuje pierwotne spf=pass |
| DKIM | Podpis obejmujący nagłówki i treść | Stopki list i przepisywanie nagłówków | Zachowuje pierwotne dkim=pass |
| DMARC | Dopasowanie SPF lub DKIM do domeny From | Niepowodzenie obu leżących u podstaw kontroli | Dostarcza dowód do nadpisania polityki |
Dla właściciela domeny ARC jest głównie czymś, co wdrażają twoje serwery przekazujące i odbierające, a nie czymś, co konfigurujesz na własnej domenie w taki sposób, w jaki ustawiasz SPF, DKIM i DMARC. Nadal poprawnie publikujesz te trzy rekordy, ponieważ ARC zachowuje jedynie wyniki, które w ogóle zaistniały. Jeśli twój podpis DKIM był nieprawidłowy przed przekazaniem, ARC wiernie odnotuje tę awarię i nic się nie poprawi.
Gdzie ARC pomaga, a gdzie nie
ARC znacząco redukuje fałszywe niepowodzenia DMARC dla wiadomości, które przechodzą przez listy mailingowe, usługi przekazywania i produkty bramowe uczestniczące w łańcuchu. To jeden z powodów, dla których członek listy dyskusyjnej wciąż może otrzymywać posty od nadawców publikujących p=reject.
ARC nie pomaga, gdy żaden pośrednik na drodze go nie wdraża, gdy odbiorca nie ufa podmiotowi pieczętującemu lub gdy wiadomość od początku nie była uwierzytelniona. Sam z siebie nie jest też mechanizmem chroniącym przed podszywaniem się. Wiadomość sfałszowana od zera nie ma legalnego łańcucha ARC, a łańcuch zapieczętowany przez niezaufaną stronę nie ma żadnej wagi. Jeśli twoim celem jest powstrzymanie podszywania się pod twoją domenę, wciąż sprowadza się to do publikowania i egzekwowania DMARC.
Najczęściej zadawane pytania
Czy muszę konfigurować ARC na swojej domenie wysyłającej?
Zazwyczaj nie. ARC jest stosowany przez pośredników, którzy przekazują lub przetwarzają twoją pocztę, i jest wykorzystywany przez serwery odbierające w miejscu docelowym. Twoim zadaniem jako właściciela domeny jest zadbać, aby SPF, DKIM i DMARC były poprawne u źródła, ponieważ ARC zachowuje jedynie wyniki uwierzytelniania, które już przeszły kontrolę.
Czym ARC-Message-Signature różni się od zwykłego podpisu DKIM?
Oba są kryptograficznymi podpisami obejmującymi treść wiadomości z użyciem domeny i selektora, ale podpis DKIM przyjmuje odpowiedzialność za wiadomość jako autor lub nadawca. ARC-Message-Signature dokumentuje stan wiadomości na przeskoku pośrednika i jest wiązany w łańcuch ARC przez ARC-Seal, dzięki czemu przetrwa nawet po tym, jak późniejsze przeskoki zmodyfikują wiadomość.
Czy poprawny łańcuch ARC gwarantuje dostarczenie mojej przekazanej poczty?
Nie. Poprawny łańcuch daje odbiorcy jedynie dowód, na podstawie którego może, ale nie musi, podjąć działanie. Dostarczenie zależy od tego, czy odbiorca ufa pośrednikom, którzy zapieczętowali łańcuch. Dostawcy tacy jak Google i Microsoft honorują ARC tylko od podmiotów pieczętujących, które administrator wyraźnie oznaczył jako zaufane.
Czy ARC może posłużyć do sfałszowania wyników uwierzytelniania?
Atakujący może dodać nagłówki ARC deklarujące cokolwiek, ale pieczęć ma znaczenie tylko wtedy, gdy domena pieczętująca jest jedną z tych, którym odbiorca ufa. Niezaufany lub nieprawidłowy łańcuch nie ma żadnej wagi, więc ARC nie tworzy nowej drogi do podszywania się, o ile odbiorcy właściwie stosują zaufanie.
Przekazywanie poczty i listy mailingowe to najczęstszy powód, dla którego legalna poczta nie przechodzi kontroli DMARC, a leżącą u podstaw przyczyną jest niemal zawsze problem z SPF lub DKIM u źródła. Uruchom darmowe skanowanie w SPFWise, aby potwierdzić, że twoje rekordy SPF, DKIM i DMARC są dopasowane i prawidłowe, zanim jakikolwiek serwer przekazujący dotknie twojej poczty.