On 17.10.23, 18:42 Viktor Dukhovni wrote via Postfix-users:
On Tue, Oct 17, 2023 at 05:47:11PM +0200, Markus Ueberall via Postfix-users
wrote:
For the record: I stumbled across this a couple of days ago when I received
a message on LinkedIn telling me that a number of e-mails sent via
Microsoft's outbound systems had bounced. Given that occasional tests using
MECSA (https://mecsa.jrc.ec.europa.eu/) and DNSSEC and DANE Validation (part
of the Microsoft Remote Connectivity Analyzer,
https://testconnectivity.microsoft.com/tests/O365DaneValidation/input)
looked /good/ (all TLSA entries for ECDSA/RSA certificates used by a certain
domain and its subdomains were always listed under subname "_tcp", with a
couple of CNAME entries "*._tcp", "[*.]_tcp.subdomain", ... pointing to said
subname), it took a while to realize that the above "STARTTLS,QUIT"
behaviour is due to the fact that said outbound systems do not like to come
across non-matching TLSA entries (for other certificates used by the
webserver) anymore.
Are you *SURE* about that? That would be a substantial departure from
the DANE specifications. Extraneous *non-matching* DANE TLSA records
MUST be simply ignored. Any single *matching* TLSA records is
sufficient.
The simple solution was to introduce a new specific subname "_25._tcp"
(which takes precedence over the generic "*._tcp" CNAME) and duplicate/move
the TLSA entries directly related to the certificate used by postfix for the
(sub)domain(s) in question there. In hindsight, this means: Whenever the
MRCA test results (see above) show something marked in red, you should check
whether it's possible to modify your configuration.
If the new TLSA RRset at _25._tcp. prefix is a proper subset of the
original (wildcard or explicit CNAME) shared RRset, and delivery works
for the subset and not the whole set, then there's a genuine problem with
the sender's implementation.
Have you tried using an explicit CNAME instead of a wildcard CNAME, and
still using the shared RRset:
_25._tcp.smtp.acme.example. IN CNAME _tcp.acme.example.
_tcp.acme.example. IN TLSA 3 1 1 ...
_tcp.acme.example. IN TLSA 3 1 1 ...
...
I just tried an explicit "_25._tcp" CNAME as suggested above (using the
shared RRset) /alongside/ the existing "*._tcp" CNAME which I did not
want to remove/replace for one domain ("D1") while keeping my
aforementioned setup for a second domain ("D2"). Then I waited for a
couple of hours to be sure that all outdated cache entries are gone (TTL
for all entries is 3600 seconds), and sent another test e-mail each to
both domains (one immediately after the other). Lo and behold: The one
addressed to D2 got delivered, the one addressed to D1 still causes the
logs to be filled with the same dreaded STARTTLS,QUIT pattern at the
time of writing.
This means that it's either not only the required lookup of a wildcard
CNAME that causes problems or the simple fact that there is a wildcard
CNAME although it should be ignored in this case. Now, I could go on and
introduce a second certificate listed below "_25._tcp" (in order to have
a valid RSA, ECDSA combo) and/or remove all wildcard CNAME entries, but
I already spent a couple of hours with the above and the current setup
for D2 (which I will restore for D1) suits my/our current needs (see
below). Either way, as you mentioned above, the behaviour (1) does *not*
seem to be in line with the DANE specifications and (2) also differs
from what is shown in the Microsoft Remote Connectivity Analyzer test
results.
By the way, thanks a lot for the thorough analysis of the
projektzentrisch.de (test) domain, but although I use that one *here*,
it's not one of the two "Dn" in question (although it has the same basic
setup as described in my previous posting above and utilizes the same
DNS hosting service, the two company domains I actually used for the
comparison/tests above have *way less* DNS entries, certificates).
KR, Markus
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
