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

Kristijonas Lukas Bukauskas <> Sun, 04 April 2021 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 497163A19AE for <>; Sun, 4 Apr 2021 13:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dtDxc4iExY5U for <>; Sun, 4 Apr 2021 13:48:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47C5A3A19AC for <>; Sun, 4 Apr 2021 13:48:01 -0700 (PDT)
Received: from (localhost.localdomain [IPv6:::1]) by (Postfix) with ESMTPSA id 15E26FD456; Sun, 4 Apr 2021 20:47:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1617569272; bh=oHdcZqt9e4PXa4N+TE25spwnPRUu7UR86Lr9VFOYJBA=; h=From:To:Subject; b=T6VITqqo2CvzZUhoczcyCgl606RlzCtT12FYioUQI7OwKGL9DaP7BjT82BVpOYNt2 q754lD8TT603XF7lNA9D080bXfvZtQUODtphHlQ2Kpw9NuwIsq1HxgQplmcm+voHzA C2vEOw/MAUNhOFnH/eTTgeuU3EruEaYow5sZrAP4=
Authentication-Results: ixion; spf=pass (sender IP is ::1)
Received-SPF: pass (ixion: connection is authenticated)
MIME-Version: 1.0
Date: Sun, 04 Apr 2021 23:47:51 +0300
From: Kristijonas Lukas Bukauskas <>
To: John R Levine <>
Cc: John C Klensin <>,
In-Reply-To: <>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <> <>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <>
Content-Type: multipart/alternative; boundary="=_81617030e00b361704e7a56e0a7bed18"
Archived-At: <>
Subject: Re: [ietf-smtp] =?utf-8?q?MTS-STS_validation_when_MX_host_points_to_?= =?utf-8?q?a_CNAME=2C_violating__RFC_2181_=C2=A7_10=2E3?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Apr 2021 20:48:06 -0000

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

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

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., "") 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.