Ramy zasad dotyczących nadawcy

Zestaw protokołów internetowych
Warstwa aplikacji
Warstwa transportowa
warstwa internetowa
Warstwa łącza

Sender Policy Framework ( SPF ) to metoda uwierzytelniania wiadomości e-mail zaprojektowana w celu wykrywania fałszowania adresów nadawcy podczas dostarczania wiadomości e-mail. Jednak sam SPF ogranicza się do wykrycia sfałszowanego oświadczenia nadawcy w kopercie wiadomości e-mail, która jest używana, gdy poczta zostanie odesłana. Tylko w połączeniu z DMARC można go używać do wykrywania fałszowania widocznego nadawcy w wiadomościach e-mail ( fałszowanie wiadomości e-mail ), techniki często stosowanej w phishingu i spamie e-mail .

SPF umożliwia odbierającemu serwerowi pocztowemu sprawdzanie podczas dostarczania poczty, czy poczta rzekomo pochodząca z określonej domeny jest wysyłana z adresu IP autoryzowanego przez administratorów tej domeny. Lista autoryzowanych hostów wysyłających i adresów IP dla domeny jest publikowana w rekordach DNS dla tej domeny.

Sender Policy Framework jest zdefiniowany w RFC 7208 z kwietnia 2014 jako „proponowany standard”.

Historia

Pierwsza publiczna wzmianka o koncepcji miała miejsce w 2000 roku, ale w większości przeszła niezauważona. Nie wspomniano o tej koncepcji ponownie, dopóki pierwsza próba specyfikacji podobnej do SPF nie została opublikowana w 2002 roku na liście IETF „namedroppers” przez Danę Valerie Reese, która nie była świadoma wzmianki o pomyśle z 2000 roku. Już następnego dnia Paul Vixie zamieścił na tej samej liście swoją własną specyfikację podobną do SPF. Posty te wzbudziły duże zainteresowanie, doprowadziły do ​​powstania IETF Anti-Spam Research Group (ASRG) i ich listy mailingowej, gdzie idea SPF była dalej rozwijana. Wśród wniosków złożonych do ASRG były „Reverse MX ” (RMX) autorstwa Hadmuta Danischa oraz „Designated Mailer Protocol” (DMP) autorstwa Gordona Fecyka.

W czerwcu 2003 roku Meng Weng Wong połączył specyfikacje RMX i DMP i poprosił innych o sugestie. W ciągu następnych sześciu miesięcy wprowadzono wiele zmian i duża społeczność zaczęła pracować nad SPF. Pierwotnie SPF oznaczało Sender Permitted From i czasami było również nazywane SMTP+SPF ; ale jego nazwa została zmieniona na Sender Policy Framework w lutym 2004 roku.

Na początku 2004 r. IETF stworzył grupę roboczą MARID i próbował wykorzystać SPF i propozycję Microsoft CallerID jako podstawę tego, co jest obecnie znane jako Sender ID ; ale to upadło z powodu konfliktów technicznych i licencyjnych.

Społeczność SPF powróciła do pierwotnej „klasycznej” wersji SPF. W lipcu 2005 ta wersja specyfikacji została zatwierdzona przez IESG jako eksperyment IETF , zapraszając społeczność do obserwowania SPF przez dwa lata po publikacji. 28 kwietnia 2006 SPF RFC został opublikowany jako eksperymentalny RFC 4408.

W kwietniu 2014 IETF opublikował SPF w RFC 7208 jako „proponowany standard”.

Zasady działania

Dalsze informacje: Schemat przepisywania nadawcy (SRS)

Simple Mail Transfer Protocol umożliwia dowolnemu komputerowi wysyłanie wiadomości e-mail podających się za pochodzące z dowolnego adresu źródłowego. Jest to wykorzystywane przez spamerów i oszustów, którzy często używają sfałszowanych adresów e-mail , co utrudnia śledzenie wiadomości z powrotem do jej źródła i ułatwia spamerom ukrywanie swojej tożsamości w celu uniknięcia odpowiedzialności. Jest również używany w phishingu , w których użytkownicy mogą zostać nakłonieni do ujawnienia prywatnych informacji w odpowiedzi na wiadomość e-mail rzekomo wysłaną przez organizację taką jak bank.

