Serwer pocztowy może wysłać prawidłową wiadomość z pustą ścieżką zwrotną SMTP zapisaną jako POCZTA OD:<>. Powiadomienia o stanie dostawy używają zerowej ścieżki zwrotnej poniżej RFC 5321 §4.5.5 aby uniknąć tworzenia niekończących się pętli odbić. Pusta ścieżka odwrotna nie oznacza, że jej nie ma SPF ocena do rozważenia: RFC 7208 §2.4 definiuje A POCZTA OD tożsamość przy użyciu części lokalnej naczelnik poczty i HELO domena w tym przypadku.
Administratorzy testujący tylko pocztę zwykłych użytkowników mogą zatem pominąć oddzielną ścieżkę uwierzytelniania używaną przez sam serwer.
Odróżnij HELO od widocznego nadawcy
HELO lub EHLO wprowadza klienta SMTP do serwera odbierającego. Jej domena jest oddzielona od widocznej wiadomości Z nagłówka i może różnić się od niepustej domeny MAIL FROM. Gospodarz może przedstawić się jako relay.example.com podczas przesyłania poczty użytkownika za pomocą nadawcy kopertowego pod adresem example.com.
RFC 7208 §2.3 zaleca sprawdzenie HELO osobno i zaleca zrobienie tego w pierwszej kolejności po sprawdzeniu obu tożsamości. The POCZTA Z regulaminu zależy od tego, czy przeprowadzono kontrolę HELO i uzyskano ostateczny wynik wynikający z zasad. Nie zakładaj, że każdy odbiorca wyemituje dwa niezależne wyniki SPF dla każdej wiadomości.
W przypadku kontroli HELO opisanej w dokumencie RFC podana wartość musi być prawidłową nazwą domeny z wieloma etykietami. Zniekształconej wartości lub literału adresu nie można traktować tak, jakby była to zwykła nazwa hosta, do której można wysyłać zapytania. Zamiast tworzyć wpisy DNS dla zniekształconych tożsamości, popraw konfigurację serwera wysyłającego za pomocą obsługiwanych przez niego elementów sterujących.
Opublikuj dla faktycznie używanej nazwy hosta
Przechwyć kontrolowaną transakcję SMTP lub dziennik zaufanego odbiorcy, aby ustalić wartość HELO . Następnie zapytaj SPF TXT o dokładnie tę nazwę hosta. Polityka SPF pod adresem example.com nie dotyczy automatycznie relay.example.com.
W przypadku serwera ze stabilnymi, jawnie kontrolowanymi adresami wyjściowymi adresy te można opisać wąską polityką. W przypadku hostowanej infrastruktury wysyłającej postępuj zgodnie z obsługiwaną konfiguracją i granicami własności dostawcy. Nie publikuj odgadniętego rekordu dotyczącego nazwy hosta, nad którym nie masz kontroli, ani nie zakładaj, że jest to nazwa hosta Rekord jest koniecznie adresem wyjściowym SMTP .
Uwzględnij protokół IPv6 w recenzji. Jakiś MTA może prezentować tę samą HELO w różnych rodzinach adresów, a polityka obejmująca tylko jego źródło IPv4 może dawać różne wyniki w przypadku IPv6 .
Wykonuj oddzielnie ruch normalny i z pustą kopertą
Przykładowy plan testów z wykorzystaniem adresów służących wyłącznie do dokumentacji:
- Serwer łączy się z 192.0.2.10 i przedstawia się jako
relay.example.com. - Nazwa hosta została opublikowana
v=spf1 ip4:192.0.2.10 -all. - Za wiadomość z
POCZTA OD:<>, SPF pochodzipostmaster@relay.example.comjako tożsamość MAIL FROM. To źródło jest autoryzowane przez zasady dotyczące nazw hostów. - Powtórz tę czynność, używając innego, nieautoryzowanego testowego adresu IP. Przy tych samych zasadach dotyczących nazw hostów niedopasowane źródło osiąga błąd.
Są to oczekiwane wyniki oceniającego, a nie wyniki działającego systemu. Używaj kontrolowanych, autoryzowanych odbiorców do rzeczywistych testów powiadomień. Nie prowokuj odesłań do dowolnych adresów zewnętrznych jedynie w celu obserwacji zachowania.
Zapisz tożsamość i werdykt
Zachowaj adres IP połączenia sesji, wartość HELO , ścieżkę zwrotną i wynik wygenerowany przez odbiornik. Ogólna „przepustka SPF ” bez tożsamości nie wystarczy do rozwiązywania problemów. Pomyślna wiadomość zwykłego użytkownika nie dowodzi, że poczta o zerowej ścieżce zwrotnej korzysta z tej samej domeny.
Jeśli test zakończy się niepowodzeniem, zdecyduj, czy przyczyną problemu jest ogłoszona nazwa hosta, publikacja DNS , zasoby wychodzące, czy też nieoczekiwana trasa. Zmiana zasad SPF domeny pracowniczej nie naprawi zasad dotyczących nazw hostów, które nigdy nie były sprawdzane.
Niech poczta generowana przez serwer będzie częścią kontroli zmian
Dodaj testy powiadomień do aktualizacji MTA, migracji przekaźników i włączenia protokołu IPv6 . Zachowaj poprzednią konfigurację tożsamości i zatwierdzoną ścieżkę odzyskiwania. Zamknij zmianę dopiero po ocenie zwykłej poczty i przepływów generowanych przez serwer istotnych dla Twojej organizacji. Zapobiega to ukryciu uszkodzonych powiadomień operacyjnych podczas prawidłowego testu poczty użytkownika.
Wykorzystaj dowody do podjęcia decyzji
Zachowaj oddzielne wiersze powiadomień MAIL FROM i powiadomień o ścieżce zerowej. W przypadku ścieżki zerowej i HELO = relay.example.com skonstruowany nadawca to postmaster@relay.example.com ; testowy adres IP należy ocenić pod kątem zasad tej domeny. Zwykły przekaz wiadomości użytkownika na example.com nie zapewnia takiego wyniku. Korzystaj z autoryzowanych odbiorców i kontrolowanych powiadomień; nie przeprowadzono żadnego testu odbicia ani zmiany serwera.