Postfix: ciekawy problem z smtpd_delay_reject i permit_sasl_authenticated

Trafił mi się ostatnio ciekawy problem – otóż standardowo przed końcem roku poprawiałem filtry antyspamowe i optymalizowałem konfigurację Postfix’a. Chciałem zmienić domyślną wartość smtpd_delay_reject=yes na smtpd_delay_reject=no by odrzucać spamerów najwcześniej jak to możliwe. I ciekawe kuku, które sobie zrobiłem polegało na tym że sam nie mogłem wysyłać poczty po logowaniu SSL’em…

Dostawałem przy tym bardzo wymowną odpowiedź:

Oct  8 16:30:39 tyr postfix/smtpd[21039]: NOQUEUE: reject: CONNECT from unknown[67.x.x.x]: 554 5.7.1 : Client host rejected: Access denied; proto=SMTP

Więc wrzuciłem debug_peer_list = 67.x.x.x do main.cf by zobaczyć dokładniej o co biega:

Oct  8 16:47:49 tyr postfix/smtpd[23899]: >>> START Client host RESTRICTIONS < <<
Oct  8 16:47:49 tyr postfix/smtpd[23899]: generic_checks: name=permit_sasl_authenticated
Oct  8 16:47:49 tyr postfix/smtpd[23899]: generic_checks: name=permit_sasl_authenticated status=0
Oct  8 16:47:49 tyr postfix/smtpd[23899]: generic_checks: name=reject
Oct  8 16:47:49 tyr postfix/smtpd[23899]: NOQUEUE: reject: CONNECT from unknown[67.x.x.x]: 554 5.7.1 : Client host rejected: Access denied; proto=SMTP
Oct  8 16:47:49 tyr postfix/smtpd[23899]: generic_checks: name=reject status=2
Oct  8 16:47:49 tyr postfix/smtpd[23899]: > unknown[67.x.x.x]: 554 5.7.1 : Client host rejected: Access denied
Oct  8 16:47:49 tyr postfix/smtpd[23899]: watchdog_pat: 0xb82c67f8
Oct  8 16:47:53 tyr postfix/smtpd[23899]: < unknown[67.x.x.x]: QUIT
Oct  8 16:47:53 tyr postfix/smtpd[23899]: > unknown[67.x.x.x]: 221 2.0.0 Bye

generic_checks: name=permit_sasl_authenticated status=0 sugeruje że autoryzacja jest ok, a chwile później reject. Sprawdziłem konfigurację SASL’a (z dovecot’a) i zaczynałem bezskutecznie komentować kolejne linie w main.cf. Jaja polegały na tym że po ustawieniu smtpd_delay_reject=yes wszystko wracało do normy… Ale nie chciałem tego tak zostawić.
Olśniło mnie dopiero po chwili – przecież połączenia SSL SMTP odbywają się na inny port – zdefiniowany w master.cf – może coś tam bruździ. A tutaj od razu rzuciła mi się w oczy różnica w konfiguracji dla usługi submission i ssmtp:

submission inet n       -       -       -       -       smtpd
  ...
  -o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject
  ...

smtps     inet  n       -       -       -       -       smtpd
  ...
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  ...

Submission ustawiałem niedawno i widocznie trafiłem na lepszego FAQ’a 🙂 Wygląda na to że sprawdzanie autoryzacji SASL w smtpd_client_restrictions odbywało się w tym przypadku zanim klient się autoryzował (albo było jakieś lekkie opóźnienie). Zamiana smtpd_client_restrictions na smtpd_sender_restrictions załatwiło sprawę. Przy okazji zauważyłem że po SSL’u można było spooflować innych użytkowników co również postanowiłem szybko naprawić. A wszystko dlatego że zachciało mi się “wczesnych optymalizacji” i chciałem w tych usługach pominąć część checków, które mam w main.cf.

W minimalnej wersji konfiguracja w master.cf powinna wyglądać tak:

submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_auth_only = yes
  -o smtpd_sasl_auth_enable=yes
smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

P.S. Znalazłem potencjalnego winnego – w dokumentacji dovecot’a wykorzystano smtpd_client_restrictions: http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL

Leave a Reply

Your email address will not be published. Required fields are marked *