Subject: Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2021 12:02:07 -0400

>>> {"organization-name":"Microsoft 
>>> Corporation","date-range":{"start-datetime":"2021-03-30T00:00:00Z","end-datetime":"2021-03-30T23:59:59Z"},"contact-info":"[email-masked]","report-id":"132616914860181612+n0.lt","policies":[{"policy":{"policy-type":"sts","policy-string":["version: 
>>> STSv1","mode: enforce","mx: mx.n0.lt","max_age: 
>>> 84600"],"policy-domain":"n0.lt"},"summary":{"total-successful-session-count":0,"total-failure-session-count":492},"failure-details":[{"result-type":"certificate-host-mismatch","failed-session-count":492}]}]}
>>> Do they complain about the certificate which includes both n0.lt and 
>>> *.n0.lt anyways?
>> 
>> Even without the CNAME error, why would it do that?  The cert matches
>> the name of the MX.
>
> So certificate-host-mismatch here should be understood that EITHER §4.1 [1] 
> (MX Host Validation) OR §4.2 [2] (Recipient MTA Certificate Validation) 
> failed and not that, according to the report, the certificate hostname 
> mismatched? Or what exactly?

It's probably just giving you the wrong error message.

Here's a radical idea: fix your MX entry and see if the errors go away.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Thu, 01 Apr 2021 20:23:13 +0300

On 2021-04-01 19:02, John R Levine wrote:

> So certificate-host-mismatch here should be understood that EITHER §4.1 
> [1] (MX Host Validation) OR §4.2 [2] (Recipient MTA Certificate 
> Validation) failed and not that, according to the report, the 
> certificate hostname mismatched? Or what exactly?

The errors do go away. But I'm not trying to fix the individual issue 
here, rather to better understand what exactly they're are complaining 
about, and if their errors and logic are compliant with the policy 
validation and application, set in RFC 8461.

They started off by pointing at their roadmap which still up until now 
says that the feature is in development, rather than rolled out, or 
launched; then seemingly tried to confuse me with:

> From reviewing your issue, we can see that your externally hosted 
> domain n0.lt is set to only accept emails using secure and encrypted 
> connections. When sending emails, by default they are unencrypted. By 
> default Office 365 sends emails unencrypted which is why your n0.lt 
> server is rejecting them.
> 
> To resolve this you need to set up a send connector in Office 365 to 
> send encrypted and TLS secured emails to n0.lt. Depending on the 
> configuration of your n0.lt mail server, you may also need a receive 
> connector to match the receiving SMTP FQDN madin.ga* with a TLS 
> certificate, however, we cannot confirm this as your mail server is not 
> hosted by Microsoft.

* - the domain I have with them for testing purposes.

Viktor Dukhovi and Sam Varshavchik have already provided their detailed 
viewpoints which will help me a lot to continue working with the support 
of this sending MTA.

Thanks!

--

Best wishes,
Kristijonas

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 01 Apr 2021 18:37:46 -0400

Kristijonas Lukas Bukauskas writes:

> viewpoints which will help me a lot to continue working with the support of  
> this sending MTA. 

My viewpoints are somewhat dated. The persona-non-grata status of MXs  
pointing to CNAMEs – that verbiage appears to be new to the current SMTP  
standard, I checked and did not find any equivalent language in the prior  
one; so my implementation reflected that.

Be it as it may. I do not see any technical issues with MXs pointing to  
CNAMEs, except that an additional lookup is required to resolve the CNAME in  
most cases. If this is not within the scope of the current standard, then I  
would not set up my domains like that.

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2021 20:24:15 -0400

>one; so my implementation reflected that.

The author of 5321 is on this list so perhaps he recalls what the motivation
for the change was.  I'm sure it wasn't accidental.

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Apr 2021 11:00:13 -0400

--On Thursday, 01 April, 2021 20:24 -0400 John Levine
<[email-masked]> wrote:

>> My viewpoints are somewhat dated. The persona-non-grata
>> status of MXs   pointing to CNAMEs – that verbiage appears
>> to be new to the current SMTP   standard, I checked and did
>> not find any equivalent language in the prior   one; so my
>> implementation reflected that.
> 
> The author of 5321 is on this list so perhaps he recalls what
> the motivation for the change was.  I'm sure it wasn't
> accidental.

No, and my apologies if parts of what follow sounds like a rant.

Actually, the rule is in RFC 1123 Section 5.2.2 with the text
in5321 as just a clarification.  My memory of that part of the
discussion in the late 1980s is very vague, but I think that it
includes some concern about the combination of performance, what
action should be taken on a CNAME loop if one were detected, and
the whole situation being error-prone.  That combines with the
obvious: because users are not expected to see those target
names, there is no good reason to have them be anything but
final (1123 says "canonical") names.  Approximately the same
reasoning applies to the DATA of one MX record, when resolved,
pointing to another MX record with the addition of questions of
what would then be two sets of priorities would mean in that
case.  

Once upon a time, we used to try to design protocols so that the
functionality that was needed was available but that the number
of different ways to do something was minimized, more or less on
the assumption that two or three ways to do the same thing
created opportunities for errors, vulnerabilities, and/or the
need to make the specifications to make things more complicated
by considering the interactions.  So, given that there is no
real reason why an MX RR should point to either another MX RR, a
CNAME RR, or, for that matter, TXT or anything else, why allow
it.

Noting my recent comments about how 2821 (and hence 5321 and the
evolving 5321bis) were assembled, 5321 is inconsistent about
where it says "don't do that", "if you do that, bad things may
happen and what they are and what you should do about them lies
outside the specification", and "if you decide to violate the
rule in Section X.Y.Z, then you should...". In general, there
are reasons for each case, but there are probably exceptions.
But the bottom line here, as John and others have suggested, is
that the right answer to the question in the subject line is
that an SMTP sender encountering an MX record whose DATA points
to a CNAME (or anything other than an address record) should
just treat the message as undeliverable, a popular
implementation or two notwithstanding.  And worrying about
validating the clearly invalid just does not make a lot of sense.

   john

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 04 Apr 2021 11:58:22 -0400

> action should be taken on a CNAME loop if one were detected, and

CNAME loops can happen on any lookup: MX, A, AAAA, or any other RR. When  
searching various DNS-related documentation I saw no exceptions for MX RRs,  
that distinguish their processing. I can't find anything explicitly  
mentioned in RFC 1035 regarding CNAME loops that occur in the process of  
doing MX lookups. What should happen is the same thing what should happen  
when getting a CNAME loop for any other query. Even PTR. In fact, at least  
at one point, CNAME aliases for PTR records were quite popular, in certain  
use cases.

RFC 1035 defines CNAMEs as follows:

# CNAME RRs cause no additional section processing, but name servers may
# choose to restart the query at the canonical name in certain cases.  See
# the description of name server logic in [RFC-1034] for details.

RFC 1035 then states:

#  If recursive service is requested and available, the recursive response
#  to a query will be one of the following:
#
#   - The answer to the query, possibly preface by one or more CNAME
#     RRs that specify aliases encountered on the way to an answer.

This is not qualified in any further way. If a recursive query for an MX  
record is received by a DNS server, it will resolve any CNAME alias. The  
next paragraph further cements this point. Section 4.3.2 then provides more  
color:

#         a. If the whole of QNAME is matched, we have found the
#            node.
#
#            If the data at the node is a CNAME, and QTYPE doesn't
#            match CNAME, copy the CNAME RR into the answer section
#            of the response, change QNAME to the canonical name in
#            the CNAME RR, and go back to step 1.
 
So, if an SMTP server uses a generic DNS resolver to look up MX records, an  
MX that's pointing to a CNAME will resolve just fine.

Following the cite to RFC 1034, over there we find the following:

# CNAME RRs cause special action in DNS software.  When a name server
# fails to find a desired RR in the resource set associated with the
# domain name, it checks to see if the resource set consists of a CNAME
# record with a matching class.  If so, the name server includes the CNAME
# record in the response and restarts the query at the domain name
# specified in the data field of the CNAME record.  The one exception to
# this rule is that queries which match the CNAME type are not restarted.

Finally:

#                                 Of course, by the robustness
# principle, domain software should not fail when presented with CNAME
# chains or loops; CNAME chains should be followed and CNAME loops
# signalled as an error.

It is clear that a generic DNS resolver will handle CNAMEs in the context of  
MX RRs no differently than any other RR. Earlier, I wrote:

> So, if an SMTP server uses a generic DNS resolver to look up MX records, an  
> MX that's pointing to a CNAME will resolve just fine.

Now, whether the SMTP server will accept this result is, of course, a  
different story. Prior to the current standard this wasn't clearly defined,  
and now it is prohibited. However, this distills this issue to the following;

The specification's audience is mostly SMTP implementations. But the onus on  
complying to this requirement is on the owners and operators who configure  
their domains. And in the context of setting up and installing their DNS  
records, there's nothing wrong with installing a CNAME for an MX target.  
They'll run

dig example.com mx

They'll get an MX record for mail.example.com, then

dig mail.example.com a

they'll get a CNAME and and A record, and for all intents and purposes, DNS  
is set up correctly.

Even better is that older DNS servers will helpfully include CNAME and A  
records automatically in the "additional data" part of the DNS response to  
an MX query. No additional DNS queries will be needed, to locate the actual  
MX, if the implementation is smart enough to check that part of the DNS  
response. I don't see this happening any more, but this used to happen more  
often than not.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 4 Apr 2021 12:40:27 -0400

> On Apr 4, 2021, at 11:58 AM, Sam Varshavchik <[email-masked]> wrote:
> 

This is it in a nutshell.  MTAs in fact (continue to) support CNAME-valued
MX exchange hosts, and users don't expect to run into any issues.  So the
prohibition in 5321 is largely unexpected to them.

The fact that the overwhelming majority of domains have MX hosts that are
not CNAMEs is partly a result of concentration: a small number of MX hosts
serve a large number of domains, and partly the fact that MX indirection
entirely obviates the need for separate CNAME indirection:

 example.org. IN MX 0 mx.example.org.
 mx.example.org. IN CNAME smtp.provider.net.

    Why on earth not just:

 example.org. IN MX 0 smtp.provider.net.

And yet this through ignorance, fashion or oddity of tooling this is
marginally popular.  Complexity only sets in when implementations need
to choose reference identifiers for TLS, and perhaps don't think it
through carefully enough.  So in combination with MTA-STS and DANE,
CNAME handling gets a bit more error-prone.

So I think that users SHOULD avoid the CNAMEs, and yet MTAs should
do their best to work anyway.

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 4 Apr 2021 13:00:43 -0400

> No, and my apologies if parts of what follow sounds like a rant.

Thanks, I'd forgotten about the RFC 1123 language.

> created opportunities for errors, ...

Yes indeed.  In retrospect, CNAME was a mistake.  If you look at RFC 
1034, you can see that the motivation for CNAME was to provide short 
local versions of names and temporary forwarding when a host name changes. 
But now it's mostly used to transfer the management of a name to someone 
else.

The normal way to do that is with a zone cut, and I think that most 
applications of CNAME would better be done with NS.  There are two 
differences: a zone cut needs to know what name is pointing at it and a 
zone cut covers all names below the redirected one while a CNAME doesn't, 
but in my experience, the situations where that matters generally have 
other problems.

Regards,

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Sun, 04 Apr 2021 21:07:28 +0300

> validating the clearly invalid just does not make a lot of sense.

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? And thus, MX Host Validation passes, even 
if the MX record itself is otherwise invalid. Match the MX record name 
against "mx" fields in the applied policy. That's it. Conditions to pass 
validation here are exhaustive, not inclusive, even if a Sending MTA 
honoring MTA-STS might not like that, and even if it wants to be less 
liberal or whatever. Exhaustive conditions were met -- validation 
passed.

--
Regards,
Kristijonas

---

From: "John R Levine" <[email-masked]>
Date: 4 Apr 2021 14:17:31 -0400

On Sun, 4 Apr 2021, Kristijonas Lukas Bukauskas wrote:
> Shouldn't an MTA-STS validator do *exactly* what RFC8461, section 4.1 says:

That's not how standards work.  If you follow the standard, you should be 
able to interoperate with other people that follow it.  If you don't, the 
results are unpredictable.  We don't try to anticipate every possible 
mistake both because it is a waste of time and because it is impossible. 
I suppose it would be nice if Microsoft sent a better error message but 
that's not a bug I can get very excited about.

You know that pointing your MX at a CNAME is a mistake, so it'll fail at 
random.  It's a somewhat common mistake, but it's still a mistake.  If it 
were me, I would fix it and move on.

Regards,

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Apr 2021 22:30:51 +0200

What John Levine says.

You can say things like "those people should be liberal in what they accept 
and overlook my minor error" but sometimes you run into people who aren't 
conservative, just like you aren't conservative if you violate a rule 
knowingly. And sometimes you run into people who haven't tested their 
handling of the error you commit, and untested code breaks, that's a <beep> 
<beep> axiom.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Apr 2021 16:46:30 -0400

--On Sunday, 04 April, 2021 13:00 -0400 John R Levine
<[email-masked]> wrote:

>> Once upon a time, we used to try to design protocols so that
>> the functionality that was needed was available but that the
>> number of different ways to do something was minimized, more
>> or less on the assumption that two or three ways to do the
>> same thing created opportunities for errors, ...
> 
> Yes indeed.  In retrospect, CNAME was a mistake.  If you look
> at RFC 1034, you can see that the motivation for CNAME was to
> provide short local versions of names and temporary forwarding
> when a host name changes. But now it's mostly used to transfer
> the management of a name to someone else.
> 
> The normal way to do that is with a zone cut, and I think that
> most applications of CNAME would better be done with NS.
> There are two differences: a zone cut needs to know what name
> is pointing at it and a zone cut covers all names below the
> redirected one while a CNAME doesn't, but in my experience,
> the situations where that matters generally have other
> problems.

I would say (and have said) much the same thing, even more
strongly, about DNAME and its purpose.  The original
specification for DNAME says that too.  But the big design
error, in retrospect, was to confuse the function of an
alternate name for a node (accomplished in the host table with a
simple alias) with a pointer or link to somewhere or something
else, most likely in a different zone.  The problem has become
especially clear in recent years every time someone tries to use
CNAME (or DNAME) to try to support an alternate spelling or
different-script form for a given node name: the bindings are
not strong enough, there is no way to ask the DNS what all of
the names are that refer to a given node, etc.

And, if I didn't say more or less that in RFC 8324, I should
have.

    john

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Sun, 04 Apr 2021 23:47:51 +0300

On 2021-04-04 21:17, John R Levine wrote:

>> says:
> That's not how standards work.  If you follow the standard, you should
> be able to interoperate with other people that follow it.  If you
> don't, the results are unpredictable.  We don't try to anticipate
> every possible mistake both because it is a waste of time and because
> it is impossible. I suppose it would be nice if Microsoft sent a
> better error message but that's not a bug I can get very excited
> about.
> 
> You know that pointing your MX at a CNAME is a mistake, so it'll fail
> at random.  It's a somewhat common mistake, but it's still a mistake.
> If it were me, I would fix it and move on.

I would disagree. Standards are and/or supposed to be well defined. Any 
implicit or implied reasoning based on emotions or vendor's whatever 
value system (being less or more liberal) while interpreting them should 
be avoided unless that is inevitably necessary. That's what standards 
are for. MUST is normally added, when an absolute requirement, sometimes 
with a reference to another RFC if needed. For example:

> Policy bodies are, as described above, retrieved by Sending MTAs via
> HTTPS [RFC2818].  During the TLS handshake initiated to fetch a new
> or updated policy from the Policy Host, the Policy Host HTTPS server
> MUST present an X.509 certificate that is valid for the "mta-sts"
> DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below,
> chain to a root CA that is trusted by the Sending MTA, and be non-
> expired.

[RFC 8461, Section 3.3]

One could argue that it would be reasonable to imply that the chain to a 
Root CA has to be trusted by the Sending MTA and be non-expired. In the 
world of standards, you can't do that. Unless there is a MUST. If it's 
not explicitly defined as a requirement for some specific outcome, it 
isn't one for that outcome.

And that applies to you, even if you are as huge as Microsoft.

--

Regards,
Kristijonas

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Apr 2021 16:53:42 -0400

--On Sunday, 04 April, 2021 14:17 -0400 John R Levine
<[email-masked]> wrote:

> That's not how standards work.  If you follow the standard,
> you should be able to interoperate with other people that
> follow it.  If you don't, the results are unpredictable.  We
> don't try to anticipate every possible mistake both because it
> is a waste of time and because it is impossible. I suppose it
> would be nice if Microsoft sent a better error message but
> You know that pointing your MX at a CNAME is a mistake, so
> it'll fail at random.  It's a somewhat common mistake, but
> it's still a mistake.  If it were me, I would fix it and move
> on.

Agreed and let me make two small additions:

(1) I agree enthusiastically with your earlier "doctor, it hurts
when I do this" comment and the response.  It is clear, as you
suggest above, that having an MX record pointing to a name
associated with a CNAME (or, for that matter, anything but an
address record) is going to fail with some systems.  How many,
which ones, and how the failures occur is unimportant (which is
almost exactly with 5321 says in standard-ese). 

(2) With regard to both the above and the note Kristijonas
posted a few minutes ago, if RFC 8461 says anything that appears
to contradict the above, it is a bug and those who care should
be generating errata or, better yet, working on an update.  8461
can --at least as long as it is consistent with other deployed
specs-- say anything it likes about certificates, where they
come from, and how they are validated.  But, it is can be read
as encouraging violation of 5321 in a specification that is
clearly about SMTP, that is bad news.

    john

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Apr 2021 07:03:10 +1000

The rules about MX and CNAME are primarily there so a MTA can easily identify itself by name and not produce mail loops. If you are send email to a CNAME then you are using a name the MTA doesn’t know itself by so it can’t reject the MX and any equal or higher value MX. Lots of mail used to bounce because mail was sent to an alias.  

To do the same filtering with CNAMES you need to lookup address records for each MX target and check all the CNAMES targets as well for a match.  You go from a single MX lookup that has to work to MX plus multiple A and AAAA lookups that have to work and you have to describe the behavior when those lookups fail. 
-- 
Mark Andrews

> On 5 Apr 2021, at 06:31, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> What John Levine says.
> 
> You can say things like "those people should be liberal in what they accept and overlook my minor error" but sometimes you run into people who aren't conservative, just like you aren't conservative if you violate a rule knowingly. And sometimes you run into people who haven't tested their handling of the error you commit, and untested code breaks, that's a <beep> <beep> axiom.
> 
> Arnt
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2021 17:13:19 -0400

>You can say things like "those people should be liberal in what they accept 

That's the most misunderstood quote in the history of the Internet.

What it means is to be liberal when interpreting standards.  For example,
earlier today someone asked about addresses that quote characters that
don't need to be quoted.  One could read the standard either way, so while
I would not send mail with needlessly quoted characters, I wouldn't refuse
to accept them.  What that does not mean is to accept an address with three 
unquoted dots in a row which is obviously forbidden.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Apr 2021 14:17:28 -0700

On 4/4/2021 2:13 PM, John Levine wrote:
> One could read the standard either way,

The above is an example of the essential requirement to Postel's 
directive.  In the face of possible ambiguity in how a standard is 
interpreted, try to be conservative in what you send and try to be 
liberal in what you accept.

Absent that kind of contextual constraint, the directive produces 
non-interoperability.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Mon, 05 Apr 2021 01:26:25 +0300

> clearly about SMTP, that is bad news.

What is MTA-STS when in enforce mode?

> "enforce": In this mode, Sending MTAs MUST NOT deliver the
>      message to hosts that fail MX matching or certificate validation
>      or that do not support STARTTLS.

1) failed MX matching, as per section 4.1;
2) failed certificate validation, as per section 4.2
3) a host doesn't support STARTTLS

