On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote: > On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 <r...@gmx.co.uk> wrote: > > > True, but for all we know they could be preceded by a > > check_policy_service or permit_dnswl_client restriction. > > Well, in this case they're not (yet?) preceded by any of those... > but I'm learning more and more with every piece of this discussion, > and now want to play around with putting "permit_dnswl_client > list.dnswl.org=127.0.[0..255].[1..3]" somewhere in there. > > > Again, can't say. I'd have the Zen higher, before most > > whitelisting, but yes, BRBL belongs down there at the end. > > Assuming I do want put them back in, and try out > permit_dnswl_client entry (only for low, medium, and high), how > high up my smtpd_recipient_restrictions food chain should the Zen > and permit_dnswl_client entries be (realizing the Zen reject should > be above the dnswl permit)? > > Here are my current entries: > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated,
I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. > reject_invalid_hostname, Deprecated syntax for reject_invalid_helo_hostname. > reject_unauth_destination, See above re: smtpd_relay_restrictions. > warn_if_reject reject_non_fqdn_hostname, I consider this one quite safe. In fact, it's one of the CBL's listing criteria; when they see a host using a non-FQDN as HELO, it will be listed. Deprecated syntax again. > warn_if_reject reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, These are safe, but mostly pointless here. You might want them on submission, in case a user has a misconfigured MUA. > warn_if_reject reject_unknown_reverse_client_hostname, Safe, because many large receivers do this as well. > warn_if_reject reject_non_fqdn_helo_hostname, This is the new syntax for reject_non_fqdn_hostname, you do the warning twice for the same thing. > warn_if_reject reject_invalid_helo_hostname, Deja vu all over again! > warn_if_reject reject_unknown_helo_hostname, This one is NOT safe. A lot of sites use HELOs which don't resolve. So I'd not take off the warn_if_reject. > reject_unauth_pipelining, This could go higher. It's a "cheap" restriction. > check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, > check_helo_access hash:/etc/postfix/helo_access, > check_sender_access hash:/etc/postfix/check_backscatterer, > check_sender_access hash:/etc/postfix/access, "access" is not a descriptive name. I would name it either "sender_access" or whatever the general purpose of the lookup is. It could also be merged with the check_backscatterer lookup. > reject_rhsbl_client dbl.spamhaus.org, > reject_rhsbl_sender dbl.spamhaus.org, > reject_rhsbl_helo dbl.spamhaus.org, > permit > > My guess would be to either put them just after the > reject_unknown_sender_domain or just before the > check_reverse_client_hostname... but that's a total guess. > The BRBL entry I'd stick back just in front of the > reject_rhsbl_client entry. I wouldn't whitelist the check_*_access lookups, but you might choose to do that for your own reasons. I would put Zen just before the three DBL lookups. This way the DBL lookups might be avoided. I'd keep DBL before DNSWL. I doubt the DNSWL folks want to list any client sending for DBL-listed domains, so check DBL first. The "low, medium, and high" idea is good, although recently I have seen a case where BRBL listed a DNSWL "none" host (with legitimate mail, sigh.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
