Postfiks odmowa_poznania_nazwa_rewersji_klienta_hosta: zamień domyślny nieznany_klient_odrzucany_kod (450) na 550. Dlaczego / Kiedy nie powinienem?

W codziennej walce ze SPAMem kilkakrotnie odczuwałem pokusę, by mocno egzekwować wymagania DNS od klientów łączących się z dzikim Internetem.

W szczegółach, to bym dodał reject_unknown_reverse_client_hostname ustawienia w moim UOVRFAENKGPVATGUVTKEVKQPU sekcji, na przykład:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining

W każdym razie zauważyłem, że po osiągnięciu takiego ograniczenia zachowanie Postfix jest dość „miękkie”, ponieważ domyślna wartość unknown_client_reject_codeto 450. Dlatego klient jest proszony o ponawianie próby.

Podczas sprawdzania odpowiedzi 550, spotkałem następujące oświadczenie w oficjalnej dokumentacji Postfix :

wprowadź opis zdjęcia tutaj

Absolutnie nie jestem ekspertem od całego RFC 5321 , ale jako ktoś wystarczająco dorosły , by znać RFC 821 , naprawdę nie rozumiem, dlaczego odpowiedź 550 zamiast 450 może wpłynąć na moją instancję Postfix na maksymalnym poziomie SMTP ( łamanie zgodności z RFC), szczególnie biorąc pod uwagę, że w przypadku tymczasowych błędów Postfix pozostanie przy 450, niezależnie od jawnego ustawienia.

Czy ktoś może mi pomóc zrozumieć, na czym polega problem z taką wymianą?

PS: w międzyczasie skończyłem z „zrelaksowanym” ograniczeniem:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname

postfix smtp spam

— Damiano Verzulli
źródło

Zacznę od dwóch praktycznych odpowiedzi

Pierwszą i najbardziej oczywistą odpowiedzią jest to, że w przypadku wystąpienia tymczasowego błędu DNS tymczasowe odesłanie pozwoli serwerowi pocztowemu nadawcy spróbować ponownie, dopóki błąd DNS nie zostanie naprawiony. W takim przypadku trwałe odbicie spowoduje zablokowanie faktycznej poczty z szynką przed dotarciem do Ciebie.
Drugą odpowiedzią jest to, że duża część spamu jest wysyłana za pośrednictwem botnetów, które nie mają żadnych funkcjonalnych programów do wysyłania poczty. Spryskają śmieciami tylko raz i nie będą próbować ponownie wysyłać żadnych wiadomości, niezależnie od tego, czy dana wiadomość otrzyma tymczasowy, czy stały błąd. Tak więc, używając tymczasowego błędu, blokujesz na stałe duży procent spamu, ale nadal pozwalasz szynce spróbować ponownie. (Nawiasem mówiąc, dlatego greylistowanie nadal działa i wciąż łapie dużo spamu).

Oprócz tych, istnieje również odpowiedź, która niesie więcej teorii i RFC

RFC mówi w sekcji 4.2.1. że:

Zasadniczą zasadą określania, czy odpowiedź pasuje do kategorii 4yz, czy 5yz (patrz poniżej) jest to, że odpowiedzi są 4yz, jeśli mogą się powieść, jeśli zostaną powtórzone bez zmiany formy polecenia lub właściwości nadawcy lub odbiorcy (to znaczy , polecenie jest powtarzane identycznie, a odbiornik nie wprowadza nowej implementacji).

W przypadku niepowodzenia wyszukiwania wstecznego komunikat byłby możliwy do zaakceptowania bez żadnych zmian w samym komunikacie, pod warunkiem że naprawiony zostanie błąd DNS. Dlatego powinien to być błąd tymczasowy.

W przypadku, gdy wiadomość nie jest spamem, sysadmin wysyłającego serwera poczty może zauważyć komunikat o błędzie i rozwiązać problem DNS, aby wiadomość mogła zostać dostarczona bez interwencji użytkownika i ponownego wysłania wiadomości. I chyba, że użytkownik wysyłający wiadomość e-mail jest również odpowiedzialny za serwer pocztowy i / lub jego wpisy DNS, nawet jeśli otrzyma trwałe odesłanie bezpośrednio, nie będzie w stanie nic z tym zrobić - w przeciwieństwie do np. Błędu pisowni adres.

Oczywiście nadal masz prawo do odrzucenia wiadomości e-mail z dowolnego powodu.

— Jenny D.
źródło

Myślałem o tymczasowych problemach z DNS, ale .... wydaje się, że nie powinny one stanowić problemu, ponieważ ... „ Serwer SMTP zawsze odpowiada 450, gdy mapowanie nie powiodło się z powodu tymczasowego błędu ”. Powinny one obejmować tymczasowe problemy z wyszukiwaniem DNS. Nie ty Jeśli chodzi o drugi punkt (BotNet, greylisting itp.), Brzmi to rozsądnie: gdy klienci nie wdrażają odpowiedniego mechanizmu kolejkowania, odpowiedź 4XX wywołuje takie same efekty jak 5XX. W każdym razie wciąż tęsknię za tym, dlaczego ma to wpływ na poziomie RFC.

— Damiano Verzulli

@DamianoVerzulli Miałoby to zastosowanie, gdy mapowanie kończy się niepowodzeniem z błędem, a nie gdy DNS jest źle skonfigurowany, aby zwracał niewłaściwą nazwę, a następnie zostaje naprawiony. W każdym razie nieco rozszerzyłem kwestie związane z RFC.

— Jenny D

Dziękujemy za wskazanie odpowiedniej sekcji RFC. Ja koncentruje się na to: „odpowiedzi są 4yz czy mogą być skuteczne, jeśli powtarza się bez zmian w formie poleceń lub we właściwościach tego SENDER lub odbiornika”. Po pierwsze sądzę, że nazwa hosta DNS klienta, a także odwrotne mapowanie DNS, są właściwościami nadawcy. Nie ty W przeciwnym razie nie widzę, co mogłoby być własnością nadawcy. (BTW: proszę nie traktuj moich komentarzy osobiście. Jestem naprawdę zainteresowany tą dyskusją i bardzo doceniam twoje uwagi! Dziękuję za komentarze!).

— Damiano Verzulli

@DamianoVerzulli Nazwa hosta DNS nie jest własnością wysyłającego serwera pocztowego i nie można go zmienić w konfiguracji serwera pocztowego. Jest kontrolowany przez autorytatywny serwer DNS, który zwykle nie jest nawet tym samym serwerem, a tym bardziej częścią serwera pocztowego. Czasami nie jest nawet kontrolowany w ramach tej samej organizacji. (Nie biorę tego osobiście - jest to dyskusja na temat faktów, bez żadnych argumentów ad hominem, nie ma nic do wzięcia osobiście! Zgadzam się, że jest bardzo interesujący i nie sądzę, aby był jednoznaczny, jest sprawa dla drugiej strony.)

— Jenny D.