Those seem to be the only reasons that a Sending MTA honoring MTA-STS 
MAY and MUST NOT deliver the messages when sending to an MX at a domain 
for which the sender has a valid and non-expired MTA-STS Policy, as 
least per MTA-STS, and to the best of my knowledge.

Can there exist other reasons, not related to MTA-STS, that allows or 
obliges the sending MTA not to deliver messages? It sure can. Is MX 
pointing to CNAME one of them?

Other than interpreting the:

> Any other response, specifically including a value that will return a
>   CNAME record when queried, lies outside the scope of this Standard.

as “It is your problem if the target of the MX refers to a CNAME
and things break"

-- is it explicitly standardized what MTA should do with such MX 
records/hosts when delivering mail?
If not, can an MTA do whatever and report it as an MTA-STS validation 
error when it's not?

On 2021-04-05 00:23, John R Levine wrote:
> You might also consider that some of the people you're arguing with
> have been writing standards documents since before you were born, so
> perhaps they have some experience worth learning from.

My apologies if I sound(ed) cocky. I am really grateful for everyone's 
thoughts. Without a shadow of a doubt, all the responses are valuable to 
me and they will encourage me to keep reading RFCs more carefully and to 
comply with them. After all, it is not fair to ask of others what you 
are not willing to do yourself. :)

