Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, viol

On 2021-04-05 03:27, Sam Varshavchik wrote:
> Kristijonas Lukas Bukauskas writes:
>
> > Shouldn't an MTA-STS validator do *exactly* what RFC8461, section 4.1 
> > says: if the *MX record name* matches one or more of the "mx" fields 
> > in the applied policy, a receiving candidate MX host is *valid* 
> > according to an applied MTA-STS Policy?
> That is how I interpret it. It seems to be the most direct, plain,
> interpretation of it. The MX record gives the name of the host, and it
> needs to match the STS policy. The End.
>
> But it seems that others interpret it as that, plus some additional
> requirements.

The MTA's position:

> As my colleagues who investigated this issue communicated, our position 
> is that this is primarily due
> to what we believe to be a non-RFC compliant MX record.
> Regardless of the liberal acceptance of this for regular mail, in this 
> case, our implementation of
> MTA-STS is not as liberal
-- suggests that they are fine with MXs pointing to CNAME for regular 
mail, but not when delivering mail to domains with MTA-STS.
That would be somewhat fine with me as well since it looks like RFC5321 
doesn't clearly say what to do with MX to CNAME -- it points out it lies 
outside the scope of that Standard, it refers to Clarifications on DNS 
Specification suggesting the RFC5321 sees that as a DNS issue, that is, 
DNS -- and not SMTP--  should deal with the issue of canonical names, 
what they are, how CNAME records relate, what names are legal in what 
parts of the DNS, and what is the valid syntax of a DNS name, etc.
I don't see the prohibition of CNAME in MX records as implying that MTA 
should not deliver messages solely based on that. But let's assume, MTAs 
do have a choice here, and so, some MTAs exercise their freedom to 
choose whenever they want, not necessarily always, but in some defined 
circumstances, preferably by documenting them, or -- if they don't have 
time for that -- by showing correct error messages.
They claim their implementation of MTA-STS is not as liberal for MXs 
pointing to CNAME as for regular mail. But it becomes liberal and 
tolerant again as soon as a Receiving MTA updates MTA-STS policy with 
mx: [CNAME-expanded name], in my case mx: n0.lt 
(https://mta-sts.n0.lt/.well-known/mta-sts.txt).
So it looks like their implementation of MTA-STS validator itself is 
confused and undecided whether it wants to be liberal for or 
conservative against MXs pointing to CNAME. Or more realistically -- MX 
Host Validation is not implemented in the way it is explicitly described 
in RFC8461, section 4.1.
Thus, not only are the errors possibly misleading but their position 
could also be potentially viewed as such.
And all the above in the context of not showing the correct error 
messages and a failure to disclose they rolled out the feature of the 
Outgoing MTA-STS Validation. At least not in the Roadmap, the source 
their very own support sees as the ultimate (it says it is still 
development? Sorry, we can't help you with this feature until it is 
rolled out/launched) [the Roadmap was finally updated].
I see that as an extremely ignorant and confusing way of doing things.

--
Regards,
Kristijonas



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp