Mam prawidłowy rekord SPF, ale nadal mogę sfałszować mój e-mail

Skonfigurowałem rekord SPF dla mojej domeny, ale nadal mogę sfałszować adresy e-mail dla mojej domeny przy użyciu fałszywych usług e-mail, takich jak ten: http://deadfake.com/Send.aspx

E-mail dociera do mojej skrzynki odbiorczej Gmaila w porządku.

Wiadomość e-mail zawiera błędy SPF w takim nagłówku : spf=fail (google.com: domain of info@mydomain.com does not designate 23.249.225.236 as permitted sender)ale nadal jest dobrze, co oznacza, że każdy może sfałszować mój adres e-mail ...

Mój rekord SPF to: v=spf1 mx a ptr include:_spf.google.com -all

AKTUALIZACJA Jeśli ktoś jest zainteresowany, opublikowałem zasady DMARC wraz z moim rekordem SPF, a teraz Gmail poprawnie oznacza fałszywe wiadomości (zdjęcie)

wprowadź opis zdjęcia tutaj

email spf

— jitbit
źródło

Tak, każdy może sfałszować twoją domenę w wiadomości e-mail. Rekord SPF nie zapobiega temu, chyba że serwer odbierający wykona twarde odrzucenie w oparciu o awarię SPF, co zapewne niewielu.

— joeqwerty

Ponieważ podałeś _spf.google.com, Twoje zasady prawdopodobnie ~allnie zostaną ocenione -all. Prawdopodobnie wystarczy tylko jeden MX, Ai PTR.

— BillThor

@BillThor jako standard powoduje , że błędy słabe lub twarde oraz includerekord d są ignorowane podczas oceny wyniku końcowego; lub, jak to ujęli, „ ocena dyrektywy„ -all ”w rekordzie, do którego następuje odwołanie, nie kończy całego przetwarzania ”.

— MadHatter

@MadHatter Tak Przejrzałem poprawioną dokumentację z tym wyjaśnieniem. Nie było to jasne we wcześniejszej dokumentacji i wydaje mi się, że napotkałem implementacje, które nie czyniły tego rozróżnienia. Nie wszystkie implementacje obsługują takie przypadki krawędzi w standardowy sposób. Uważam, że być może dlatego potrzebne było wyjaśnienie.

— BillThor,

@BillThor możesz mieć rację! Jak przyznają, includepolityka nie była świetną nazwą, ponieważ wszyscy z doświadczeniem w programowaniu od razu przyjęli zestaw założeń dotyczących jej działania - niektóre z nich były niewłaściwe!

— MadHatter

Odpowiedzi:

Fakt, że reklamujesz rekord SPF, w żaden sposób nie zobowiązuje nikogo do honorowania go. Od administratorów dowolnego serwera pocztowego zależy, który e-mail zdecyduje się zaakceptować. Myślę, że są głupie, jeśli nie sprawdzą rekordów SPF i odpowiednio odrzucą, ale to zależy od nich . Wiem, że niektórzy ludzie lubią DMARC, ale myślę, że sam jest to ohydny pomysł i nie będę ponownie konfigurować mojego serwera e-mail, aby akceptował / odrzucał w oparciu o DMARC; Niewątpliwie niektórzy ludzie mają takie samo zdanie na temat SPF.

Co myślę SPF ma zrobić, to pozwalają zrzekają się wszelkich dalszych odpowiedzialności za e-mail, który twierdził, że jest z domeny, ale nie było. Każdy administrator poczty przychodzący do ciebie narzekający, że twoja domena wysyła mu spam, gdy nie zadał sobie trudu, aby sprawdzić reklamowany przez ciebie rekord SPF, który powiedziałby im, że wiadomość e-mail powinna zostać odrzucona, może zostać wysłany z pchłą do ucha.

— Szalony Kapelusznik
źródło

SPF nie może temu zapobiec. Daje to jedynie wskazówkę dla innych serwerów, że poczta jest sfałszowana, ale większość korzysta z tego tylko jednego z kilku czynników, aby zdecydować, czy poczta powinna zostać zablokowana.

— Sven
źródło

OK, dziękuję, właśnie to podejrzewałem ... Tak naprawdę jestem zaskoczony, że Gmail nie „szanuje” awarii SPF jako jakiejś flagi ostrzegawczej :(

— jitbit

@jitbit Gmail przestrzega SPF, ale SPF-Hardfail nie oznacza, że poczta jest dostarczana bezpośrednio do folderu ze spamem. Jest to jeden z wielu parametrów wykrywania spamu.

— sebix,

@sebix W końcu zmusiłem Gmaila do traktowania tego jako spamu / złośliwego oprogramowania, zobacz aktualizację w pytaniu

— jitbit

Tak, to normalne. Każdy może sfałszować dowolny adres e-mail, ale SPF (Sender Policy Framework) daje dostawcom i klientom usług e-mail możliwość lepszej identyfikacji i oznaczania jako spam lub ewentualnie całkowitego odrzucania wiadomości, jeśli jest to częścią ich procesu.

— morgant
źródło