Am Dienstag, den 19.05.2020, 05:06 -0400 schrieb Viktor Dukhovni: > We have no choice, we can't ship code that silently fails to honour > its > configuration. I'm not worried about DANE "working", I'm worried > about > DANE *not* working, and the user being none-the-wiser. > Just my 50cents to make clear, that out of this not only a technical issue stuck:
As the one that triggered the whole thing, I can only agree with the above. I had no chance to see in regular service of postfix why DANE was not working. The logs would not even be suspicious, as you would just guess that no DANE was configured on the partner site. Only the explicit test with a wrongly configured domain - and knowing what should happen - triggered me. But again analysing this needed capturing of the DNS traffic. Nothing regular you do. => As an end user I can only say muslc needs to be very transparent on what features it supports and what not. And should pop the question on missing parts with developers and package maintainers (e.g. build time, dev testing), that actually understand what is happening. This should not be something handled by an end user. @Rich: Seeing the stubs in the muslc code was probably the worst for me in terms of reducing confidence in muslc, hence reverted all my services back to glibc
