On Wed, Jul 11, 2018 at 10:13:48AM -0400, James B. Byrne wrote:
> > The connecting client did not like one of the certificates in the
> > chain. Perhaps it expected to find a working WebPKI certificate
> > from one of the usual suspects ("browser bundle" public root CAs).
> >
> > You should ask the postmaster of the sending domain? Is the problem
> > ongoing? Or a transient glitch?
>
> It is an ongoing problem with delivery to us of the samba-users
> mailing list digest, of which I am a subscriber.
Any logs they're willing to share would likely be enlightening.
> I am in communication with the person directly responsible for
> implementing DANE at that site. They have just implemented DANE which
> is when the problems first started.
Do you know which MTA they're using?
> As we use 'smtp_tls_security_level = dane'
Your outbound use of DANE when sending email to them has no bearing
on difficulties with their outbound use of DANE when sending email to
you.
> and as they are missing a number of TLSA RRs
What does that mean???
> their problem with us may be an incomplete implementation.
Do they support certificate usage DANE-TA(2)? Perhaps their MTA
only supports DANE-EE(3) and chokes on DANE-TA(2). You could publish
both "3 1 1" and "2 1 1" TLSA records for each MX host, and see if
that resolves the issue.
; TLSA RRs matching the EE key, intermediate CA key and root CA key,
respectively
; Just the EE and intermediate should be enough.
;
_25._tcp.mx32.harte-lyne.ca. IN TLSA 3 1 1
9d111285068fd3e814269b472b75e46a2700f8655989e8c0007e33881ad09733
_25._tcp.mx32.harte-lyne.ca. IN TLSA 2 1 1
9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
_25._tcp.mx32.harte-lyne.ca. IN TLSA 2 1 1
4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4
_25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 3 1 1
478dbe42903020004738f55fc767c6c2ed5cf5b9e7d256b797bd305e84d03a55
_25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 2 1 1
9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
_25._tcp.inet08.hamilton.harte-lyne.ca. IN TLSA 2 1 1
4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4
_25._tcp.mx31.harte-lyne.ca. IN TLSA 3 1 1
3fa3dae08e2fecff0611a75767ee0995a115e308a181ad79a6d163315742b270
_25._tcp.mx31.harte-lyne.ca. IN TLSA 2 1 1
9c19d0fed453f6c49cd9f569af9b5da75ef6d8baabd26308eee88adb2d06a3b5
_25._tcp.mx31.harte-lyne.ca. IN TLSA 2 1 1
4bd5dd98b37237136d1a5b2e45ee8ed1c9f2c2569b6dc94f0951da5af6d090c4
... remaining MX hosts ...
If it does, the Samba list should disable DANE support until their
implementation is less crippled. It needs to either not enforce
DANE for MX hosts with just DANE-TA(2) records, or properly support
DANE-TA(2) records.
--
Viktor.
