Kiedy mówimy o „Uwierzytelnianiu e-maili”, mamy na myśli technikę, która ma na celu zapewnienie odbiorcy wiadomości pewnego poziomu pewności, że wiadomość faktycznie pochodzi z deklarowanego źródła.
Business in a box.
Odkryj nasze rozwiązania.
Porozmawiaj z naszym zespołem sprzedaży
Kiedy mówimy o „Email Authentication”, mamy na myśli technikę, która ma zapewnić odbiorcy wiadomości pewien poziom pewności, że wiadomość rzeczywiście pochodzi z deklarowanego źródła. Idea polega na osiągnięciu pewnego poziomu obrony przed oszukańczymi emailami, takimi jak phishing i spoofing, które mogą podważyć zaufanie odbiorcy do otrzymywania emaili. To powiedziawszy, samo wysyłanie uwierzytelnionej wiadomości nie oznacza, że wiadomość jest dobra czy pożądana; oznacza jedynie, że wiadomość jest taka, że reputację uwierzytelnionej strony można niezawodnie ustalić i użyć w decyzjach dotyczących akceptacji i umieszczania emaili.
Obecnie stosowane są dwie główne formy uwierzytelniania emaili—Sender Policy Framework (SPF) i DomainKeys Identifed Mail (DKIM). W tym poście na blogu wyjaśnię, czym jest SPF i jak działa.
SPF Przegląd
Sender Policy Framework (SPF), parafrazując RFC 7208, to protokół, który nie tylko pozwala organizacji autoryzować hosty i sieci do używania jej nazw domenowych przy wysyłaniu e-maili, ale także zapewnia sposób, w jaki host odbiorca może sprawdzić tę autoryzację.
Po przeczytaniu tego posta mam nadzieję, że nauczysz się następujących rzeczy:
SPF to system uwierzytelniania „oparty na ścieżce”.
Zasady SPF są deklarowane w rekordach TXT DNS.
Walidacja jest przypisana do domeny Return-Path (co tu w SparkPost nazywamy „domeną bounce”) lub domeny HELO.
Walidacja może być wykonana wcześnie w transakcji SMTP, więc jest to dobre sprawdzenie, aby szybko odrzucić niezweryfikowaną pocztę.
Jest podatne na stosunkowo wysoki procent fałszywych negatywnych wyników.
„Path-Based” Authentication
SPF jest uważany za system uwierzytelniania oparty na ścieżce, ponieważ jest związany wyłącznie ze ścieżką, którą przeszedł komunikat od swojego pochodzenia do miejsca przeznaczenia. Gdy serwer wysyłający inicjuje transakcję SMTP z serwerem odbierającym, serwer odbierający ustala, czy serwer wysyłający jest uprawniony do wysłania tej wiadomości na podstawie polityki SPF domeny. Jest to wyłącznie decyzja oparta na tym, skąd pochodzi wiadomość, i nie ma nic wspólnego z jej treścią.
Deklarowanie polityki SPF
Rekord polityki SPF domeny to po prostu specjalnie sformatowany rekord DNS TXT, zwykle zawierający jeden lub więcej z następujących „mechanizmów”:
v=spf1 – Wymagany pierwszy token, aby wskazać, że rekord TXT jest rekordem SPF (domena może mieć wiele rekordów TXT)
ipv4, ipv6 – Używane do określenia adresów IP i sieci, które są uprawnione do wysyłania poczty dla domeny
a – Jeśli domena wysyłająca ma rekord DNS „A”, który rozwiązuje się do wysyłającego IP, to IP jest dozwolone
mx – Jeśli wysyłający IP jest również jednym z rekordów MX dla domeny wysyłającej, to IP jest dozwolone
all – Wymagany ostatni token, zawsze modyfikowany:
-all – Tylko to, co jest tutaj wymienione, może przejść; odrzuć odrzucone.
~all – Elementy, które nie są tutaj, powinny miękko zbaczać; zaakceptować je, ale zanotować.
?all – Nie jesteśmy pewni, czy elementy, które nie są tutaj, powinny przejść.
+all – Uważamy, że SPF jest bezużyteczne; przepuścić wszystko.
Inne mniej powszechne mechanizmy, które nadal są szeroko stosowane, to:
include – Używane, gdy domena nie tylko posiada własne serwery, ale także korzysta z serwerów innych osób. Musi być stosowane rozważnie. Każde include to kolejne zapytanie DNS, a zapisy SPF nie mogą wymagać więcej niż dziesięciu zapytań DNS do rozwiązania.
redirect – Kiedy domena A i domena B są własnością tego samego podmiotu i używają tej samej infrastruktury. Właściciele zazwyczaj chcą utrzymywać tylko jedną kopię rekordu SPF dla obu i skonfigurować B, aby przekierowywał zapytania do A.
exists – Jeśli domena ma wiele małych, nieciągłych bloków sieciowych, może wykorzystać ten mechanizm do określenia swojego rekordu SPF, zamiast wymieniać je wszystkie. Przydatne, aby pozostać w limicie rozmiaru (512 bajtów) dla odpowiedzi DNS.
Uwaga odnośnie mechanizmu „ptr”
Ostateczny mechanizm, „ptr”, istniał w oryginalnej specyfikacji dla SPF, ale został ogłoszony jako „nie używać” w obecnej specyfikacji. Mechanizm ptr był używany do deklarowania, że jeśli adres IP wysyłający miał rekord DNS PTR, który rozwiązywał się do nazwy domeny, to ten adres IP był uprawniony do wysyłania poczty dla domeny.
Obecny stan tego mechanizmu jest taki, że nie powinien być używany. Jednak witryny wykonujące walidację SPF muszą go akceptować jako ważny.
Niektóre przykładowe rekordy SPF
Oto kilka przykładowych rekordów i ich znaczenie. Ten przykład pokazuje adresy RFC 1918, ale zdaję sobie sprawę, że takie adresy nigdy nie pojawią się w prawdziwych rekordach SPF.
Rekord MX, jeden adres IP, jedna sieć IP, miękki brak sukcesu dla reszty:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Rekord A, dwie sieci IP, odrzucić resztę:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nie wysyłamy żadnej poczty:
“v=spf1 -all”
Uważamy, że SPF jest głupie:
“v=spf1 +all”
Rekord SPF dla domeny sparkpostmail.com (użyty mechanizm przekierowania)
“v=spf1 redirect=_spf.sparkpostmail.com”
Rekord SPF dla _spf.sparkpostmail.com (użyto mechanizmów exists i ptr):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
W SparkPost obecnie używamy mechanizmu ptr w naszym rekordzie SPF. Uznaliśmy to za konieczne z powodu braku powszechnego wsparcia dla walidacji mechanizmu exists. Do tej pory nie zauważyliśmy żadnych awarii SPF wynikających z używania mechanizmu ptr.
Jak działa uwierzytelnianie SPF?
Oto jak wygląda typowa transakcja SMTP, gdy uwzględniony jest SPF:
Serwer wysyłający (klient) łączy się z serwerem odbierającym
Serwer odbierający zapisuje łączący się adres IP klienta
Wymieniają pozdrowienia, w tym nazwę hosta HELO klienta
Klient wydaje polecenie SMTP MAIL FROM
Serwer odbierający może teraz sprawdzić rekord SPF dla domeny MAIL FROM lub nazwy hosta HELO, aby określić, czy łączący się IP jest upoważniony do wysyłania poczty dla domeny, i zdecydować, czy zaakceptować wiadomość.
MAIL FROM lub HELO – Które sprawdzić?
Specyfikacja SPF stanowi, że odbierające serwisy MUSZĄ sprawdzać SPF dla domeny MAIL FROM i ZALECA się jej sprawdzanie dla nazwy hosta HELO. W praktyce sprawdzanie odbywa się tylko na domenie MAIL FROM, chyba że w przypadkach, gdy adres MAIL FROM jest adresem nadawcy NULL (tj. "<>"), w takim przypadku jedyną dostępną tożsamością jest nazwa hosta HELO.
SPF nie jest niezawodny
Chociaż wydaje się to stosunkowo prosty sposób uwierzytelniania poczty e-mail, SPF jest podatny na błędy w postaci fałszywych negatywów. Te błędy mogą występować częściej, niż wielu osobom odpowiada.
Oto dwa powszechne scenariusze, w których całkowicie legalna poczta może nie zdać weryfikacji SPF i wydawać się oszukańcza:
Zautomatyzowane przekazywanie, gdzie wiadomość wysłana do jsmith@alumni.university.edu, skrzynka pocztowa ustawiona na automatyczne przekazywanie całej poczty do jsmith@isp.com
Listy mailingowe, gdzie poczta wysłana do talk-about-stuff@listserv.foo.com zostaje „rozłożona” i wysłana do każdego subskrybenta
W obu tych przypadkach, jeśli Return-Path nie jest zmieniona od oryginału, poczta może nie przejść sprawdzeń SPF (w zależności od modyfikatora użytego z mechanizmem 'all'). Dzieje się tak, ponieważ dociera do swojego ostatecznego miejsca przeznaczenia z serwera pośredniego, a nie oryginalnego, i ten serwer pośredni prawdopodobnie nie znajduje się w rekordzie SPF domeny. Technika zwana „Sender Rewriting Scheme” lub „SRS” może zmniejszyć to ryzyko, i niektóre większe strony ją przyjęły, ale nie jest to rozwiązanie uniwersalne.
Podsumowanie
Tak więc to jest uwierzytelnianie SPF, jak to działa, jak zadeklarować politykę SPF i jakie są pułapki związane z używaniem SPF. SPF był pierwszym schematem uwierzytelniania e-maili, który osiągnął szerokie zastosowanie, ale nie jest jedynym dostępnym. Uwierzytelnianie SPF jest najskuteczniejsze, gdy jest stosowane w połączeniu z innymi technikami anty-fraudowymi.
