Wietse Venema wrote:
Dan Langille:
Today I discovered that my mail server is rejecting smtps connections
based upon RBL.
Example:
Sep 28 17:44:40 nyi postfix/smtpd[20073]: NOQUEUE: reject: CONNECT
from pool-151-197-20-211.phil.east.verizon.net[151.197.20.211]: 554
5.7.1 Service unavailable; Client host [151.197.20.211] blocked using
dnsbl.njabl.org; 1045929907; proto=SMTP
I'd rather not restrict smtps connection. Either they authenticate or
they do not. That is enough for me.
Assuming that other sanity checks still apply for smtps clients...
My smtps service is defined through this (slightly altered) master.cf
entry:
10.11.12.13:smtps inet n - n - - smtpd
-o smtpd_sasl_auth_enable=yes
-o
smtpd_recipient_restrictions
=permit_sasl_authenticated,reject_unauth_destination
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_cert_file=/usr/local/etc/postfix-config/CERTS/
nyi.example.org.cert
-o smtpd_tls_key_file=/usr/local/etc/postfix-config/CERTS/
nyi.example.org.nopassword.key
In main.cf, I find these references to njabl.org. I would prefer to
keep these smtp restrictions in place.
maps_rbl_domains = dnsbl.njabl.org
smtpd_client_restrictions = sleep 1, reject_unauth_pipelining, hash:/
usr/local/etc/postfix-config/main/access,
reject_rbl_client dnsbl.njabl.org,
permit_mynetworks
Add to main.cf:
smtps_client_restrictions = sleep 1, reject_unauth_pipelining
hash:/usr/local/etc/postfix-config/main/access
i.e. all but the ``reject_rbl_client dnsbl.njabl.org''.
In master.cf, add to the smtps entry:
-o smtpd_client_restrictions=$smtps_client_restrictions
Ditto for smtpd_helo_restrictions and smtpd_sender_restrictions
or anything that references dnsbl.njabl.org.
This workaround is needed because there can't be spaces in master.cf
-o options. You can use commas instead of spaces, but that just
makes things uglier.
I was thinking about a "generic" way to do this (even if it's a little
ugly):
foobar ...
-o var=${foobar_var?${foobar_var}}${foobar_var:${var}}
so in the OP case, it would be
smtps ...
-o
smtpd_client_restrictions=${smtps_client_restrictions?${smtps_client_restrictions}}${smtps_client_restrictions:${smtpd_client_restrictions}}
it sure looks a little ugly, but it is safe even if the admin removes
smtps_client_restrictions. (a better alternative may be to generate
master.cf based on main.cf declarations?).
and this leads me to a suggestion: support values that use the "service"
name and fallback to the "parent" service. for example, the default for
"submission" would be to use submission_client_restrictions if defined
in main.cf, and fallback to smtpd_client_restrictions otherwise. This
would extend the footransport_mumble that is already supported.
