Le 30/10/2009 16:05, /dev/rob0 a écrit :
On Friday 30 October 2009 09:52:44 Simon Morvan wrote:
Hello folks,
I've got some checks setup like that :
smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_sender_access hash:/etc/postfix/white_senders,
check_client_access hash:/etc/postfix/white_clients,
check_recipient_access hash:/etc/postfix/white_recipients,
reject_rbl_client sbl-xbl.spamhaus.org,
Consider Zen here. It also incorporates the (not-quite-so) new PBL,
which has been very effective here.
The last time I tried it, Zen included too many legitimate users behind
ADSL lines. The "Policy" behind PBL is a bit too restrictive. Maybe it
changed, I'll give it another try.
reject_rhsbl_sender dsn.rfc-ignorant.org,
check_policy_service inet:10.18.0.100:60000,
I notice that event if the recipient address doesn't exists, the
check_policy_service (greylist) got evaluated, causing higher load than
needed. Isn't reject_unauth_destination there to block inexistent
recipients ?
If the load of a policy service is a problem for you, you should
consider increasing your resources, i.e., throw more money at it. :)
That notwithstanding, I know that's not your real question, which
appears to be confusion of reject_unauth_destination with
reject_unlisted_recipient; see:
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient
Thanks to all repliers abount reject_unlisted_recipient, i'll try to
search the F** manual a bit deeper the next time :).
Btw, I was telling "load" for "human load" :). There is no point of
greylisting mail for unexistant recipients. It increase the greylist
pending database and make it harder for me to find the legitimate
servers I should whitelist.
--
Simon.
