Wiadomość e-mail zawiera kilka tożsamości i odpowiadają one na różne pytania. Koperta SMTP kieruje transportem, nagłówki dostarczone przez autora opisują wiadomość, systemy odbierające dodają informacje o śledzeniu, a osoby oceniające uwierzytelnianie zgłaszają swoje ustalenia. Przekonująca nazwa wyświetlana lub wers mówiący „pass” nie jest wystarczającym pochodzeniem. Zacznij od określenia, który system stworzył każdą wartość i którym elementom Twoja organizacja może faktycznie zaufać.
Odróżnij kopertę od zawartości
POCZTA OD i RCPT TO należą do transakcji SMTP . Nie muszą pasować do widocznych nagłówków From i To. Adres zwrotny, lista mailingowa, alias, odbiorca ukrytej kopii lub reguła przekazywania mogą sprawić, że różnica będzie uzasadniona. Zbiór odbiorców użyty do dostarczenia nie jest rekonstruowany po prostu poprzez odczytanie Do i DW.
Końcowy system dostarczania rejestruje ścieżkę odwrotną w Return-Path według RFC 5321. Ten nagłówek stanowi dowód dotyczący koperty w momencie dostarczenia, jeśli jej granica wstawiania jest zaufana; nie jest to uniwersalny certyfikat tożsamości pierwotnego autora. Przesyłanie dalej może przepisać kopertę pomiędzy przeskokami, więc porównaj odpowiednią transakcję, zamiast zakładać, że jeden adres będzie się utrzymywał na całej trasie.
Przypisz widoczne pola
From określa pole autora wiadomości w obszarze RFC 5322. Nadawca, jeśli jest używany, identyfikuje agenta odpowiedzialnego za transmisję w zdefiniowanym w polu znaczeniu. Opcja Reply-To wyświetla sugerowane miejsce docelowe odpowiedzi. Data i identyfikator wiadomości pomagają w interpretacji i korelacji, ale nie są niezależnie uwierzytelniane jedynie przez pojawienie się w wiadomości.
DKIM weryfikacja może uwierzytelnić podpisaną treść nagłówka w stosunku do domeny podpisującej. Nie zamienia każdego niepodpisanego pola w zweryfikowany dowód ani nie ustala, że osoba wymieniona w From autoryzowała transakcję biznesową. Sprawdź, który podpis przeszedł, jego domenę d i listę podpisanych nagłówków. DMARC wyrównanie dotyczy widocznej domeny From i odpowiedniej uwierzytelnionej SPF lub DKIM , a nie pasujący identyfikator Reply-To lub Message-ID.
Ustal granicę odbiorczą
Odbierające serwery SMTP poprzedzają otrzymane pola śledzenia. Przeczytaj ślad, mając wiedzę na temat systemów, którymi operuje Twoja organizacja, i obserwowanych przez nią zewnętrznych granic. Wcześniejszy lub dostarczony z zewnątrz tekst śledzenia może wprowadzać w błąd. Podobnie, RFC 8601 definiuje Authentication-Results w ramach zrozumiałej granicy zaufania; osoba atakująca może wstawić nagłówek, który wygląda na korzystny wynik.
Rozważmy hipotetyczną wiadomość z dwoma polami Authentication-Results : jedno twierdzi, że pochodzi od receiver.example , a drugie twierdzi, że pochodzi z forged.example . Żadna etykieta nie potwierdza własnego pochodzenia. Zaufaj pierwszemu tylko wtedy, gdy udokumentowana granica i dzienniki usługi odbierającej wykażą, że umieścił ją jej autoryzowany weryfikator; w przeciwnym razie zaznacz jego pochodzenie jako nierozwiązane. Drugi nie jest dowodem uwierzytelnienia tylko dlatego, że zawiera przepustkę.
Zamień mapę w śledztwo
Dla każdej istotnej tożsamości zapisz wartość, system źródłowy, obserwowany przeskok, podstawę zaufania i pytanie, na które odpowiada. Widoczna domena autora odpowiada na inne pytanie niż konto uwierzytelnionego przesyłania lub domena zwrotna koperty. Przechowuj oryginalne bajty w ograniczonym magazynie dowodów i używaj zredagowanej kopii roboczej do rutynowych dyskusji. Redakcja może unieważnić DKIM , więc zachowaj nienaruszony oryginał, gdy wymagana jest weryfikacja.
Porównaj mapę nagłówka z dziennikami SMTP i wynikami zaufanych odbiorców. W hipotetycznej ścieżce rozliczeniowej MAIL FROM to bounce@vendor.example , a adres From to invoices@brand.example . Różnica może być uzasadniona. Sprawdzone Podpis DKIM z d=brand.example może zapewnić dokładne dopasowanie, nawet jeśli domena koperty jest inna. Załóż, że obowiązują zasady DMARC i nie ma nierozwiązanych błędów oceny; nie testowano tutaj żadnego rzeczywistego dostawcy, podpisu ani wiadomości.
Zakończ wnioskiem powiązanym z dowodami: która domena została uwierzytelniona, jaka trasa została zaobserwowana i które pytania autoryzacyjne pozostają otwarte. Nie sprowadzaj tych ustaleń do twierdzenia, że każde pole lub każde żądane działanie jest godne zaufania.
Użyj pięciokolumnowej notatki o pochodzeniu
- Wartość: skopiuj dokładną tożsamość pola lub koperty z oryginalnego dowodu.
- Producent: określić, który klient, przekaźnik, firma kurierska lub weryfikator go dostarczył.
- Przeskok: zapisz transakcję lub granicę odbioru, w której została zaobserwowana.
- Podstawa zaufania: wyjaśnij, dlaczego rekord tego systemu jest zaufany lub oznacz go jako niezaufany.
- Znaczenie: podaj pytanie, na które odpowiada wartość, oraz jakiej tożsamości lub autoryzacji biznesowej nie potwierdza.