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.