But at the same time, I believe it's not too much to ask for from 
Microsoft to either send messages to MXs that point to CNAMEs or at 
least report errors correctly. They are huge. They can handle that.

Thank's everyone!

--
Warm regards,
Kristijonas

       __            /^\
     .'  \          / :.\
    /     \         | :: \
   /   /.  \       / ::: |
  |    |::. \     / :::'/
  |   / \::. |   / :::'/
  `--`   \'  `~~~ ':'/`
          /         (
         /   0 _ 0   \
       \/     \_/     \/
     -== '.'   |   '.' ==-
       /\    '-^-'    /\
         \   _   _   /
        .-`-((\o/))-`-.
   _   /     //^\\     \   _
."o".(    , .:::. ,    )."o".
|o  o\\    \:::::/    //o  o|
  \    \\   |:::::|   //    /
   \    \\__/:::::\__//    /
    \ .:.\  `':::'`  /.:. /
     \':: |_       _| ::'/
  jgs `---` `"""""` `---`

Happy Easter!

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 04 Apr 2021 20:27:11 -0400

Kristijonas Lukas Bukauskas writes:

> 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.

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Mon, 05 Apr 2021 06:49:07 +0300

On 2021-04-05 03:27, Sam Varshavchik wrote:
>> 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?
> 
> interpretation of it. The MX record gives the name of the host, and it
> needs to match the STS policy. The End.
> 

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 06 Apr 2021 17:16:36 +1000

> least report errors correctly. They are huge. They can handle that.

This world view will not serve you well.

My view: Microsoft are big therefore they have no need to test with weird error cases because others will work around even their egregious bugs, let alone their imperfect handling of error conditions.

Also it's harder to get support for making any change in a large organisation without giving a good reason, and "Kristijonas wants it" isn't on the management approved list of good reasons.

It's not an ideal world, but we don't live in an ideal world.  We live in a real world, and in the real world "Microsoft are huge so they can handle the cost of doing what I want them to do" only works if you have a significant enough stick to incentivise them to do so.

Regards,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Tue, 06 Apr 2021 23:04:48 +0300

On 2021-04-06 10:16, Bron Gondwana wrote:

> It's not an ideal world, but we don't live in an ideal world.  We live 
> in a real world, and in the real world "Microsoft are huge so they can 
> handle the cost of doing what I want them to do" only works if you have 
> a significant enough stick to incentivise them to do so.

I believe O365 clients of *paid* services could argue this is a breach 
of the contract. A client wants to deliver a message to 
[email-masked]. Sending MTA misleadingly says: Receiving MTA of 
[email-masked] has the problem A (MTA-STS validation failed), that's 
why we can't provide you a service you paid for. If that's not the case 
(and I suppose it's not: RFC8461, section 4.1 defines MX host Validation 
by matching MX record *name* against MTA-STS policy; the end).

Things are more complicated, I believe, and it depends on the 
jurisdiction(s), but when refusing to provide a paid service, I'd see 
the correct error reporting as a minimum requirement: by either showing 
generic or more specific errors, but never misleading ones.

That's more of a legal question though.

--
Regards,
Kristijonas

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Apr 2021 22:33:28 +0200

On Tuesday 6 April 2021 22:04:48 CEST, Kristijonas Lukas Bukauskas wrote:
> I believe O365 clients of *paid* services could argue this is a 
> breach of the contract. A client wants to deliver a message to 
> [email-masked]. Sending MTA misleadingly says: Receiving MTA 
> of [email-masked] has the problem A (MTA-STS validation 
> failed), that's why we can't provide you a service you paid for. 
> If that's not the case (and I suppose it's not: RFC8461, section 
> 4.1 defines MX host Validation by matching MX record *name* 
> against MTA-STS policy; the end).