SPF umożliwia właścicielowi domeny internetowej określenie, które komputery są upoważnione do wysyłania poczty z adresami koperty nadawcy w tej domenie, przy użyciu rekordów DNS ( Domain Name System ). Odbiorcy weryfikujący informacje SPF w rekordach TXT mogą odrzucić wiadomości z nieautoryzowanych źródeł przed otrzymaniem treści wiadomości. Tym samym zasady działania są podobne do tych z list czarnych dziur opartych na DNS ( DNSBL ), z wyjątkiem tego, że SPF korzysta ze schematu delegowania uprawnień systemu nazw domen. Obecna praktyka wymaga użycia rekordów TXT, tak jak robiły to wczesne implementacje. Na jakiś czas zarejestrowano nowy typ rekordu (SPF, typ 99) i udostępniono go w powszechnym oprogramowaniu DNS. Wykorzystanie rekordów TXT dla SPF miało być wówczas mechanizmem przejściowym. Eksperymentalny RFC, RFC 4408, sekcja 3.1.1, sugerował, że „nazwa domeny zgodna z SPF POWINNA mieć rekordy SPF obu typów RR”. Proponowany standard RFC 7208 mówi, że „korzystanie z alternatywnych typów DNS RR było obsługiwane w fazie eksperymentalnej SPF, ale zostało przerwane”.

Adres z koperty nadawcy jest przesyłany na początku okna dialogowego SMTP. Jeśli serwer odrzuci domenę, nieautoryzowany klient powinien otrzymać wiadomość o odrzuceniu, a jeśli ten klient był agentem przekazywania wiadomości (MTA), wiadomość o odrzuceniu na oryginalny adres nadawcy na kopercie może zostać wygenerowany. Jeżeli serwer zaakceptuje domenę, a następnie zaakceptuje również adresatów i treść wiadomości, powinien wstawić w nagłówku wiadomości pole Return-Path, aby zapisać adres koperty nadawcy. Chociaż adres w ścieżce zwrotnej często pasuje do innych adresów nadawcy w nagłówku poczty, takim jak header-from , niekoniecznie tak jest, a SPF nie zapobiega fałszowaniu tych innych adresów, takich jak nagłówek nadawcy .

Spamerzy mogą wysyłać wiadomości e-mail z wynikiem SPF PASS, jeśli mają konto w domenie z zasadami dotyczącymi nadawcy lub nadużywają zainfekowanego systemu w tej domenie. Jednak takie postępowanie ułatwia śledzenie spamera.

Główną korzyścią z SPF są właściciele adresów e-mail sfałszowanych w ścieżce zwrotnej. Otrzymują dużą liczbę niechcianych komunikatów o błędach i innych automatycznych odpowiedzi. Jeśli tacy odbiorcy używają SPF do określania swoich legalnych źródłowych adresów IP i wskazują wynik FAIL dla wszystkich innych adresów, odbiorniki sprawdzające SPF mogą odrzucić fałszerstwa, zmniejszając w ten sposób lub eliminując ilość rozproszenia wstecznego .

SPF ma potencjalne zalety wykraczające poza pomoc w identyfikowaniu niechcianej poczty. W szczególności, jeśli nadawca dostarcza informacje SPF, odbiorcy mogą użyć wyników SPF PASS w połączeniu z listą dozwolonych, aby zidentyfikować znanych nadawców. Scenariusze, takie jak zhakowane systemy i wspólne wysyłanie wiadomości e-mail, ograniczają to użycie.

Powody do wdrożenia

Jeśli domena publikuje rekord SPF, spamerzy i phisherzy są mniej skłonni do fałszowania wiadomości e-mail udających, że pochodzą z tej domeny, ponieważ sfałszowane wiadomości e-mail są bardziej narażone na przechwycenie przez filtry spamu, które sprawdzają rekord SPF. Dlatego domena chroniona przez SPF jest mniej atrakcyjna dla spamerów i phisherów. Ponieważ domena chroniona przez SPF jest mniej atrakcyjna jako sfałszowany adres, jest mniej prawdopodobne, że zostanie odrzucona przez filtry antyspamowe, a więc ostatecznie prawdziwszy e-mail z domeny ma większe szanse na przedostanie się.

NIEPOWODZENIE i przekazywanie

