Czy używanie SOFTFAIL zamiast FAIL w rekordzie SPF jest uważane za najlepszą praktykę?

31

Lub inaczej mówiąc, czy używanie jest v=spf1 a mx ~allzalecane zamiast używania v=spf1 a mx -all? RFC nie wydaje żadnych zaleceń. Zawsze wolałem używać FAIL, co powoduje, że problemy stają się natychmiast widoczne. Uważam, że w przypadku SOFTFAIL niepoprawnie skonfigurowane rekordy SPF mogą trwać w nieskończoność, ponieważ nikt tego nie zauważa.

Wydaje się jednak, że wszystkie przykłady, które widziałem online, używają SOFTFAIL. To, co skłoniło mnie do pytania, to wybór, kiedy zobaczyłem instrukcje Google Apps dotyczące konfigurowania SPF:

Utwórz rekord TXT zawierający ten tekst: v = spf1 include: _spf.google.com ~ all

Opublikowanie rekordu SPF, który używa -all zamiast ~ all, może powodować problemy z dostarczaniem. Zobacz zakresy adresów IP Google, aby uzyskać szczegółowe informacje na temat adresów serwerów pocztowych Google Apps.

Czy przykłady są zbyt ostrożne, zmuszając do użycia SOFTFAIL? Czy istnieją dobre powody, dla których korzystanie z SOFTFAIL jest najlepszą praktyką?

Michael Kropat
źródło

Odpowiedzi:

21

Cóż, z pewnością nie było to celem specyfikacji, aby zamiast tego była używana - softfail ma służyć jako mechanizm przejściowy, w którym można oznaczać wiadomości bez ich całkowitego odrzucania.

Jak się okazało, brakujące wiadomości wprost powodują problemy; niektóre legalne usługi, na przykład, sfałszują adresy Twojej domeny, aby wysyłać pocztę w imieniu użytkowników.

Z tego powodu mniej drakoński softfail jest zalecany w wielu przypadkach jako mniej bolesny sposób na uzyskanie dużej ilości pomocy, jaką oferuje SPF, bez niektórych bólów głowy; filtry antyspamowe adresata nadal mogą traktować ten softfail jako wyraźną wskazówkę, że wiadomość może być spamem (co wielu robi).

Jeśli masz pewność, że żadna wiadomość nie powinna pochodzić z innego węzła niż ten, który podałeś, to na pewno użyj fail zgodnie z zamierzonym standardem SPF ... ale jak zauważyłeś, softfail zdecydowanie przekroczył swój zamierzony cel posługiwać się.

Shane Madden
źródło
2
Tak więc, o ile nie wystąpią szczególne okoliczności wymagające użycia SOFTFAIL, bezpiecznie jest trzymać się przy FAIL. Niesamowite. Dzięki.
Michael Kropat
1
@Shane, Jeśli chodzi o „niektóre legalne usługi sfałszują adresy Twojej domeny” (akapit 2), jakie są przykłady, o których mówiłeś?
Pacerier
1
Sfałszowanie nagłówka od: jest w porządku. Żadna legalna usługa nie podszyje się pod kopertę Od, która jest jedynym nadawcą, o którym SPF ma cokolwiek do powiedzenia - żaden inny serwer w Internecie nie ma firmy wysyłającej e-maile podczas przekierowywania do mnie wiadomości, co jest formalną funkcją koperty Od .
MadHatter obsługuje Monikę
7

-wszystko powinno być zawsze używane BEZ WYJĄTKU. Nieużywanie go oznacza otwarcie się na kogoś, kto fałszuje twoją nazwę domeny. Gmail na przykład ma ~ wszystko. Spamerzy cały czas podszywają się pod adresy gmail.com. Standard mówi, że musimy akceptować e-maile od nich z powodu ~ wszystkich. Ja osobiście nie przestrzegam tego standardu, ponieważ zdałem sobie sprawę, że większość z was źle skonfigurowała swoje rekordy SPF. Egzekwuję ~ wszyscy, wszyscy, tak jak ja-wszyscy. Składnia SPF Błędy SPF

