RFC 8601 opisuje nagłówek Authentication-Results dokumentujący wyniki weryfikacji uwierzytelniania wiadomości.
Rola nagłówka Authentication-Results
RFC 8601 opisuje sposób zapisywania wyników uwierzytelniania wiadomości poczty elektronicznej w polu nagłówka Authentication-Results. Nagłówek ten jest dodawany przez system obsługujący odbiór wiadomości, zwykle przez serwer pośredniczący, filtr antyspamowy albo bramę pocztową. Jego zadaniem jest przekazanie kolejnym elementom toru dostarczania informacji o tym, jakie mechanizmy uwierzytelniania zostały sprawdzone i jaki był wynik tych sprawdzeń.
Authentication-Results nie jest samodzielnym mechanizmem uwierzytelniania i nie szyfruje wiadomości. Stanowi raport oparty na rezultatach innych technologii, między innymi SPF, DKIM oraz DMARC. Odbiorca może wykorzystać ten raport do podjęcia decyzji dotyczącej dostarczenia wiadomości, oznaczenia jej jako podejrzanej albo odrzucenia. Sam nagłówek nie dowodzi jednak, że wiadomość jest bezpieczna. Informuje tylko o przeprowadzonych testach i ich wyniku w określonym środowisku.
Składnia i identyfikator systemu oceniającego
Wartość pola Authentication-Results rozpoczyna się od identyfikatora serwisu uwierzytelniającego, nazywanego authserv-id. Identyfikator wskazuje system, który przeprowadził ocenę i wystawił dany nagłówek. Po nim umieszcza się jedną lub większą liczbę wyników metod uwierzytelniania, określanych jako method wraz z wartością result. Przykładowe wyniki obejmują pass, fail, softfail, neutral, none, temperror oraz permerror, przy czym dokładny zestaw dopuszczalnych rezultatów zależy od opisywanej metody.
Poszczególne elementy mogą zawierać dodatkowe właściwości, takie jak domena użyta podczas sprawdzania, identyfikator selektora DKIM, adres IP klienta SMTP albo wartość domeny uzyskana dla mechanizmu SPF. Przykładowa konstrukcja może mieć postać Authentication-Results: mx.example; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org. W takim zapisie mx.example jest identyfikatorem systemu oceniającego, a dalsze elementy opisują wyniki SPF i DKIM. Konkretne parametry są interpretowane zgodnie z regułami danej metody, a nie jako uniwersalne pola o identycznym znaczeniu.
SPF, DKIM i DMARC w tym raporcie
Wynik spf=pass oznacza, że adres IP klienta wysyłającego został zaakceptowany według rekordu SPF domeny użytej w mechanizmie MAIL FROM albo w odpowiednim adresie nadawcy koperty. SPF dotyczy ścieżki transportowej i nie potwierdza sam przez się zgodności adresu widocznego w polu From:. Z tego powodu wiadomość może otrzymać pozytywny wynik SPF, mimo że jej widoczny nadawca nie jest zgodny z domeną używaną do wysyłki.
Wynik dkim=pass informuje o poprawnej weryfikacji podpisu DKIM, w tym o zgodności kryptograficznej podpisanych nagłówków i treści z kluczem publicznym opublikowanym w DNS. Parametr header.d wskazuje domenę podpisującą. DMARC wykorzystuje między innymi wyniki SPF i DKIM oraz sprawdza ich dopasowanie do domeny z pola From:. Dlatego zapis dmarc=pass powinien być rozpatrywany razem z informacjami o domenie nadawcy i użytej metodzie wyrównania, a nie jako ogólne potwierdzenie autentyczności całej wiadomości.
Interpretacja nagłówka podczas analizy wiadomości
Analizując Authentication-Results, należy najpierw ustalić, który zaufany system dodał nagłówek. Wiadomość może przechodzić przez kilka serwerów i zawierać wiele pól o tej samej nazwie. Nagłówki otrzymane z niezaufanego źródła mogą zostać sfałszowane przez nadawcę, dlatego nie powinny być traktowane jako wiarygodny dowód wyniku kontroli. System odbiorczy powinien rozpoznawać własną granicę zaufania i odpowiednio odrzucać albo ignorować informacje pochodzące spoza tej granicy.
Warto również odróżnić błąd stały od czasowego. temperror wskazuje problem przejściowy, na przykład niedostępność usługi DNS, natomiast permerror oznacza trwały błąd konfiguracji lub składni danych wymaganych przez daną metodę. Wynik none oznacza brak odpowiedniej informacji do sprawdzenia, a neutral brak jednoznacznej decyzji. Nagłówek może pomóc ustalić, dlaczego wiadomość trafiła do spamu, ale pełna analiza wymaga porównania go z polami Received, From, Return-Path, podpisem DKIM oraz polityką DMARC domeny.
