RFC 8617 – ARC

RFC 8617 opisuje mechanizm ARC, pozwalający zachować wyniki uwierzytelnienia mimo pośredniczących serwerów.

ARC jako zapis kolejnych ocen uwierzytelnienia wiadomości

RFC 8617 opisuje ARC, czyli Authenticated Received Chain, mechanizm przeznaczony dla poczty elektronicznej przechodzącej przez pośredniczące systemy. Typowy problem pojawia się wtedy, gdy wiadomość po sprawdzeniu przez pierwszy serwer trafia do listy dyskusyjnej, usługi przekazującej albo innego pośrednika, który zmienia nagłówki, treść lub dane koperty SMTP. Takie zmiany mogą spowodować niepowodzenie późniejszej weryfikacji DKIM albo niespełnienie warunków DMARC, mimo że wcześniejszy serwer poprawnie ocenił wiadomość w chwili jej otrzymania.

ARC nie usuwa tych zmian i nie przywraca ważności pierwotnego podpisu DKIM. Jego zadaniem jest zachowanie kolejnych ocen uwierzytelnienia oraz informacji o drodze wiadomości. Każdy uczestniczący serwer może dołączyć własne świadectwo dotyczące wyniku kontroli, a następny odbiorca może sprawdzić, czy wcześniejsze wpisy nie zostały zmienione. Specyfikacja została opublikowana jako RFC 8617 w 2019 roku i ma status Experimental.

Trzy nagłówki tworzące pojedynczy ARC Set

Pojedynczy zestaw ARC, nazywany ARC Set, składa się z trzech powiązanych nagłówków. ARC-Authentication-Results, skracany do AAR, zapisuje ocenę uwierzytelnienia wykonaną przez konkretny system pocztowy. Jego zawartość opisuje między innymi wyniki SPF, DKIM lub innych kontroli, ale sam format wyniku jest oparty na mechanizmie Authentication-Results z RFC 8601. AAR dokumentuje stan zaobserwowany na danym etapie, a nie gwarantuje, że wszystkie zawarte w nim oceny są prawidłowe.

ARC-Message-Signature, czyli AMS, jest podpisem kryptograficznym odnoszącym się do wiadomości w postaci przekazywanej przez dany węzeł. Konstrukcyjnie przypomina podpis DKIM i wykorzystuje między innymi domenę podpisującą, selektor oraz klucz publiczny dostępny przez DNS. ARC-Seal, oznaczany jako AS, podpisuje informacje tworzące łańcuch ARC, w tym odpowiednie wcześniejsze elementy. Komplet AAR, AMS i AS otrzymuje ten sam numer instancji zapisany parametrem i=. Pierwszy zestaw ma zwykle i=1, a kolejne pośredniki zwiększają numer o jeden.

Walidacja łańcucha i znaczenie parametru cv

Podczas tworzenia kolejnego zestawu ARC serwer występujący jako sealer dołącza własną ocenę AAR, podpisuje aktualną wiadomość przez AMS, a następnie zabezpiecza cały dostępny łańcuch przez ARC-Seal. Weryfikator sprawdza kompletność zestawów, kolejność numerów instancji, poprawność podpisów oraz możliwość pobrania właściwych kluczy publicznych. Brak jednego z elementów zestawu, powtórzenie numeru albo niezgodność podpisu może doprowadzić do odrzucenia łańcucha jako niewiarygodnego.

W nagłówku ARC-Seal znajduje się parametr cv=, określający stan łańcucha widziany przez bieżącego sealera. Wartość none oznacza rozpoczęcie łańcucha, pass wskazuje poprawną walidację wcześniejszych elementów, a fail sygnalizuje problem z łańcuchem. Wynik ARC powinien być interpretowany razem z lokalną polityką odbiorcy, reputacją domeny podpisującej oraz innymi wynikami kontroli. Sam poprawny podpis ARC nie dowodzi, że nadawca pierwotnej wiadomości jest godny zaufania.

ARC w ścieżce przekazywania poczty

Praktycznym zastosowaniem ARC jest przekazywanie wiadomości przez podmioty, które działają zgodnie z uzasadnioną funkcją pośredniczącą, ale nie mogą zachować wszystkich elementów oryginalnego przekazu. Lista mailingowa może zmienić temat i treść, a usługa przekazywania może wpłynąć na adres używany w kopercie SMTP. Odbiorca końcowy może wtedy zobaczyć, że bieżący DKIM lub DMARC nie przechodzi, lecz jednocześnie otrzymać podpisany zapis wcześniejszej oceny wraz z informacją, które systemy uczestniczyły w dostarczeniu.

ARC nie jest mechanizmem szyfrowania, nie zastępuje SPF ani DKIM i nie nakazuje odbiorcy przyjęcia wiadomości. Serwer odbiorczy może uznać zweryfikowany łańcuch za dodatkowy sygnał przy podejmowaniu decyzji, ale powinien uwzględnić, czy ufa domenom występującym jako sealery. Podczas analizy nagłówków należy sprawdzić zgodność numerów i=, obecność wszystkich trzech nagłówków w każdym zestawie, wartości cv=, domeny d=, selektory s= oraz wyniki weryfikacji podpisów. Takie dane pozwalają odróżnić utratę pierwotnego uwierzytelnienia wskutek legalnego przekazania od próby dopisania lub zmodyfikowania historii wiadomości.