On Sat, Aug 27, 2022 at 02:32:30PM +0200, Günther J. Niederwimmer wrote:
> Also the SASL problem is getting worse, the whole thing worked before I
> upgraded to 3.7.0 and is getting worse 3.7.1 =>. I hope I give all relevant
> configs logs?
I expect you upgraded more than just Postfix, and likely one of those
upgrades is the real problem.
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane
Congratulations! To ensure actual security against active attacks
from DANE, I hope your /etc/resolv.conf or equivalent points only
to a loopback validating resolver.
> smtp_tls_CAfile = /etc/pki/tls/cert.pem
> smtp_tls_cert_file = /etc/letsencrypt/live/mx02.4gjn.com/fullchain.pem
> smtp_tls_eccert_file = /etc/letsencrypt/live/mx02.4gjn.com/fullchain-ecdsa.pem
> smtp_tls_eckey_file = /etc/pki/tls/private/4gjn.com_ec.key
> smtp_tls_key_file = /etc/pki/tls/private/4gjn.com.key
You probably don't need any of these. Are you actually relying on TLS
client certificates to permit delivery to any remote SMTP servers?
> smtp_tls_loglevel = 2
This is too verbose, 1 is sufficient and better.
> smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
FWIW, a very small number of DANE-enabled domains are still offering
only TLS 1.0. You probably don't send them any email, but just in case
be aware that in principle you can't if you wanted to. There is no
meaningful risk in allowing TLS 1.0 outbound in SMTP, and you could just
leave it enabled. That said, probably TLS 1.2 and up are will work well
enough for your needs.
> smtpd_sasl_auth_enable = yes
For now, consider setting this to "no", and adding:
-o smtpd_sasl_auth_enable=yes
to just the submission services in master.cf. This will
allow you to receive inbound email while you're debugging
the SASL issue. Indeed your inbound mail is mostly down:
https://stats.dnssec-tools.org/explore/?4gjn.com
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
Congratulations on configurating Dovecot SASL, it tends to
be simpler to configure and use.
* That said, is there actually a "/var/spool/postfix/private/auth"
unix-domain socket?
* Does "netstat" or "lsof" report any processes listening on that
socket?
* Is Dovecot actually up and running on your system? Is it
configured to create an auth socket in /var/spool/postfix/private?
* Are the socket permissions correct?
> smtpd_tls_cert_file = /etc/letsencrypt/live/mx02.4gjn.com/fullchain.pem
> smtpd_tls_dh1024_param_file = /etc/pki/tls/certs/dh_4096.pem
With Postfix 3.7, you're better off with either empty, or equivalently
the implied "auto", which uses "standard" negotiated DHE parameters.
> smtpd_tls_dh512_param_file = /etc/pki/tls/certs/dh_2048.pem
And this setting is no longer needed or used.
> smtpd_tls_eccert_file =
> /etc/letsencrypt/live/mx02.4gjn.com/fullchain-ecdsa.pem
> smtpd_tls_eckey_file = /etc/pki/tls/private/4gjn.com_ec.key
> smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL, DES-CBC3-SHA,
> ECDHE-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, IDEA-CBC-SHA
Simpler:
smtpd_tls_exclude_ciphers = RC4, 3DES, IDEA
> smtpd_tls_session_cache_database = lmdb:${data_directory}/smtpd_scache
This is best left empty, let the clients use session tickets.
> smtps_smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
Presumably a master.cf override variable.
> What I find in the logs is hundreds of times, e.g.
> Aug 27 14:18:27 mx02 postfix/smtpd[1417085]: connect from
> camomile.cloud9.net[168.100.1.3]
> Aug 27 14:18:28 mx02 postfix/smtpd[1417085]: Anonymous TLS connection
> established from camomile.cloud9.net[168.100.1.3]: TLSv1.2 with cipher ECDHE-
> ECDSA-AES256-GCM-SHA384 (256/256 bits)
> Aug 27 14:18:38 mx02 postfix/smtpd[1417085]: fatal: no SASL authentication
> mechanisms
> Aug 27 14:18:39 mx02 postfix/master[213623]: warning: process
> /usr/libexec/postfix/smtpd pid 1417085 exit status 1
> Aug 27 14:18:39 mx02 postfix/master[213623]: warning:
> /usr/libexec/postfix/smtpd: bad command startup -- throttling
Your Dovecot SASL subsystem is broken. See above.
--
Viktor.