Look it up and quote chapter and verse, please. I don't see anything of the 
kind. I do see wording in "my" enterprise documentation that IMO suggests a 
required ability to send to working sites, but nothing that requires 
Microsoft to provide a correct analysis of what is broken at sites outside 
Microsoft's control.

Arnt

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Wed, 07 Apr 2021 01:44:08 +0300

On 2021-04-06 23:33, Arnt Gulbrandsen wrote:

> Look it up and quote chapter and verse, please. I don't see anything
> of the kind. I do see wording in "my" enterprise documentation that
> IMO suggests a required ability to send to working sites, but nothing
> that requires Microsoft to provide a correct analysis of what is
> broken at sites outside Microsoft's control.

[DISCLAIMER: I am not a lawyer. The following is not legal advice. Even 
if I was a lawyer, this discussion would not make me *your* lawyer, and 
this would still not be legal advice. This is only my interpretation of 
the law and opinion about some aspect thereof. Don't sue me if you do 
something unreasonable based on what I said; I disclaim all 
responsibility for your actions. Act at your own risk]

https://www.microsoft.com/en-us/servicesagreement:

> 8. APPLICABLE LAW.
> 
> a. United States and Canada. If you acquired the application in the 
> United States or
> Canada, the laws of the state or province where you live (or, if a 
> business, where your
> principal place of business is located) govern the interpretation of 
> these terms, claims
> for breach of them, and all other claims (including consumer 
> protection, unfair
> competition, and tort claims), regardless of conflict of laws 
> principles.
> b. Outside the United States and Canada. If you acquired the 
> application in any other
> country, the laws of that country apply.