północ
źródło
5
Popieram tę opinię. Dla mnie jedynym powodem Softfail są testy. Jeśli aktualizujesz swój rekord SPF, nie ma powodu, aby używać softfaila. Jeśli tego nie zrobisz, nie ma żadnego powodu do SPF. Nie sądzę, aby jakakolwiek legalna usługa mogła sfałszować swój e-mail pochodzący z Twojej domeny.
Tim
Zakwestionowałbym to: ponieważ to zależy. Jeśli wszyscy korzystający z tej domeny znają implikacje, jest to absolutnie w porządku. Ale nie zapominaj: wiadomości z formularzy kontaktowych na stronie internetowej mogą zostać utracone bez uprzedzenia. Często te wiadomości są skonfigurowane do przekazywania wiadomości pocztą w Twoim imieniu. ALE jeśli konfigurujesz pocztę dla kogoś innego, nie rób tego. Nie wiedzą, że formularze kontaktów nie przechodzą, a to uniemożliwia im skonfigurowanie adresu e-mail jako wygodnego aliasu u innego dostawcy, np. Gmail.
śr.
5

W moim rozumieniu Google ocenia nie tylko SPF, ale także DKIM i ostatecznie DMARC. DMARC bierze pod uwagę zarówno podpisywanie SPF, jak i DKIM. Jeśli którykolwiek z nich jest prawidłowy, Gmail zaakceptuje wiadomość e-mail, ale jeśli obie się nie powiedzą (lub nie powiedzie się), będzie to wyraźny sygnał, że wiadomość e-mail może być fałszywa.

To jest ze stron DMARC Google :

Komunikat musi zakończyć się niepowodzeniem zarówno sprawdzania SPF, jak i DKIM, aby również nie udał się DMARC. Niepowodzenie pojedynczego sprawdzenia przy użyciu dowolnej technologii pozwala na przekazanie komunikatu DMARC.

Dlatego myślę, że byłoby zalecane użycie SPF w trybie softfail, aby pozwolić mu wejść w większy algorytm analizy poczty.

Darwin
źródło
1
Bardzo ciekawe, chociaż nie widzę, jak wniosek wynika z przesłanek. Jeśli DMARC może przekazać z SPF FAIL lub SPF SOFTFAIL, to jakie to ma znaczenie, który wybierzesz?
Michael Kropat,
4
Myślę, że jeśli ustawisz rekord SPF na FAIL, to nawet nie przejdzie on do oceny DMARC ... ale mogę się mylić. Specyfikacje nie są jasne na ten temat ...
darwin
ad SPF Fail vs SoftFail: a) ma to znaczenie dla osób bez zaimplementowanego DMARC b) nawet gdy DMARC nie powiedzie się sam SPF może być powodem do oznaczenia twojej wiadomości jako spam, podczas gdy SoftFail nie byłby sprawą. par.
Vlastimil Ovčáčík
ad SPF Fail zapobiega ewaluacji DMARC : jeśli jest zaimplementowany, DMARC jest zawsze oceniany, ponieważ a) jeśli SPF i / lub DKIM przejdzie, DMARC musi sprawdzić wyrównanie b) jeśli oba zawiodą, DMARC musi zaktualizować statystyki raportu awarii.
Vlastimil Ovčáčík
1

Być może powodem, dla którego wciąż używana jest funkcja softfail, jest to, że wielu użytkowników (słusznie lub niesłusznie) przekazuje konfigurację, być może z służbowego adresu e-mail do domu, zostanie to odrzucone, jeśli włączona zostanie funkcja hardfail

Jon Redwood
źródło
2
Jeśli zrobią to wbrew radom administratorów poczty, zasłużyli na niepowodzenie e-maila.
MadHatter obsługuje Monikę
1
@MadHatter przesyłane wiadomości e-mail mają zachowanego nadawcę koperty, więc sprawdzany byłby (i najprawdopodobniej nieudany) rekord SPF źródła, a nie rekord SPF pracodawcy. Jeśli serwer pocztowy pracodawcy zaktualizuje nadawcę kopert, zostanie on zaktualizowany do wartości, która nie zawiodłaby, ponieważ nie byłoby różnicy między przesyłaną i normalną pocztą wychodzącą (w odniesieniu do SPF).
Vlastimil Ovčáčík
1
@ VlastimilOvčáčík masz rację, lub inaczej: jeśli przekażesz SRS, nic ci nie będzie. Jeśli tego nie zrobisz, nie zrobisz tego i unikanie -allpo prostu pomocy innym osobom (np. Nie-SRS) w ustawieniach przekazywania nie jest dobrym pomysłem.
MadHatter obsługuje Monikę