On 11 Aug 2016, at 15:36, Richard Klingler wrote:
On Thu, 11 Aug 2016 21:33:39 +0200, Benny Pedersen wrote:
On 2016-08-11 21:06, Noel Jones wrote:
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
http://www.postfix.org/postconf.5.html#smtpd_sasl_exceptions_networks
same effect can be made with sasl disabled in main.cf
and just enabled in master.cf for submission
oh well :=)
Jezzz...
Is there a good ebook explaining all the configuration possibilities?
'man 5 postconf' provides basic documentation of all configuration
options. The many readme files (probably installed as plain text and/or
HTML, in directories you can find with "postconf html_directory
readme_directory") provide some deeper and more discursive documentation
of particular feature sets for the version you have installed. The
latest versions of all those can be found via the many links at
http://www.postfix.org/documentation.html.
I still haven't figured the difference between
smtpd_recipient_restrictions and smtpd_sender_restrictions.
The multiple restriction lists ("smtpd_*_restrictions") exist with the
names they carry because historically they were evaluated by default at
different steps in the SMTP session and could cause Postfix smtpd to
reply with a 5xx response code (i.e. rejecting the transaction) at the
point when the particular restriction list was evaluated. Exceptions:
smtpd_etrn_restrictions is special and is only evaluated if ETRN is
attempted, while smtpd_relay_restrictions is only evaluated if sending
to a recipient address amounts to relaying. The modern default behavior
is to evaluate each of the restriction lists at RCPT time in logical
order (client, helo, sender, recipient, and maybe relay) with the
rejection results from earlier lists acting immediately and non-rejected
transactions being passed along to later restriction lists that might
cause a rejection. So in both cases: if smtpd_sender_restrictions
rejects a session it is rejected and never gets a shot at
smtpd_recipient_restrictions, but if a session gets through
smtpd_sender_restrictions it must still clear
smtpd_recipient_restrictions for each recipient (i.e. each RCPT
command.)
The reason the default restriction list evaluation time changed is that
many mail senders, both legitimate and otherwise, react inappropriately
to rejection before RCPT time. The problem this created is that some
miscreants misbehave early, sometimes without even sending HELO/EHLO,
but Postfix smtpd no longer evaluates smtpd_client_restrictions at
connect time. The solution for that is the postscreen facility, which
handles the initial SMTP connection and does very limited evaluation of
the client and its behavior before either handling of the connection to
a smtpd process or handling the connection itself in a sham SMTP
implementation that can't accept mail. If you have a modern (>2.8)
version of Postfix and have postscreen enabled, you can use the
postscreen_access_list feature which uses a cidr table to blacklist IPs
early and with minimal resource cost. Another advantage of using
postscreen is that it logs and blocks "fast talker" clients that so it
is easy and safe to set up fail2ban or a simpler targeted log snooper to
drop those into a local packet filter (e.g. iptables, ipfw, etc.) since
they have a tendency to come back over and over.
For name-based rejection (verified rDNS or HELO/EHLO) that you don't
want/need exempted by anything else, use check_client_access in
smtpd_client_restrictions and check_helo_access in
smtpd_helo_restrictions (and/or their arcane variants, see the
postconf(5) man page)
