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

Kristijonas Lukas Bukauskas <kr@n0.lt> Wed, 31 March 2021 21:44 UTC

Return-Path: <kr@n0.lt>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F1E6D3A386A for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 14:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, 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=n0.lt
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t9CsfuLTdbcv for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 14:44:47 -0700 (PDT)
Received: from ixion.n0.lt (ixion.n0.lt []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE0C3A384F for <ietf-smtp@ietf.org>; Wed, 31 Mar 2021 14:44:46 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id 1CA76FC1AC for <ietf-smtp@ietf.org>; Wed, 31 Mar 2021 21:44:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617227083; bh=GLD//wHNT8uw5J/DNjFiB6ZCIY1rVMivypXboyPiUYA=; h=From:To:Subject; b=SLtS7gUlmSMtlzSzmflhRhE/4aL0RZkW5oThXKi1jhDBl01hKUay1Bk4qHsBsRJek foqKTsco5C3DwmmTNY7WWcW7yGT0w7oCW7r9UtMRTwDjnICaoOCZvJjRGUnFu8gnTT 47S1/ku8dIeqqW/VV1tI+A7fVUKQfDAvuMBeJtVk=
Authentication-Results: ixion; spf=pass (sender IP is ::1) smtp.mailfrom=kr@n0.lt smtp.helo=webmail.n0.lt
Received-SPF: pass (ixion: connection is authenticated)
MIME-Version: 1.0
Date: Thu, 01 Apr 2021 00:44:43 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: ietf-smtp@ietf.org
Reply-To: kr@n0.lt
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <59a4ba6c024e3cdc2c10dc6edc673ef7@n0.lt>
X-Sender: kr@n0.lt
Content-Type: multipart/alternative; boundary="=_99b6282066f96f24bdf58a74d343bd6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/MXe_Cx0IgsM1N4KZYxH2XDQAGZc>
Subject: [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: Wed, 31 Mar 2021 21:46:29 -0000


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 ( 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 
> [1], for MX records to point to CNAMEs. Despite that, I do not believe 
> that it should affect MX host validation in accordance with RFC 8 
> [2]461 §4.1 [2] when selecting a target MX host, for the reasons of:
> *
> RFC 2181 is an RFC on Clarifications to the DNS Specification, not 
> *
> Selecting an MX target host is regulated in a different RFC, namely and 
> specifically in RFC 5321 §5.1 [3]:
>> 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. :)


[1] https://tools.ietf.org/html/rfc2181#section-10.3
[2] https://tools.ietf.org/html/rfc8461#section-4.1
[3] https://tools.ietf.org/html/rfc5321#section-5.1