On 2022-04-22 at 17:30 -0500, Faisal Misle via mailop wrote:
> Note the trailing dot on the second policy. Is that a valid MX for the
> policies of the file? I could not find anything about it on RFC 8461 and
> most validators were flagging it as an invalid MX.
>
> Looking forward to hearing your thoughts!
>
> -Faisal
That trailing . (the root zone) appears on dns and in the ouput of e.g.
host(1), but I don't think it is valid in the context of a STS policy
file (even though I often leave that triling . when writing local STS
overrides)
RFC 8461 don't mention trailing dots in the text, nor they appear on
the samples. This is a good indication it isn't expected.
And for the formal rules, rfc8461 defers to rfc6125, which basically
say "the text must be the same case-insensitive"
> If the DNS domain name portion of a reference identifier is a
>"traditional domain name", then matching of the reference identifier
>against the presented identifier is performed by comparing the set of
>domain name labels using a case-insensitive ASCII comparison, as
>clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
>to "www.example.com" for comparison purposes). Each label MUST match
>in order for the names to be considered to match
(*) skipping over the mentions of wildcards for clarity
Thus my conclusion is that the mx entries MUST NOT have such trailing
dots.
Furthermore, the fact that validators reject them is a sign that
implementations are likely to reject them as well, which would lead to
email not being delivered (since no mx would match)
Nonetheless, per Postel's Law, a client MAY wish to ignore such
trailing dots and I think it would be fine.
Best regards
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
