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
Gdy mówimy o „Email Authentication”, mamy na myśli technikę, która ma na celu zapewnienie odbiorcy wiadomości pewnego poziomu pewności, że wiadomość faktycznie pochodzi od deklarowanego źródła wiadomości. Idea polega na osiągnięciu pewnego poziomu obrony przed oszukańczymi emailami, takimi jak phishing i spoofing, które mogą podważać zaufanie odbiorcy do odbieranych wiadomości email. To powiedziawszy, samo wysyłanie uwierzytelnionych wiadomości email nie oznacza samo w sobie, że email jest dobry lub pożądany; oznacza to tylko, że poczta jest taka, że można wiarygodnie ustalić reputację uwierzytelnionej strony i wykorzystać ją w decyzjach dotyczących akceptacji i umieszczania wiadomości email.
Istnieją dwie główne formy uwierzytelniania emaili stosowane obecnie—Sender Policy Framework (SPF) i DomainKeys Identified Mail (DKIM). W tym wpisie 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 odbierający może sprawdzić tę autoryzację.
Po przeczytaniu tego posta mam nadzieję, że dowiesz się następujących rzeczy:
SPF to system uwierzytelniania oparty na "ścieżkach".
Polityki SPF są deklarowane w rekordach DNS TXT.
Weryfikacja jest związana z domeną Return-Path (co tutaj w SparkPost nazywamy "bounce domain") lub domeną HELO.
Weryfikacja może być wykonana wcześnie w transakcji SMTP, więc to dobry sposób, aby szybko odrzucić nieautoryzowaną pocztę.
Jest narażony na stosunkowo wysoki odsetek fałszywych negatywów.
„Path-Based” Authentication
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 zaangażowane jest SPF:
Serwer wysyłający (klient) łączy się z serwerem odbierającym
Serwer odbierający notuje adres IP, z którego łączy się klient
Wymieniają się powitaniami, 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 ustalić, czy łączący się adres IP jest uprawniony 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.