SPF łamie zwykłe przekazywanie wiadomości . Gdy domena publikuje zasady SPF FAIL, prawidłowe wiadomości wysyłane do odbiorców przekazujących ich pocztę osobom trzecim mogą zostać odrzucone i/lub odesłane, jeśli wystąpią wszystkie poniższe okoliczności:

  1. Nadawca nie przepisuje Return-Path , w przeciwieństwie do list mailingowych.
  2. Następny przeskok nie umieszcza na liście dozwolonych usługi przesyłania dalej.
  3. Ten chmiel sprawdza SPF.

Jest to konieczna i oczywista cecha SPF – sprawdzanie za „granicznym” MTA ( MX ) odbiornika nie może działać bezpośrednio.

Wydawcy zasad SPF FAIL muszą zaakceptować ryzyko odrzucenia lub odesłania ich uzasadnionych e-maili. Powinni testować (np. z polityką SOFTFAIL), dopóki nie będą zadowoleni z wyników. Poniżej znajduje się lista alternatyw dla zwykłego przekazywania wiadomości.

HELO testy

W przypadku pustej ścieżki zwrotnej używanej w komunikatach o błędach i innych automatycznych odpowiedziach obowiązkowe jest sprawdzenie tożsamości HELO przez SPF.

W przypadku fałszywej tożsamości HELO wynik NONE nie pomógłby, ale w przypadku prawidłowych nazw hostów SPF chroni również tożsamość HELO. Ta funkcja SPF była zawsze obsługiwana jako opcja dla odbiorników, a późniejsze wersje robocze SPF, w tym ostateczna specyfikacja, zalecają, aby zawsze sprawdzać HELO.

Pozwala to odbiorcom na umieszczanie na liście dozwolonych wysyłających wiadomości na podstawie HELO PASS lub odrzucanie wszystkich wiadomości po HELO FAIL. Może być również używany w systemach reputacji (każda lista dozwolonych lub zabronionych jest prostym przypadkiem systemu reputacji).

Realizacja

Zgodność z SPF składa się z trzech luźno powiązanych zadań:

  • Publikowanie zasad : domeny i hosty identyfikują komputery upoważnione do wysyłania wiadomości e-mail w ich imieniu. Robią to, dodając dodatkowe rekordy do istniejących informacji DNS: każda nazwa domeny lub host, który ma rekord A lub rekord MX , powinien mieć rekord SPF określający zasady, jeśli jest używany w adresie e-mail lub jako argument HELO/EHLO. Hosty, które nie wysyłają poczty, powinny mieć opublikowany rekord SPF, który to wskazuje („v=spf1 -all”).
  • Sprawdzanie i używanie informacji SPF : Odbiorcy używają zwykłych zapytań DNS, które są zazwyczaj buforowane w celu zwiększenia wydajności. Następnie odbiorniki interpretują informacje SPF zgodnie ze specyfikacją i działają na podstawie wyniku.
  • Weryfikacja przekazywania poczty : SPF nie zezwala na zwykłe przekazywanie poczty. Alternatywy to:
    • Remailing (tj. zamiana pierwotnego nadawcy na nadawcę należącego do domeny lokalnej)
    • Odmowa (np. odpowiedź 551 Użytkownik nie jest lokalny; spróbuj <[email protected]> )
    • Lista dozwolonych na serwerze docelowym, aby nie odrzucił przesłanej wiadomości
    • Schemat przepisywania nadawcy , bardziej skomplikowany mechanizm obsługujący kierowanie powiadomień o niedostarczeniu do pierwotnego nadawcy

W związku z tym kluczową kwestią w SPF jest specyfikacja nowych informacji DNS, które są ustawiane przez domeny i używane przez odbiorniki. Rekordy przedstawione poniżej mają typową składnię DNS, na przykład:

„v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -wszystko”

„v=” określa używaną wersję SPF. Następujące słowa udostępniają mechanizmy służące do określania, czy domena może wysyłać pocztę. „ip4” i „a” określają systemy, które mogą wysyłać wiadomości dla danej domeny. „-all” na końcu określa, że ​​jeśli poprzednie mechanizmy nie pasowały, wiadomość powinna zostać odrzucona.

Mechanizmy

Zdefiniowano osiem mechanizmów :

