On Sat, Oct 22, 2016 at 09:33:35AM +0200, Geert Stappers wrote:
> On Sat, Oct 22, 2016 at 03:18:36PM +0900, Tomoyuki Murakami wrote:
> > On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis wrote:
> > > smtpd_relay_restrictions =
This is a strange choice for spam controls. It's intended (as a new
feature of Postfix 2.10) only to control permission for relaying.
Typically all the spam controls should go in recipient restrictions.
I don't suppose there is anything *wrong* with doing it this way,
except that most of this has nothing to do with relaying, and it is
confusing to someone who comes after you and has to understand the
configuration you made.
> > > permit_mynetworks,
> > > permit_sasl_authenticated,
On port 25 one should not be allowing relay, so these don't belong.
> > > check_sender_access hash:/etc/postfix/whitelist,
> > > reject_invalid_hostname,
> > > reject_non_fqdn_sender,
> > > reject_non_fqdn_recipient,
> > > reject_unknown_sender_domain,
> > > reject_unknown_recipient_domain,
> > > reject_unauth_pipelining,
> > > reject_unauth_destination,
This is the only line that belongs here for port 25. It should be
overridden for the submission service:
[master.cf]
submission [ ... ] smtpd
-o smtpd_relay_restrictions=$mua_relay_restrictions
[ ... ]
[main.cf]
mua_relay_restrictions = permit_sasl_authenticated,
reject_unauth_destination
(permit_mynetworks deliberately omitted, because it's a better
practice to always require AUTH from relaying clients, but those who
still want IP-address-based relay permission can use it.)
> > > check_policy_service unix:private/shadelist,
> > > reject_rbl_client bl.spamcop.net,
This is an odd choice which can lead to a lot of woe. Spamcop is an
automated list which often is too aggressive in blocking.
> > > reject_rbl_client zen.spamhaus.org,
> > > reject_rbl_client ix.dnsbl.manitu.net,
I'm not personally familiar with this list so I wouldn't use it here.
I am familiar with and DO recommend using Zen, however.
> > > permit
> >
> > permit after all ?
>
> Hummm. In networking firewall rules it common[1] to have
> a couple of deny rules with an allow rule closing such groups.
>
>
> Rereading http://www.postfix.org/SMTPD_ACCESS_README.html did
> not show any "closing permit".
Look again, the paragraph after the examples:
http://www.postfix.org/SMTPD_ACCESS_README.html#lists
"The end of the list is equivalent to a PERMIT result."
> Should "closing 'permit' lines" be removed from live
> configurations?
Of course not. That is how it works. If not specified as the OP did
it, the ending value of any restriction stage is "permit". If not,
mail would not be accepted at all.
> [1] Common sense is the least common sense of all :-(
In this case common sense is to keep rereading the aforementioned
README until you get it. :)
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
