Czy „~ all” w środku rekordu SPF sygnalizuje koniec rekordu podczas jego parsowania?

Format rekordu SPF naszej firmy jest następujący:

„v = spf1 obejmują: _spf.google.com ~ all a mx ip4: XX0.0 / 23 obejmują: spf.example.com? wszystko”

Mamy więc „~ all” w środku naszego rekordu SPF. Na stronie openspf.com mówią to w odniesieniu do mechanizmu „wszystko”:

Ten mechanizm zawsze pasuje. Zwykle idzie na końcu rekordu SPF.

Tak więc, nie mówią, że „wszyscy” muszą przejść na koniec rekordu SPF, ale że ZWYKLE idzie na koniec.

W naszej firmie ostatnio widzimy pewne błędy w wiadomościach e-mail wysyłanych z serwerów wymienionych w naszym rekordzie SPF, ale nasz rekord SPF przechodzi wszystkie narzędzia sprawdzania poprawności, które do tej pory znalazłem.

Zastanawiam się, czy to „~ all” bezpośrednio po dołączeniu do Google Apps (_spf.google.com) spowoduje zatrzymanie analizowania i nierozpoznanie pozostałych fragmentów rekordu SPF? Czy przekazywanie vs. miękka awaria zależą od tego, kto je analizuje i od ich konkretnej implementacji przetwarzania rekordów SPF? Czy jest jakiś powód, aby mieć mechanizm „wszystko”, którego nie ma na końcu rekordu SPF?

I tak, wiem, że moglibyśmy po prostu zmienić nasz rekord SPF. To pytanie dotyczy raczej wyjaśnienia, jak to wszystko działa, a niekoniecznie rozwiązania naszej konkretnej sytuacji.

RFC 7208 § 5.1 mówi o tym wprost: po allpojawieniu się, wszystko po nim MUSI zostać zignorowane.

Mechanizmy po „wszystkim” nigdy nie będą testowane. Mechanizmy wymienione po „wszystkich” MUSZĄ zostać zignorowane. Każdy modyfikator „przekierowania” ( sekcja 6.1 ) MUSI zostać zignorowany, gdy w rekordzie znajduje się mechanizm „wszystko”, niezależnie od względnej kolejności terminów.

Przestarzałe RFC , RFC 4408 , mówiło to samo; nowsza wersja RFC po prostu wyjaśnia intencję.

Mechanizmy po „wszystkim” nigdy nie będą testowane. Każdy modyfikator „przekierowania” ( sekcja 6.1 ) nie działa, gdy istnieje mechanizm „wszystko”.

Zatem zgodne implementacje SPF całkowicie zignorują wszystko po pierwszym ~all. Nie oznacza to jednak, że każda implementacja jest zgodna ze specyfikacją. W szczególności uznano to za godne wyjaśnienia właśnie dlatego , że co najmniej jedna implementacja nie była zgodna.

Wcale nie jest jasne, dlaczego narzędzie do sprawdzania poprawności online nie wyłapało tej błędnej konfiguracji, ale jeśli zamierzasz allużyć czegoś po pierwszym użyciu, powinieneś poprawić zapis, ponieważ odpowiednie implementacje go zignorują.

„v = spf1 obejmują: _spf.google.com ~ all a mx ip4: XX0.0 / 23 obejmują: spf.example.com? wszystko”

mówi w kolejności:

„e-mail przekazujący rekord SPF _spf.google.comjest ważny dla naszej domeny”

„softfail na wszystkich innych nadawcach dla naszej domeny”

„wiadomości e-mail pochodzące z naszych rekordów A są ważne w naszej domenie”

„wiadomości e-mail pochodzące z naszych rekordów MX są ważne w naszej domenie”

„e-mail pochodzący z zakresu adresów IP x.x.0.0/23jest ważny dla naszej domeny”

„e-mail przekazujący rekord SPF spf.example.comjest ważny dla naszej domeny”

„wiadomości e-mail od wszystkich innych nadawców dla naszej domeny nie można zweryfikować w ten czy inny sposób”

Zgodnie ze składnią Record:

Mechanizmy są oceniane w kolejności. Jeśli żaden mechanizm lub modyfikator nie pasuje, domyślnym wynikiem jest „Neutralny”.

Więc dla ciebie, gdy tylko trafi w „softfail dla wszystkich innych”, to naprawdę o to chodzi ... powinno ignorować pozostałe mechanizmy, które określiłeś.

Twój rekord SPF powinien być możliwie zwięzły. Bardzo wątpię, że masz całą sieć / 23, która powinna wysyłać wiadomości e-mail dla Twojej domeny, podobnie jak wszystkie twoje rekordy A. Może tak ... ale najprawdopodobniej nie.

Ładny czysty rekord SPF powinien wyglądać mniej więcej tak:

„v = spf1 obejmują: _spf.google.com obejmują: spf.example.com mx -all”

Co w zasadzie powiedziałoby, że _spf.google.com, spf.example.com i twoje rekordy MX są jedynymi prawidłowymi nadawcami dla Twojej domeny ... wszystko inne powinno być traktowane jako nieprawidłowe.

Prawidłowo wdrożony sprawdzania SPF będzie zwarcie na mechanizm meczu i funkcji check_host () zwróci wartość kwalifikatora jako wynik. Nie mam żadnych danych z „prawdziwego świata”, które mogłyby dostarczyć ci informacji na temat tego, czy większość serwerów e-mail przestrzega RFC, czy nie.

Źródło: RFC7208 (patrz strona 17)