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

Kristijonas Lukas Bukauskas <> Tue, 06 April 2021 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B6BC3A3417 for <>; Tue, 6 Apr 2021 15:44:15 -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 bCEkhP7fFpB6 for <>; Tue, 6 Apr 2021 15:44:10 -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 1F9B03A3411 for <>; Tue, 6 Apr 2021 15:44:10 -0700 (PDT)
Received: from (localhost.localdomain [IPv6:::1]) by (Postfix) with ESMTPSA id 41420FC204; Tue, 6 Apr 2021 22:44:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1617749048; bh=q3z/JRNmjirrVBA/eGOkFE6dTNgHokc6/Ha3noPxPl0=; h=From:To:Subject; b=WpcsC5ZkjUxD7OqOKUwR5/QI8yFilPIc78l0DrcWllgjVN50bilFmaI2mjkp7Onfw sIqN8MRM+/olfIjpeoxSvytR8fGqwA1J5x1uTdrR0UtTkSh/+Vl6mUxozwCpEdsZEZ 1qD6z52LWF1gAMwGe8oOWxxGIxPvW5hG+kRWqgSg=
Authentication-Results: ixion; spf=pass (sender IP is ::1)
Received-SPF: pass (ixion: connection is authenticated)
MIME-Version: 1.0
Date: Wed, 07 Apr 2021 01:44:08 +0300
From: Kristijonas Lukas Bukauskas <>
To: Arnt Gulbrandsen <>
In-Reply-To: <>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <> <> <BE4982F24C6848D1624C4D1D@JcK-HP5> <> <> <> <>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <>
Content-Type: multipart/alternative; boundary="=_160e0ce7fedfa22dbfa88b8fb304f1f7"
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: Tue, 06 Apr 2021 22:44:15 -0000

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]

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

> 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 

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