Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)
- On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
> On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 <rob0@...> wrote:I don't put these permit_* in global restrictions; I only apply them
> > 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 =
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,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,"access" is not a descriptive name. I would name it either
> check_helo_access hash:/etc/postfix/helo_access,
> check_sender_access hash:/etc/postfix/check_backscatterer,
> check_sender_access hash:/etc/postfix/access,
"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,I wouldn't whitelist the check_*_access lookups, but you might choose
> 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.
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:
- On 5/14/2013 11:45 AM, Steve Jenkins wrote:
> On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <rob0@...> wrote:"permits" always come before "rejects". Thus whitelist type entries
>> On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote:
>>> smtpd_recipient_restrictions =
>>> warn_if_reject reject_non_fqdn_helo_hostname,
>>> warn_if_reject reject_unknown_helo_hostname,
>>> check_helo_access hash:/etc/postfix/helo_access,
>>> check_sender_access hash:/etc/postfix/sender_access,
>>> reject_rbl_client zen.spamhaus.org,
>>> reject_rhsbl_client dbl.spamhaus.org,
>>> reject_rhsbl_sender dbl.spamhaus.org,
>>> reject_rhsbl_helo dbl.spamhaus.org,
>>> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
>> The last two lines are no-op. If you have anything you want to be
>> subjected to the list.dnswl.org whitelist, put it after the
>> permit_dnswl_client. If not, there is no point in querying it.
> Excellent point. If the next step is going to "permit" anyway, then no use
> in the extra query. I've moved the dnswl.org line up so that it's just
> above the three "local" check_* lines.
should always be at the top of the restrictions list. As you are using
(client|helo|sender|recipient) sections any whitelisting in
smtpd_recipient_restrictions should typically be at the very top.
This shows you are explicitly permitting anything/everything listed in
the dnswl. Are you sure that is what you want? I use...
which does not explicitly permit email marketing providers nor any IP
with trustworthiness score of 1. A score of 1 is equivalent to a
SpamAssassin score of -1, which does not merit a direct shot to the
queue. That would typically require an SA score of -5. I want these
clients to go through all of my other restrictions before allowing their
payload into my queue.
Also worth noting, there are currently only 14 categories (3rd octet of
a reply), so specifying 255 is not necessary, and possibly problematic.
Hypothetically, if dnswl decided one day to create categories 16,
political campaigns, and 17, religious newsletters, you are currently
setup to automatically permit such clients.
Remember, the sole purpose of whitelisting is to bypass all of your
other spam checks and get the mail into your queue unmolested. IMO, not
every IP listed by dnswl is deserving of this honor, not even close to
all of them.
See section "Return codes" at: http://www.dnswl.org/tech