WSZYSTKO Zawsze pasuje; używany dla wyniku domyślnego, takiego jak -all dla wszystkich adresów IP, które nie zostały dopasowane przez wcześniejsze mechanizmy.
A Jeśli nazwa domeny ma rekord adresu (A lub AAAA), który można przetłumaczyć na adres nadawcy, będzie pasować.
IP4 Jeśli nadawca znajduje się w danym zakresie adresów IPv4 , dopasuj.
IP6 Jeśli nadawca znajduje się w danym zakresie adresów IPv6 , dopasuj.
MX Jeśli nazwa domeny ma rekord MX odnoszący się do adresu nadawcy, będzie pasować (tzn. poczta pochodzi z jednego z serwerów poczty przychodzącej domeny).
PTR Jeśli nazwa domeny ( rekord PTR ) dla adresu klienta znajduje się w podanej domenie i ta nazwa domeny jest tłumaczona na adres klienta ( odwrotny DNS z potwierdzeniem przekazania ), dopasuj. Mechanizm ten jest odradzany i należy go unikać, jeśli to możliwe.
ISTNIEJE Jeśli dana nazwa domeny odpowiada dowolnemu adresowi, dopasuj (bez względu na adres, na który się rozwiązuje). Jest to rzadko używane. Wraz z językiem makr SPF oferuje bardziej złożone dopasowania, takie jak DNSBL .
WŁĄCZAĆ Odwołuje się do polityki innej domeny. Jeśli zasady tej domeny zostaną spełnione, ten mechanizm przejdzie. Jeśli jednak uwzględnione zasady zawiodą, przetwarzanie jest kontynuowane. Aby w pełni przekazać zasady innej domeny, należy użyć rozszerzenia przekierowania .

Kwalifikacje

Każdy mechanizm można połączyć z jednym z czterech kwalifikatorów :

  • + za wynik PASS. Można to pominąć; np. +mx oznacza to samo co mx .
  • ? dla wyniku NEUTRALNEGO interpretowanego jako BRAK (brak polityki).
  • ~ (tylda) dla SOFTFAIL, pomoc w debugowaniu między NEUTRALNYM a FAIL. Zazwyczaj wiadomości, które zwracają błąd SOFTFAIL, są akceptowane, ale oznaczane tagami.
  • - (minus) dla FAIL, wiadomość powinna zostać odrzucona (patrz poniżej).

Modyfikatory

Modyfikatory pozwalają na przyszłe rozszerzenia frameworka. Do tej pory szeroko stosowane były tylko dwa modyfikatory zdefiniowane w dokumencie RFC 4408:

  • exp=jakiś.example.com podaje nazwę domeny z rekordem DNS TXT (zinterpretowanym przy użyciu języka makr SPF), aby uzyskać wyjaśnienie wyników FAIL — zazwyczaj adres URL dodawany do kodu błędu SMTP. Ta funkcja jest rzadko używana.
  • redirect=jakiś.example.com można użyć zamiast mechanizmu ALL- , aby połączyć się z rekordem polityki innej domeny. Ten modyfikator jest łatwiejszy do zrozumienia niż nieco podobny mechanizm INCLUDE .

Obsługa błędów

Gdy tylko implementacje SPF wykryją błędy składniowe w polityce nadawcy, muszą przerwać ocenę z wynikiem PERMERROR. Pomijanie błędnych mechanizmów nie może działać zgodnie z oczekiwaniami, dlatego też include:bad.example i redirect=bad.example również powodują błąd PERMERROR.

Kolejnym zabezpieczeniem jest maksymalnie dziesięć mechanizmów odpytujących DNS, czyli dowolny mechanizm oprócz IP4, IP6 i ALL. Implementacje mogą przerwać ocenę z wynikiem TEMPERROR, gdy trwa to zbyt długo lub zapytanie DNS przekroczy limit czasu, lub mogą nadal udawać, że zapytanie nie zwróciło żadnych danych — co nazywa się „wyszukiwaniem pustym”. Muszą jednak zwrócić PEMERROR, jeśli polityka bezpośrednio lub pośrednio wymaga więcej niż dziesięciu zapytań o mechanizmy . Ponadto powinny zwrócić PERMERROR, gdy tylko napotkane zostaną więcej niż dwa „wyszukiwania pustki”. Dowolne przekierowanie= wlicza się również do tych limitów przetwarzania .

