SPF vs. DKIM - dokładne przypadki użycia i różnice


20

Przepraszam za niejasny tytuł. Nie do końca rozumiem, dlaczego SPF i DKIM powinny być używane razem.

Po pierwsze: SPF może przejść tam, gdzie powinien zawieść, jeśli nadawca lub DNS jest „sfałszowany” i może zawieść tam, gdzie powinien przejść, jeśli zaangażowane są pewne zaawansowane ustawienia serwerów proxy i usług przesyłania dalej.

DKIM może przejść tam, gdzie powinien zawieść, albo z powodu błędu / słabości w kryptografii (wykluczamy to, stąd uproszczony punkt), albo z powodu sfałszowania zapytania DNS.

Ponieważ błąd kryptografii jest wykluczony, różnica (jak widzę) polega na tym, że DKIM może być używany w konfiguracjach, w których SPF zawodzi. Nie mogę wymyślić żadnych przykładów, w których można skorzystać z obu. Jeśli konfiguracja pozwala na SPF, to DIKM nie powinien dodawać żadnej dodatkowej weryfikacji.

Czy ktoś może mi podać przykład korzyści z korzystania z obu?

Odpowiedzi:


15

SPF ma o wiele więcej rankingów niż pozytywny / negatywny. Wykorzystanie ich w heurystycznie punktowanym spamie sprawia, że ​​proces jest łatwiejszy i dokładniejszy. Niepowodzenie z powodu „zaawansowanych ustawień” oznacza, że ​​administrator poczty nie wiedział, co robił, konfigurując rekord SPF. Nie ma konfiguracji, której SPF nie może poprawnie uwzględnić.

Kryptografia nigdy nie działa w absolutach. Jedyne szyfrowanie dozwolone w DKIM zwykle wymaga znacznych zasobów do złamania. Większość ludzi uważa to za wystarczająco bezpieczne. Każdy powinien ocenić swoją sytuację. Ponownie, DKIM ma więcej rankingów niż tylko Pass / Fail.

Jeden przykład, w którym można skorzystać z obu: wysłanie do dwóch różnych stron, z których jedna sprawdza SPF, a druga sprawdza DKIM. Kolejny przykład, wysyłanie do strony z treściami, które normalnie zajmowałyby wysoką pozycję w teście spamowym, ale są równoważone zarówno przez DKIM, jak i SPF, umożliwiając dostarczenie poczty.

W większości przypadków nie są one wymagane, chociaż indywidualni administratorzy poczty ustalają własne reguły. Oba pomagają rozwiązać różne aspekty spamu: SPF, który przekazuje pocztę e-mail, a DKIM to integralność wiadomości e-mail i autentyczność pochodzenia.


Ok, śledzę twoje uwagi (zwłaszcza, że ​​niektórzy mogą po prostu użyć tylko jednego z dwóch - jak tego nie widziałem!). Więc SPF i DKIM mogą mieć różne ustawienia i rankingi, ale ogólnie rzecz biorąc, są skierowane do tej samej monety. Do twojego ostatniego punktu: poczta od autoryzowanego przekaźnika (SPF) powinna być zaufana tak samo jak prawidłowy podpis DKIM. W końcu właściciel domeny zatwierdził jedno i drugie. Właśnie przetestowałem moją pocztę tylko przy użyciu SPF i chociaż mój uniwersytet i gmail starają się ją zaakceptować, hotmail uważa ją za spam - być może dlatego, że polega na DIKM. Dzięki za komentarz Chris!
usunięty użytkownik 42

Hotmail używa SenderID (że tak powiem SPF 2.0), DKIM, SenderScore, PBL i ich własnej technologii filtrowania. Są trochę skryci odnośnie dokładnej formuły.
Chris S

18

Odpowiedź została udzielona jakiś czas temu, ale myślę, że w przyjętej odpowiedzi nie ma sensu, dlaczego oba muszą być używane razem, aby były skuteczne.

SPF sprawdza adres IP ostatniego skoku serwera SMTP względem listy autoryzowanych. DKIM sprawdza, czy poczta została początkowo wysłana przez daną domenę, i gwarantuje jej integralność.

Prawidłowe podpisane wiadomości DKIM mogą być używane jako spam lub phishing poprzez ponowne wysłanie bez modyfikacji. SPF nie sprawdza integralności wiadomości.

Wyobraź sobie scenariusz, w którym otrzymujesz prawidłową wiadomość e-mail z podpisem DKIM (od banku, znajomego itp.) I znajdujesz dobry sposób na wykorzystanie tej poczty bez modyfikacji: wtedy możesz po prostu wysłać tę wiadomość tysiące razy do różnych osób. Ponieważ poczta nie jest modyfikowana, podpis DKIM nadal będzie ważny, a wiadomość przejdzie jako zgodna z prawem.

W każdym razie SPF sprawdza pochodzenie (rzeczywisty adres IP / DNS serwera SMTP) poczty, więc SPF uniemożliwi przekazywanie poczty, ponieważ nie można ponownie wysłać prawidłowej poczty przez dobrze skonfigurowany serwer SMTP, a poczta pochodząca z innych adresów IP będzie odrzucone, skutecznie zapobiegając ponownemu wysyłaniu „prawidłowych” wiadomości DKIM jako spamu.


Czy mógłby Pan podać kilka przykładów wykorzystania poczty bez modyfikacji?
user3413723,

Każdy e-mail zaczynający się od ogólnego „Szanowny kliencie”, „Drogi użytkowniku” lub „Drogi <pierwsza część adresu e-mail przed znakiem @”. Dlatego ważne jest, aby legalne wiadomości e-mail zawsze zawierały co najmniej 1 część danych osobowych, takich jak część kodu pocztowego / pocztowego lub pełne imię i nazwisko. (Dzięki temu są bardziej autentyczne i nie
nadają się

Ale jeśli pola nagłówka zostały podpisane, w tym adresaci, to z pewnością eliminuje to możliwość powtórnego ataku na nowych adresatów? tj. Dodanie podpisów h=from:to;( od wymaganego w RFC 6376 , do opcjonalnego) powinno pozwolić jedynie na ataki powtórne na tego samego odbiorcę. Co jest złe, ale nie tak złe, jak sugeruje ta odpowiedź.
Richard Dunn,

4

Oto kilka powodów, dla których powinieneś zawsze publikować zarówno SPF, jak i DKIM.

  1. Niektórzy dostawcy skrzynek pocztowych obsługują tylko jednego lub drugiego, a niektórzy obsługują oba, ale ważą jeden więcej niż drugi.

  2. DKIM chroni wiadomości e-mail przed zmianą podczas przesyłania, SPF tego nie robi.

Dodałbym również DMARC do listy. Jaką wadą jest zawsze publikowanie pełnego uwierzytelniania przez e-mail?


1
„Jaką wadą jest zawsze publikowanie pełnego uwierzytelniania przez e-mail?”, Wysiłek! Myślę, że Devops jest już PITA, co jest kolejną cegłą w ścianie, lub 3, w zależności od przypadku.
Gordon Wrigley,

Co ISP ma z tym wspólnego? Masz na myśli dostawcę poczty?
William

Tak, miałem na myśli dostawcę skrzynki pocztowej. Ludzie często otrzymywali usługi e-mail od dostawców usług internetowych, więc mam w zwyczaju mówić o nich.
Neil Anuskiewicz,

Dziękujemy za zwrócenie na to uwagi, ponieważ zmieniłem go teraz na dostawcę skrzynki pocztowej.
Neil Anuskiewicz,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.