Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: /dev/rob0 (rob0gmx.co.uk)
Date: Wed May 01 2013 - 07:14:37 CDT
On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
> On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 <rob0gmx.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 =
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.
Deprecated syntax for reject_invalid_helo_hostname.
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,
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.
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,
> 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
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: