Hello,
DANE TLSA records are strictly enforced when "well-formed", where
well-formed also requires a plausible TLSA "associated data" field
(expected length for SHA2-256 and SHA2-512 digests and valid DER
encoding of certs or keys for matching type Full(0)).
That's what I did expect. Starting with the fact that what I expect is
also
what should haven happened I reviewed the whole system. The reason
somewhere
lies in DNSSEC. The mail sending server is also the domain server for
the
internal target domain. When I send mail to the target from somehwere
else DANE works
(with updated TLSA). From the server which has the local name server the
answer has the
aa flag, but not the ad flag. I have to investigate what's broken here.
Either a configuration change or an update broke something. It was
hidden as no
negative side effects were visible (I hate it when stuff fails and it's
invisible,
except in some logs).
So two tasks for me:
a) fix the internal DNSSEC issue
b) monitor internal DANE as well
Lesson learned: Not only external stuff must be monitored thoroughly.
;-)
P.S. For https://www.postfix.org/TLS_README.html#client_tls_dane maybe
the third paragraph could have added: "If there are usable, but
mismatching TLSA entries, no mail is sent."?
For Freedom In Peace
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