> 9. LEGAL EFFECT.
> 
> This agreement describes certain legal rights. You may have other 
> rights under the laws of your state or country. This agreement doesn't 
> change your rights under
> the laws of your state or country if the laws of your state or country 
> don't permit it to do so.

Thus, the client has rights laid down in the agreement plus the rights 
in the laws of the corresponding country. A service provider has 
obligations laid down in the agreement and might have obligations set in 
the laws of a corresponding country.

For example, local law here in Lithuania (Article 6.200 of the Civil 
Code of the Republic of 
Lithuania)[https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/TAIS.245495]:

> Principles of performance of a contract
> 
> * A contract must be performed by the parties in a proper way and in 
> good faith.
> * In performing a contract, each party shall be bound to contribute to 
> and to
> cooperate with the other party.
> * The parties shall be bound to use the most economical means in the 
> performance of the contract.
> * Where according to a contract or its nature, a party in exercising 
> certain actions is bound to make the best effort in the performance of 
> a contract, this party shall be
> bound to make such effort as a reasonable person would make in the same 
> circumstances.

If a party (a service provider) of a contract is a professional in his 
field with extensive experience, also due to the nature of a contract 
(e-mail services), although it not reasonable to require the provider to 
examine internal third-party server errors or misconfiguration, it's 
reasonable to expect the provider to know why it cannot provide the 
service (why it fails to send out a message on its end), and if 
requested, to explain those reasons to a client (sender). Showing 
specific errors (as opposed to generic ones) suggests the service 
provider's choice to provide a piece of detailed information. Being a 
professional, the service provider that shows detailed but misleading 
information (a client usually being a weaker side of the contract and 
that's especially true when it is a natural person) cannot be considered 
as acting in a good faith while performing the contract.

That's my view.

--

Regards,
Kristijonas

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Apr 2021 20:12:10 -0400

Kristijonas,

I'm not a lawyer either, but it is clear to me that the
discussion has strayed far outside any area that the IETF can do
anything about or that is productive for discussion on this
list.  

While I don't see the odds of forcing Microsoft to change their
behavior and/or to punish them for it as particularly high
(which may just be more evidence that I am not a lawyer), it
seems to me that, if you are convinced that they are behaving
illegally or very badly, your next step would be to raise the
issue with local regulatory, consumer protection, or
competitiveness authorities. Or perhaps with someone who has a
contractual relationship with Microsoft that they believes
Microsoft is violating and who might be inclined to try to
enforce those provisions.  However, I am quite certain (despite
not being a lawyer) that there is no contractual relationship
between Microsoft and "the Internet" (partially because I can't
even imagine what that would mean).

     best,
      john

--On Wednesday, April 7, 2021 01:44 +0300 Kristijonas Lukas
Bukauskas <kr=[email-masked]> wrote:

>> Look it up and quote chapter and verse, please. I don't see
>> anything of the kind. I do see wording in "my" enterprise
>> documentation that IMO suggests a required ability to send to
>> working sites, but nothing that requires Microsoft to provide
>> a correct analysis of what is broken at sites outside
>> Microsoft's control.
> 
> [DISCLAIMER: I am not a lawyer. The following is not legal
> advice. Even if I was a lawyer, this discussion would not make
> me *your* lawyer, and this would still not be legal advice.
> This is only my interpretation of the law and opinion about
> some aspect thereof. Don't sue me if you do something
> unreasonable based on what I said; I disclaim all
>> a. United States and Canada. If you acquired the application
>> in the  United States or
>> Canada, the laws of the state or province where you live (or,
>> if a  business, where your
>> principal place of business is located) govern the
>> interpretation of  these terms, claims
>> This agreement describes certain legal rights. You may have
>> other  rights under the laws of your state or country. This
>> agreement doesn't  change your rights under
>> the laws of your state or country if the laws of your state
>> or country  don't permit it to do so.
> 
> Thus, the client has rights laid down in the agreement plus
> the rights in the laws of the corresponding country. A service
> provider has obligations laid down in the agreement and might
> have obligations set in the laws of a corresponding country.
> 
> For example, local law here in Lithuania (Article 6.200 of the
> Civil Code of the Republic of
>> * A contract must be performed by the parties in a proper way
>> and in  good faith.
>> * In performing a contract, each party shall be bound to
>> contribute to  and to
>> * The parties shall be bound to use the most economical means
>> in the  performance of the contract.
>> * Where according to a contract or its nature, a party in
>> exercising  certain actions is bound to make the best effort
>> in the performance of  a contract, this party shall be
>> bound to make such effort as a reasonable person would make
>> in the same  circumstances.
> 
> If a party (a service provider) of a contract is a
> professional in his field with extensive experience, also due
> to the nature of a contract (e-mail services), although it not
> reasonable to require the provider to examine internal
> third-party server errors or misconfiguration, it's reasonable
> to expect the provider to know why it cannot provide the
> service (why it fails to send out a message on its end), and
> if requested, to explain those reasons to a client (sender).
> Showing specific errors (as opposed to generic ones) suggests
> the service provider's choice to provide a piece of detailed
> information. Being a professional, the service provider that
> shows detailed but misleading information (a client usually
> being a weaker side of the contract and that's especially true
> when it is a natural person) cannot be considered as acting in
> a good faith while performing the contract.
> 
> That's my view.

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Wed, 07 Apr 2021 04:59:30 +0300

> anything about or that is productive for discussion on this

Absolutely!  Thanks to everyone for your inputs. All the questions I had 
have been answered.

To sum up, the lesson learned - despite some sections of an RFC not 
directly referring to another RFC (as RFC8461, section 4.1 doesn't to 
neither RFC5321 nor RFC2181), one still should always want to read all 
normative and informative references, referenced at the end of an RFC. 
And probably other RFCs as well. And take them as a whole.  Just to be 
safe.

Thanks again everyone for all you do! :)

--
Regards,
Kristijonas