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 <unknown [67.x.x.x]>: Client host rejected: Access denied; proto=SMTP</unknown>
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 <unknown[67.x.x.x]>: 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 <unknown [67.x.x.x]>: 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</unknown>
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