🚀 go-pugleaf

jacki wrote:

> W dniu 2015-04-02 o 16:49, Sykomt pisze:
>>>> Witam,
>>>>
>>>> zapraszam do korzystania z polskiego RBL'a : rbl.polspam.pl
>>>> Szczegóły na polspam.pl
>>>>
>>>> Admin
>>>
>>> A czemu podpinać je należy pod smtpd_client_restrictions a nie pod
>>> smtpd_recipient_restrictions w postfixie?
>>>
>> Witam,
>> 
>> Z tego co wiem smtp_client_restrictions jest wykonywane przed
>> smtp_recipient_restrictions, więc postfix "ubije" to od razu,
>> bez męczenia się następnymi regułkami.
>> 
> 
> Tak, masz rację, ale ja za to jestem jakoś naturalnie przekonany, że
> wypadałoby jednak to robić w smtp_recipient_restrictions
> Nie wiem, być może to tylko moje przeświadczenie, myślę, że Lemat mógłby
> się wypowiedzieć na ten temat jak On to widzi.
> 

przy smtpd_delay_reject = no
smtpd_client_restrictions jest przetwarzane tuż po tym jak się klient 
podłączy a zanim zdąży cokolwiek wysłać.

przy smtpd_delay_reject = yes
wszystkie smtpd_(client|helo|sender|recipient|relay)_restrictions są 
przetwarzane jak klient z serwerem przeprowadzi dialog. Wtedy serwer 
dysponuje już pełną informacją na temat adresu IP klienta, helo/ehlo, 
nadawcą i odbiorcą.

zatem jeżeli zależy nam na wydajności to trzeba ustawić smtpd_delay_reject = 
no

a wtedy:
ubijanie klientów można rozpocząć w smtpd_client_restrictions
ubijanie senderów można rozpocząć dopiero w smtpd_sender_restricions

gdyż, ponieważ na etapie smtpd_client_restrictions klient nie przeprowadził 
z serwerem dialogu i serwer nie dysponuje adresem nadawcy.

jeżeli wsadzimy sprawdzanie nadawcy w smtpd_client_restrictions to postfix 
opóźni uruchomienie tego łańcucha do momentu w którym będzie znał adres 
nadawcy. Czyli zamiast uruchomić smtpd_client_restrictions na samym początku 
uruchomi to po odpowiednim dialogu czyli nici z przyspieszenia.

-- 
Pozdrawiam
Lemat