Dlaczego wiadomość e-mail jest dostarczana normalnie, mimo że „SPF” jest „niezawodny”?

Próbuję dowiedzieć się, dlaczego fałszywa wiadomość e-mail jest dostarczana do głównych dostawców poczty e-mail (gmail.com, outlook.com), nawet jeśli wiadomość e-mail jest oznaczona SPF hardfail. Wiadomość e-mail jest również dostarczana do Microsoft Exchange, która rzuca PermErrordla tego samego rekordu SPF.

Wysyłam wiadomość e-mail za pomocą domeny SOME_DOMAIN.com, która definiuje uszkodzony rekord SPF. Wiadomość e-mail jest przesyłana z mojego własnego adresu IP, który nie jest wyraźnie wymieniony w rekordzie SPF witryny SOME_DOMAIN.com. Rekord SPF dla witryny SOME_DOMAIN.com ma następujące trzy właściwości, pierwsze dwa stanowią naruszenie SPF RFC-4408:

1. Wymaga więcej niż 10 zapytań DNS, aby rozwiązać cały rekord SPF, z powodu include:.
2. Błąd składni w jednym z rekordów SPF, python-spf zgłasza błąd analizy.
3. Rekord SPF zawiera zarówno reguły , jak ~alli -alloba, mówiąc, że zestaw wszystkich adresów powinien softfailihardfail

Wiadomość e-mail wysłana na adres outlook.com podszywający się pod admin@SOME_DOMAIN.com będzie zawierać następujący błąd w nagłówku SMTP dostarczonej wiadomości e-mail. Ten e-mail został dostarczony normalnie do skrzynki odbiorczej użytkownika :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail dostarczy również wiadomość e-mail do skrzynki odbiorczej użytkownika, ale zgłosi inny błąd SPF:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Więc co tu się dzieje? Dlaczego poczta e-mail jest dostarczana pomimo SPF hardfail? Czy zepsuty rekord SPF oznacza, że ​​inne serwery SMTP całkowicie ignorują SPF? A może brakuje mi czegoś ...

SPF jest tak źle skonfigurowany przez tak wiele witryn, że otrzymywanie MTA często liczy się hardfailtylko jako doradztwo i po prostu uwzględnia je w swoich wynikach wykrywania spamu. Ostatecznie administrator MTA decyduje o tym, jak będą traktowane awarie SPF.

Warunki błędu SPF nie wskazują niczego na temat pożądanej polityki. Jako takie nie dostarczają wskazówek, czy przyjąć wiadomość, czy nie. Możliwe, że jest to zamierzona polityka +all. W takim przypadku przyjmowanie poczty jest normalne. Wygląda na to, że Google jest łagodny z powodu niezgodności tych domen ze standardem.

Nawet odrzucenia zasad SPF ( -all) są niewiarygodne podczas sprawdzania poprawności adresów nadawców. Istnieje wiele przypadków, w których odrzucenie takiej poczty byłoby niewłaściwe, w tym:

• Poczta wysyłana przez zakontraktowanych nadawców (osoby te otrzymują wynagrodzenie za naruszenie zasad.);
• Poczta wysyłana z formularzy internetowych i innych takich zautomatyzowanych systemów;
• Poczta przekazywana za pomocą list mailingowych lub innych mechanizmów przesyłania; i
• Po prostu błędna konfiguracja rekordów SPF (niezbyt często, ale nie dość rzadko).

Prowadzę dość niewielki serwer, na którym mogę odłożyć na ciężkie awarie. To pozwala mi na białej liście uzasadnione niepowodzenia. Jeśli nadawca zauważy, że poczta nie została dostarczona, może naprawić konfigurację. W niektórych przypadkach spróbuję skontaktować się z odpowiednimi postmaster, ale wiele domen nie ma postmasteradresu.

Użytkownicy, którzy chcą egzekwować silniejsze zasady, mogą korzystać z DMARC, co nie jest jeszcze standardem. Poczta prawdopodobnie nadal zostanie dostarczona, ale może zostać poddana kwarantannie lub odrzucona, jak określono w tych zasadach. Poczta, która nie spełnia zasad, może zostać dostarczona do folderu ze spamem, a nie do zwykłej skrzynki odbiorczej.

Trudne awarie SPF wydają się być wiarygodne do sprawdzania tożsamości serwera wysyłającego. Jakiś czas temu przeprowadziłem kilka badań i odkryłem, że nawet miękkie błędy w nazwie HELO są rozsądnym powodem do niepowodzenia lub odroczenia przychodzących wiadomości.

Wiele serwerów pocztowych nie ma rekordu SPF. Jeśli serwer pocztowy nie ma rekordu SPF, sprawdzam, czy w domenie nadrzędnej nie ma rekordu SPF. Jest to niestandardowe, ale skuteczne. Zachęcam administratorów poczty e-mail do upewnienia się, że istnieje rekord SPF dla adresu IP serwera wymienionego w rekordzie PTR. Twój serwer powinien się również identyfikować po nazwie zwróconej przez jego rekord PTR. Sprawdź, czy masz odpowiedni rekord A do odwrotnej weryfikacji DNS.