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

Kristijonas Lukas Bukauskas <> Thu, 01 April 2021 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F58A3A1C70 for <>; Thu, 1 Apr 2021 10:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 MYl9xU4vSBDc for <>; Thu, 1 Apr 2021 10:23:16 -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 B22ED3A1C5A for <>; Thu, 1 Apr 2021 10:23:15 -0700 (PDT)
Received: from (localhost.localdomain [IPv6:::1]) by (Postfix) with ESMTPSA id 43F5FFC48D; Thu, 1 Apr 2021 17:23:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1617297793; bh=oA6zKOV2GeQntoUUoZrY8/bF0d9TL8hswlsSeAsfv08=; h=From:To:Subject; b=ethgmo9GCFosWWhssT9VbYEOrpUBdv7dixJtfmmdFzWWBPrTODy7Bxu6t7C/ZqB7r cRXx6oqirW45DzAGhf1mv0zwtTAMY5JvlUbIskrZux8FA36md8PqTGf7wcXIE/w222 02QaSGmi6hfb84o1TL6X96cOQg22lJ6oaKbRrPEM=
Authentication-Results: ixion; spf=pass (sender IP is ::1)
Received-SPF: pass (ixion: connection is authenticated)
MIME-Version: 1.0
Date: Thu, 01 Apr 2021 20:23:13 +0300
From: Kristijonas Lukas Bukauskas <>
To: John R Levine <>
In-Reply-To: <>
References: <20210401003023.713A871BE253@ary.qy> <> <> <> <>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <>
Content-Type: multipart/alternative; boundary="=_3a7ee2518afd9eb2d0c5a3bf8234c134"
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: Thu, 01 Apr 2021 17:23:26 -0000

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

>> {"organization-name":"Microsoft 
>> Corporation","date-range":{"start-datetime":"2021-03-30T00:00:00Z","end-datetime":"2021-03-30T23:59:59Z"},"contact-info":"","report-id":"","policies":[{"policy":{"policy-type":"sts","policy-string":["version: 
>> STSv1","mode: enforce","mx:","max_age: 
>> 84600"],"policy-domain":""},"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 and 
>> * 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.

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 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 
> 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 Depending on the 
> configuration of your mail server, you may also need a receive 
> connector to match the receiving SMTP FQDN* 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.



Best wishes,