Wietse wrote: >> Given the fact that "encrypt" implies no "dane" this sounds like a bad idea >> for interoperability with dane sites. > No problem. Postfix currently does not try DANE (or STS) with the default TLS > security level "may". Correct. But would you then ignore the suggested _smtps.example.dom setting with "dane", "dane-only", "secure", or "verify" TLS security level? Or what would be the semantics in any of these? Would one assume the same certificate to be used with STARTTLS or implied TLS? >> All in all, imho interoperability with RFC 7672 and RFC 8461 are not >> addressed sufficiently yet. > Can you be more specific? I think it does not interfere with either DANE or > STS. Maybe not conceptually, but implementation wise there could be more clarification. E.g. would one first obtain _smtps.example.doc for the port to use (fallback 25), and then search for TLSA records _<port>._tcp.<mx.example.dom> to check for dane as well? Would one prefer not to optimize the connection in case there are no TLSA records on the specified port but there are any for _25._tcp.<mx.example.dom> ? To some extend the approach probably replaces blocking calls on TCP layer with blocking calls on DNS. If we see DNS also moving to TLS (I am aware of there is right now no standard how to use any of Do* with authoritative DNS servers, but that might change as well), then there is probably little gain unless caching plays a significant role, which likely depends a lot on the load of the mail server.
Joachim _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
