On Thursday 27 October 2011 10:32:54 Simon Brereton wrote: > I know this gets beaten to death on a regular basis, but sometimes
Indeed it does, such as ... today! Read the "Config check" thread. > I get in a muddle and I'd appreciate a sanity check. Currently my > main.cf looks like: > > ## SPAM STUFF and REJECT CODES ## > smtpd_recipient_restrictions = reject_non_fqdn_sender, > reject_non_fqdn_recipient, > permit_sasl_authenticated, > reject_sender_login_mismatch, > check_helo_access hash:/etc/postfix/helo_checks, > check_sender_access hash:/etc/postfix/ip_whitelist, > check_recipient_access hash:/etc/postfix/laxdomains, > check_sender_access hash:/etc/postfix/backscatter In that thread I mentioned why this is a bad idea. > reject_invalid_hostname, > reject_non_fqdn_hostname, ... and that this syntax is deprecated ... > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, ... but here you are with the same restrictions' new syntax! > reject_unknown_helo_hostname, I mentioned this one too. > check_reverse_client_hostname_access > pcre:/etc/postfix/fqrdns.pcre, permit_mynetworks, > check_policy_service inet:127.0.0.1:10031, > reject_unlisted_recipient, > reject_unauth_destination, > check_policy_service unix:private/policy-spf, > reject_rbl_client bl.spamcop.net, I wouldn't trust Spamcop for outright rejection, but it is useful in postscreen(8) scoring. > reject_rbl_client cbl.abuseat.org, > reject_rbl_client zen.spamhaus.org, CBL is part of Zen. > reject_rbl_client blackholes.mail-abuse.org, > reject_rbl_client tw.countries.nerd.dk, > reject_rbl_client kr.countries.nerd.dk, > reject_rbl_client cn.countries.nerd.dk, I don't know those. > reject_rbl_client relays.mail-abuse.org, > reject_rhsbl_sender dsn.rfc-ignorant.org, I'd only use the RFCI lists in scoring, too. > warn_if_reject, > reject_unknown_client, > warn_if_reject, > reject_rhsbl_client dsn.rfc-ignorant.org, > warn_if_reject, > reject_rbl_client dnsbl.sorbs.net, > warn_if_reject, > reject_rbl_client dnsbl.njabl.org, > warn_if_reject, > reject_rbl_client dul.dnsbl.sorbs.net, > permit > > > This stuff builds up over time and I find I can't always remember > the rational for putting things in the order I put them. One > point of concern that I have is that when I added in the > policy-spf the warnings were clear that it needs to go after > reject_unauth_destination otherwise it turns the box into an open > relay. The same logic should apply to the policyd service, yes? As well as to anything which might return permit or OK. See the other thread, and the link posted therein. > But yet there it is above reject_unauth_destination and the online > but http://www.checkor.com/ and > http://verify.abuse.net/cgi-bin/relaytest says I'm not an open > relay, so I'm confused. You probably are open for certain relay attempts. An online checker cannot test for all possible combinations of sender, EHLO, et c. > Looking over the list though, I propose: > > ## SPAM STUFF and REJECT CODES ## > smtpd_recipient_restrictions = reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_sender_login_mismatch, > # shouldn't this be before permit_sasl? Yes, if you're using that. Also a good idea to put user submission on a separate smtpd(8) service. > permit_sasl_authenticated, > check_helo_access hash:/etc/postfix/helo_checks, > check_sender_access hash:/etc/postfix/ip_whitelist, > check_recipient_access hash:/etc/postfix/laxdomains, > #domains that don't want grey-listing and rigourous helo checking - > would be better to put this after unknown_recipient_domain, yes? > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, > reject_unknown_helo_hostname, > check_reverse_client_hostname_access > pcre:/etc/postfix/fqrdns.pcre, check_sender_access > hash:/etc/postfix/backscatter > # the other items will catch more and should therefore come first, > yes? permit_mynetworks, > reject_unlisted_recipient, > reject_unauth_destination, > # does the order of reject_unlisted and reject_unauth matter? Both > are mysql lookups but domain should come before recipient, no? > check_policy_service unix:private/policy-spf, > check_policy_service inet:127.0.0.1:10031, > # makes sense to put the grey-listing after SPF verified hosts, > yes? reject_rbl_client bl.spamcop.net, > reject_rbl_client cbl.abuseat.org, > reject_rbl_client zen.spamhaus.org, > reject_rbl_client blackholes.mail-abuse.org, > reject_rbl_client tw.countries.nerd.dk, > reject_rbl_client kr.countries.nerd.dk, > reject_rbl_client cn.countries.nerd.dk, > reject_rbl_client relays.mail-abuse.org, > reject_rhsbl_sender dsn.rfc-ignorant.org, > warn_if_reject, > reject_unknown_client, > warn_if_reject, > reject_rhsbl_client dsn.rfc-ignorant.org, > warn_if_reject, > reject_rbl_client dnsbl.sorbs.net, > warn_if_reject, > reject_rbl_client dnsbl.njabl.org, > warn_if_reject, > reject_rbl_client dul.dnsbl.sorbs.net, > # can I group all the warn_if_rejects? > Permit > > I'd be grateful for comments/suggestions. Are there newer/better > RBLs I should be using? Quality of DNSBL is more important than quality. I have posted my postscreen rules which are doing a very good job. I'd recommend that you look that up and consider upgrading if you are pre-2.8. Also, the Barracuda BRBL is a very nice service, almost on par with Zen in terms of effectiveness, and has seemed very safe here. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
