On Fri, Mar 15, 2024 at 10:13:01PM +0100, Dirk Stöcker via Postfix-users wrote:
> I recently did a misconfiguration of an internal mail server for a test > system and as a result broke the TLSA record. Exactly *how* was the TLSA record broken? Logs? And were alternative MX hosts available for the destination domain? ... Without technical details, your anecdotal experience can at best just elicit sympathy. > Postfix still delivered mail to the system now with Trusted instead of > Verified (BTW I find these two outputs texts misleading, each time I > check the logs I look for a reference server to know which of the two > is which, couldn't you find something more explicit?). That's not generally expected, because the default is not trust any WebPKI CAs, but perhaps you explicitly specified a non-empty smtp_tls_CAfile or smtp_tls_CApath? > That was a really unexpected behavior for me so I looked in the > documentation for "smtp_tls_security_level = dane" in > https://www.postfix.org/TLS_README.html#client_tls_dane and really there it > says "If TLSA records are published for a given remote SMTP server (implying > TLS support), but are all "unusable" due to unsupported parameters or > malformed data, the Postfix SMTP client will use mandatory unauthenticated > TLS." Well, were the TLSA records unusable (bad usage, selector or matching type parameters or bad data), or were they usable, but simply did not match the presented certificate chain? The former will lead to "encrypt", the latter will skip the MX host and either defer delivery or use another MX host. > Now I understand the rationale behind this. Still unclear what "this" is. Unusable TLSA records are treated as a signal to "encrypt", but do not signal an (impossible) authentication requirement. > You want to prevent mail breaking because of too many bad > configurations, but in this case I think a more strict DANE setting is > missing: If you want DANE for a particular destination, you can use "dane-only". If you want opportunistic DANE TLS (RFC7672), for random destinations with no *prior* expectation of security, then treating unusable parameters as "encrypt" makes sense. > * I agree that at the moment it can be a good idea not to enforce DANE for > "unsupported parameters" or "malformed data" (even though I think there > should be a way to make this an error). We'll agree to disagree about that. > * But I would expect that DANE is enforced when data is well-formed and with > supported parameters but simply wrong, like in my case old. That's actually the case. Well-formed, but "simply wrong" (not matching the cert chain) TLSA records are strictly enforced. Otherwise, what'd be the point of DANE TLSA records? > Would it be possible to add a "dane-strict" setting which enforces > correct DANE always, when there are TLSA records or at least > acceptable but not matching TLSA records (I assume changing "dane" > option is out of the question)? 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)). -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