Typowa polityka SPF HELO v=spf1 a mx ip4:192.0.2.0 -all może wykonać cztery lub więcej zapytań DNS: (1) rekord TXT (typ SPF został przestarzały przez RFC 7208), (2) A lub AAAA dla mechanizmu a , (3) Rekord MX i (4+) A lub AAAA dla każdej nazwy MX dla mechanizmu mx . Poza pierwszym, wszystkie te zapytania liczą się do limitu 10. Dodatkowo, jeśli np. nadawca ma adres IPv6, a jego nazwa i dwie nazwy MX mają tylko adresy IPv4, to ocena dwóch pierwszych mechanizmów już skutkuje więcej niż dwoma wyszukiwaniami pustymi, a zatem PEMERROR. Zauważ, że mechanizmy ip4 , ip6 i wszystkie nie wymagają wyszukiwania DNS.

Kwestie

Rekordy DNS SPF

Aby umożliwić szybkie testowanie i wdrażanie, początkowe wersje SPF sprawdziły jego ustawienie w rekordzie DNS TXT domeny wysyłającej — mimo że tradycyjnie rekord ten miał być tekstem o dowolnej formie, bez dołączonej semantyki. Chociaż w lipcu 2005 r. IANA przypisała do SPF określony rekord zasobów typu 99, jego popularność nigdy nie była wysoka, a posiadanie dwóch mechanizmów było mylące dla użytkowników. W 2014 r. zaprzestano używania tego rekordu po tym, jak grupa robocza SPFbis stwierdziła, że ​​„…znacząca migracja do typu SPF RR w dającej się przewidzieć przyszłości jest bardzo mało prawdopodobna i że najlepszym rozwiązaniem tego problemu z interoperacyjnością jest rezygnacja ze wsparcia dla typu SPF RR”.

Ograniczenia nagłówka

Ponieważ SPF w coraz większym stopniu uniemożliwia spamerom fałszowanie adresu nadawcy, wielu przeniosło się tylko na fałszowanie adresu w polu Od nagłówka wiadomości, który jest faktycznie wyświetlany odbiorcy, a nie tylko przetwarzany przez agenta przesyłania wiadomości odbiorcy ( MTA ) . SPF (lub DKIM ) może być jednak używany razem z DMARC , aby sprawdzić również pole Od w nagłówku poczty. Nazywa się to „dopasowaniem identyfikatora”.

Niestandardowe, zastrzeżone implementacje są wymagane do ochrony przed takim fałszowaniem nazw wyświetlanych i nie mogą korzystać z SPF.

Zastosowanie

Oprogramowanie antyspamowe, takie jak SpamAssassin w wersji 3.0.0 i ASSP, implementuje SPF. Wielu agentów przesyłania poczty (MTA) bezpośrednio obsługuje SPF, takich jak Courier , CommuniGate Pro, Wildcat , MDaemon i Microsoft Exchange , lub udostępnia poprawki lub wtyczki obsługujące SPF, w tym Postfix , Sendmail , Exim , qmail i Qpsmtpd . Od 2017 r. ponad osiem milionów domen publikuje SPF FAIL -all zasady. W ankiecie opublikowanej w 2007 roku 5% domen .com i .net miało jakąś politykę SPF. W 2009 r. ciągłe badanie przeprowadzone przez Nokia Research wykazało, że 51% testowanych domen określa zasady SPF. Wyniki te mogą obejmować trywialne zasady, takie jak v=spf1 ?all . [ wymaga aktualizacji ]

W kwietniu 2007 r. BITS, oddział Financial Services Roundtable, opublikował zalecenia dotyczące bezpieczeństwa poczty e-mail dla swoich członków, w tym dotyczące wdrożenia SPF. W 2008 roku Messaging Anti-Abuse Working Group (MAAWG) opublikowała artykuł na temat uwierzytelniania poczty e-mail obejmującego SPF, Sender ID i DomainKeys Identified Mail (DKIM). W swoich „Najlepszych praktykach komunikacyjnych nadawcy” MAAWG stwierdziło: „Nadawcy powinni przynajmniej uwzględniać rekordy SPF dla swoich domen pocztowych”. W 2015 r. grupa robocza Messaging Anti-Abuse Working Group (MAAWG) dokonała przeglądu dokumentu dotyczącego uwierzytelniania poczty e-mail obejmujące SPF, DomainKeys Identified Mail (DKIM) i DMARC (DMARC). W swoich poprawionych „Najlepszych praktykach komunikacyjnych nadawcy” MAAWG stwierdził: „Uwierzytelnianie wspiera przejrzystość poprzez dalszą identyfikację nadawcy (nadawców) wiadomości, jednocześnie przyczyniając się do zmniejszenia lub wyeliminowania sfałszowanych i sfałszowanych adresów”.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=1135512216 ”