On Sun, Feb 01, 2026 at 12:55:41PM +1100, Viktor Dukhovni wrote: > On Sat, Jan 31, 2026 at 07:11:47PM -0500, Wietse Venema via Postfix-users > wrote: > > > dane:may (number, opportunistic dane, fallback to opportunistic TLS) > > FWIW, this example is not going to be very common, because DANE is downgrade > resistant. When the configured security level is "dane", but the server > has no TLSA records, the logged policy is simply "may": > > Feb 01 11:50:57 amnesiac postfix/smtp[96562]: 220A09355B9: > to=<[email protected]>, relay=spike.porcupine.org[168.100.3.2]:25, > delay=5.4, delays=0.12/0.02/3.7/1.5, tls=may, dsn=2.0.0, status=sent > (250 2.0.0 Ok: queued as 4f3WQ90wZ6zJrNm)
Off-list discussion with Wietse confirms that "dane:may" is not expected to occur, absence of any TLSA records is logged simply as "tls=may". If a reasonable user would expect logging of "dane:may" in this case, we'd need to keep track of the policy level that was in effect just prior to TLSA lookup, along with the resulting effective policy after the lookup, and incorporate that into the logging. > Even with "unusable" TLSA records that result an effective policy of > "encrypt": > > > https://github.com/vdukhovni/postfix/blob/11d1e54392f7411e7bc7990115fb5a62aff204f6/postfix/src/smtp/smtp_tls_policy.c?ts=8#L1123-L1124 > > if (tls_dane_unusable(dane)) { > dane_incompat(tls, iter, DANE_CANTAUTH, "TLSA records unusable"); > > > https://github.com/vdukhovni/postfix/blob/11d1e54392f7411e7bc7990115fb5a62aff204f6/postfix/src/smtp/smtp_tls_policy.c?ts=8#L1016-L1017 > > if (tls->level == TLS_LEV_DANE) { > tls->level = (errtype == DANE_CANTAUTH) ? TLS_LEV_ENCRYPT : TLS_LEV_MAY; > > I still see "may": That was an error on my part, I have sender-dependent-default transport that is in place for sending notifications to domains with broken TLSA records, and I used the sender address in question for the probe. :-( When I avoid the PBKAC mistake the logging matches expectations: Feb 02 12:23:09 amnesiac postfix/smtp[123300]: D1D859355B9: to=<...>, relay=youractive.nl[136.144.163.208]:25, delay=5, delays=0.09/0.03/4.5/0.32, tls=encrypt, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) Keeping track of the policy level prior to TLSA lookup would also make it possible to report that "encrypt" was a result of DANE TLSA records (with only unusable TLSA records), and might then log: tls=dane:encrypt with documentation to explain that this is to be expected when the TLSA RRset consists entirely of "unusable" records. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
