Hello Victor, I don´t get why defining a different transport per domain should be easier than defining a tls policy per domain, and my configuration is mostly automated anyway. The automated part becomes a challenge right now with a combination of dead mx plus insecure mx only - and the issue is not about automation but detecting the situation properly and figuring out adequate configuration. If I get your message right, the [] are essential to match nexthop? I double checked and I didn´t have [] in my route so far. Thanks, Joachim
-----Ursprüngliche Nachricht----- Von: owner-postfix-us...@postfix.org <> Im Auftrag von Viktor Dukhovni Gesendet: Friday, 27 May 2022 15:13 An: postfix-users@postfix.org Betreff: Re: transport map with TLS policies? On Fri, May 27, 2022 at 09:21:23AM +0200, Joachim Lindenberg wrote: > I added a transport map (or “route” as mailcow-dockerized calls it) > that points to the alive MX What was the exact form of the transport entry? Presumably, something like: example.com smtp:[mx1.example.com] > plus a TLS policies for the domain and MX that asks for “may”, As documented, the TLS policy table lookup key is the verbatim nexthop (including any optional ":port" suffix) from the transport table, which in the above case would be: [mx1.example.com] may > but flushing the queue I still got “untrusted certificate”. I > temporarily changed my default to may and the mail was delivered. Most likely you did not pay attention to detail or did not read the docuementation, and used some ad hoc list of keys that don't include the correct one. > Are TLS policies applied at all after setting a domain specific > transport? Yes. But in your case (with an overly strict default policy, requiring may exceptions) it would be more appropriate to define a dedicated transport for opportunistic unauthenticated TLS: # Or "dane" instead of "may" if you have a working DNSSEC resolver # on 127.0.0.1 # maytls unix - - n - - smtp -o smtp_tls_security_level=may and then just set the transport to "maytls" instead of "smtp" for the multitude of domains for which you need to make exceptions. > I cannot rule out that the problem is mailcow specific of course. Of course the real problem is an unreasonable default TLS policy, that requires extensive work-arounds. -- Viktor.