On Fri, Apr 02, 2021 at 11:50:04PM +0300, Kristijonas Lukas Bukauskas wrote:
The error indicated is indeed misleading, since the problem appears
to rather be a mismatch between the CNAME-expanded MX hostname and
the "mx: " field of the MTA-STS policy. The certificate matches
either name, so isn't plausibly the problem:
mx.n0.lt. IN CNAME n0.lt.
n0.lt. IN A 188.166.32.32
So that's the failed MX Host Validation, as described in [RFC8461],
section 4.1, that sending MTA seems to claim to be the problem. Correct?
Yes, that's my interpretation of the outcome. Their MTA-STS validator
detected a mismatch between the MTA-STS policy MX hostname and the
CNAME-expanded MX hostname.
You can test this by updating the MTA-STS policy to include both forms
of the MX hostname (and sunsequently change the "id" field of the
MTA-STS TXT record). If the problems go away, that'll confirm the
hypothesis.
If so, what error should the reporter use, as per [RFC8460], in an
aggregated TLS report?
You'd have to look at RFC8460, where I don't actually see a good fit
for this case... :-(
validation-failure?
That seems about the closest.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp