From: /dev/rob0 (rob0gmx.co.uk)
Date: Wed May 01 2013 - 07:14:37 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 =
> 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:

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]