On Fri, Oct 02, 2026 at 07:10:43AM +0200, Hans-Martin Mosner via mailop wrote:
> I believe there are some folks from Deutsche Telekom on the list. > Please have a look into this: > > We had some mails to addresses @magenta.de which were not delivered due to > "Server certificate not verified" errors. openssl s_client had no trouble > connecting to the MX, so I was stumped. A colleague found the solution: DANE > config for magenta.de is invalid. > > https://stats.dnssec-tools.org/explore/?magenta.de claims that there > are no matching TLSA records for magenta.de. Correct, though "claims" can safely (more accurately) be replaced with "reports", the caveats being: 1. Data freshness: The results may be up to ~28 hours old, given that checks run once a day, and each run takes around 4 hours. Results for a handful of sites that have opted out of survey scans could be arbitrarily stale, recording the status when last scanned, you're very unlikely to run into one of these. 2. Partial coverage: Only some of the certificates of a server may be tested in a given run, some of those not tested may have no matching TLSA records, but the survey may not detect this, so some problems may not be reported. No false reports of problems. > I'd love to see more explicit errors in the postfix log for this, even > with increased verbosity I only see There's not much to report: IN TLSA 3 1 1 5d4b23c321e1190498ff2529a20ad989ddb6e5b02fda8cc684f6937a85b15c96 while the actual SPKI digest is: baf764214df6fe7496351d680635163a3e947ff65195d2a2f4c4d77634b9db41 For a certificate issued on 2026/9/22. > > [...] > > Oct 2 01:02:52 localhost postfix/smtp[2901865]: Trusted TLS connection > > established to mx02.magenta.de[194.25.134.9]:25: TLSv1.3 with cipher > > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) > > server-signature RSA-PSS (4096 bits) server-digest SHA256 Your log level is too high, levels higher than 1 are not intended for endusers. > > Oct 2 01:02:52 localhost postfix/smtp[2901865]: BD92A1207A1: > > to=<*@magenta.de>, relay=mx02.magenta.de[194.25.134.9]:25, delay=32456, > > delays=32455/0.04/0.27/0, dsn=4.7.5, status=deferred (Server certificate > > not verified) > > which does not really indicate to me that there is a DANE problem. Newer versions of Postfix log this is more detail, via the "tls=" property of the delivery log entry. http://www.postfix.org/postconf.5.html#smtp_log_tls_feature_status > Apparently if you search for postfix and "Server certificate not > verified" you will get pointers to DANE issues, but yesterday I was a > little too tired to do that search (and I steadfastly refuse to use > LLMs for various reasons). Well, by default Postfix does not verify certificates. That only happens when you explicitly set the security level higher than "encrypt", or when you enable dynamic discovery of support for DANE or MTA-STS. So any issues with cert verification would have to be a result of that. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
