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

Mark Andrews <marka@isc.org> Thu, 01 April 2021 00:09 UTC

Return-Path: <marka@isc.org>
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 D0F853A3C5A for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 17:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.119
X-Spam-Level:
X-Spam-Status: No, score=-7.119 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=NH5+P3dq; dkim=pass (1024-bit key) header.d=isc.org header.b=Xfy2wX7L
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 hbbnguYwmLiM for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 17:09:24 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181AB3A3C5B for <ietf-smtp@ietf.org>; Wed, 31 Mar 2021 17:09:24 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D5B0F3AB022; Thu, 1 Apr 2021 00:09:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1617235762; bh=N3+tELCsne7vYCUED2hJhfFgz73MsUUc/wtAlRMe12s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NH5+P3dq9UpP42SNmXRdExrFdUiDnfTqZJ6YeuAYWLzx4b63GxceeAK4wscFWCvCV 57IA2y4Px4h4JmeQjUdtAo7uwG7OeRBzCO8qTBoMEXLz/LOfRV8c56waHwp/zGsiYq smQhzmCgY5dBOrTdLRlS8nBtkA2aAbjIDnbT3EHI=
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 90F7D16003E; Thu, 1 Apr 2021 00:09:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55F2F1600A8; Thu, 1 Apr 2021 00:09:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 55F2F1600A8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1617235762; bh=wCOpAfO71BEfgWZEHS1aZnceUFrbDDqxd8pZLTm1tnY=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=Xfy2wX7LGJkw0EUUH6o37FqjSe9eBTZH4l8pzLAdzfmGJPxBUxM8F+Vl7gndNc8fG n5TUXBkQ9fm3ilKWtAMHTiYYXSEmBZq7W9kKt78D/z5dqp0+PVUiiYVP++vVgFRGy9 hV9M1Cb55bVHY6KpVT9SC0NyiPeY0regIrrYeuj0=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id blDy7xk-n5DB; Thu, 1 Apr 2021 00:09:22 +0000 (UTC)
Received: from [172.30.42.99] (n49-177-132-25.bla3.nsw.optusnet.com.au [49.177.132.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 5445216003E; Thu, 1 Apr 2021 00:09:21 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <59a4ba6c024e3cdc2c10dc6edc673ef7@n0.lt>
Date: Thu, 1 Apr 2021 11:09:18 +1100
Cc: ietf-smtp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <992B07C8-5689-4092-A9CC-446731F5A114@isc.org>
References: <59a4ba6c024e3cdc2c10dc6edc673ef7@n0.lt>
To: kr@n0.lt
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/Wffr3K4ARyg7RFcMRfzYn22AXVs>
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-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: Thu, 01 Apr 2021 00:09:29 -0000

You need properly read the quoted section that talks about MX target being a CNAME.
In particular this sentence from RFC 5321, section 5.1:

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

In other words “It is your problem if the target of the MX refers to a CNAME
and things break."

The MX records for n0.lt are NOT RFC compliant.  The target points to a CNAME.

With regards to others delivering mail to, just because an implementation is
more liberal, it doesn’t make it correct.  It’s a absolute pain in the butt
when the 900lb gorillas don’t reject erroneous configurations as then everyone
else is under pressure to work with those configurations.  You get “But it works
with …”.

% dig n0.lt mx
;; BADCOOKIE, retrying.

; <<>> DiG 9.15.4] <<>> n0.lt mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48337
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 239ed73d712edd7d01000000606505ac5ca63d7a998dc694 (good)
;; QUESTION SECTION:
;n0.lt.				IN	MX

;; ANSWER SECTION:
n0.lt.			300	IN	MX	10 mx.n0.lt.

;; Query time: 2009 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 01 10:28:44 AEDT 2021
;; MSG SIZE  rcvd: 81

% dig mx.n0.lt
;; BADCOOKIE, retrying.

; <<>> DiG 9.15.4 <<>> mx.n0.lt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30179
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e8e0c48edf143f7e01000000606505b6cad98ca2cff6ac04 (good)
;; QUESTION SECTION:
;mx.n0.lt.			IN	A

;; ANSWER SECTION:
mx.n0.lt.		290	IN	CNAME	n0.lt.
n0.lt.			300	IN	A	188.166.32.32

;; Query time: 224 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 01 10:28:54 AEDT 2021
;; MSG SIZE  rcvd: 95



> On 1 Apr 2021, at 08:44, Kristijonas Lukas Bukauskas <kr=40n0.lt@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> I'm having an affair with one of the vendors as a sending MTA, honoring MTA-STS (RFC 8461). Their response:
> 
> 
> 	• Our TDS validation shows MX lookup for n0.lt returns n0.lt instead of mx.n0.lt. It is consistent with what we are seeing with production. 
> 
> remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.)' 3/24/2021 3:36:19 PM - Server at n0.lt (0.0.0.0) returned '450 4.4.317 Cannot connect to remote server [Message=451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.] [LastAttemptedServerName=n0.lt]
> 	• We can confirm that customer is not RFC compliant with MX pointing to a CNAME and we don't think it is worth to change the logic to accommodate that.
>   
> 	• Customer does have an easy fix on their side, just to modify their STS Policy to include n0.lt as one of the supported MX record.
> 
> 
> 
> 
> My objections:
> 
> 
> 
>> I'm familiar with a general prohibition, pursuant to RFC 2181 § 10.3, for MX records to point to CNAMEs. Despite that, I do not believe that it should affect MX host validation in accordance with RFC 8461 §4.1 when selecting a target MX host, for the reasons of:
>> 
>> 	• RFC 2181 is an RFC on Clarifications to the DNS Specification, not SMTP.
>> 
>> 	• Selecting an MX target host is regulated in a different RFC, namely and specifically in RFC 5321 §5.1:
>> 
>> 
>> 
>>> If MX records are present, but none of them are usable, this situation MUST be reported as an error.<...> When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38]
>> 
>> 
>> 	• Thus, the prohibition of CNAMEs is NOT an SMTP or MTA-STS issue. As per the RFC 5321 §5.1, which is used to select an MX target host, pursuant to RFC 8461 §4.1 (MX Host validation), vendors are NOT allowed to choose a different host name (in my scenario, n0.lt instead of mx.n0.lt which is found in MX record). The situation MUST be reported as an error, if none of the found records are usuable. That MUST happened even if the target domain has not deployed MTA-STS. And this doesn’t seem to be the case. When MTA-STS is not deployed, Microsoft, as a sending MTA doesn’t return any errors.
>> 
>> 	• No major providers (including, but not limited to Gmail) nor publicly available MTA-STS tests (including, but not limited to My Email Communications Security Assessment (MECSA) by European Commission’s Joint Research Center) doesn’t select n0.lt instead of mx.n0.lt which is found in MX record nor does it show any errors, suggesting my interpretation of different RFCs is most likely correct.
>> 
> 
> 
> 
> 
> As advised by one of the authors of RFC 8461, I'm reaching out to the IETF SMTP list for your opinions, namely if MTA-STS, in theory, should fail to validate if an MX points to a CNAME.  
> 
> Any insights would be much appreciated and thanked in advance. :)
> 
> --
> Regards,
> Kristijonas
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org