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

John C Klensin <john-ietf@jck.com> Wed, 07 April 2021 00:12 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB28E3A36F9; Tue, 6 Apr 2021 17:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG6QF69pdSEs; Tue, 6 Apr 2021 17:12:22 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C63A3A36BA; Tue, 6 Apr 2021 17:12:19 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lTvns-0005s5-Hb; Tue, 06 Apr 2021 20:12:16 -0400
Date: Tue, 06 Apr 2021 20:12:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: Kristijonas Lukas Bukauskas <kr=40n0.lt@dmarc.ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
cc: ietf-smtp@ietf.org
Message-ID: <348738A65F9E297975C78D5B@PSB>
In-Reply-To: <f78eb70a909a1d11629c9899223588dc@n0.lt>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <e87c4a27cb86ec5b32f0539754c341f3@n0.lt> <a232c63-bf8-2371-51e1-b64d119ad55d@taugh.com> <BE4982F24C6848D1624C4D1D@JcK-HP5> <2a09c64747a5c027c2655671ada3b3f8@n0.lt> <71ceffea-7837-4502-9eff-929008b032c5@dogfood.fastmail.com> <741de85508e5d4d8622ccb178bc82fbf@n0.lt> <31d4e036-8a37-4ac7-bee0-194f33a09daf@gulbrandsen.priv.no> <f78eb70a909a1d11629c9899223588dc@n0.lt>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/sisrQqMGx_BiVmENk50XVSD8ReA>
Subject: Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 00:12:27 -0000

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=40n0.lt@dmarc.ietf.org> wrote:

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