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

Kristijonas Lukas Bukauskas <kr@n0.lt> Sun, 04 April 2021 18:07 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2303A1366 for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 11:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv3CBQgdAqXs for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 11:07:36 -0700 (PDT)
Received: from ixion.n0.lt (ixion.n0.lt [188.166.32.32]) (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 53EE13A1364 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 11:07:36 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id D13BDFC4C3; Sun, 4 Apr 2021 18:07:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617559648; bh=90Q48HMARuKpABMYcRPTGCY3ceKbXRB3XknpHodKp6E=; h=From:To:Subject; b=F3pLnOVa7NRzctjaZz6dCC7dBn1ejuW8v9QffbLdcEYN1vR2HpPJ/BADjwS2wQOGh g0gM11t2AomZeAiI1Uwtmg+wYcm+vsVFmydqFaFFhgop4nVRnxK84AU9VJN6RtNDaI BHoMuyM+47EDR3YkqYgRNRiGtaF1rjEwjxztj9fQ=
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: Sun, 04 Apr 2021 21:07:28 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: John C Klensin <john-ietf@jck.com>
Cc: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org, mrsam@courier-mta.com
In-Reply-To: <70B5B7CCF6D64FBA195CCAA5@JcK-HP5>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <e87c4a27cb86ec5b32f0539754c341f3@n0.lt>
X-Sender: kr@n0.lt
Content-Type: multipart/alternative; boundary="=_182d1e2d2d41f16f47bf25c88c0bd208"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/jzQivduK7xevLRXE5rQ6zVOCMuM>
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: Sun, 04 Apr 2021 18:07:42 -0000

On 2021-04-04 18:00, John C Klensin wrote:

> But the bottom line here, as John and others have suggested, is
> that the right answer to the question in the subject line is
> that an SMTP sender encountering an MX record whose DATA points
> to a CNAME (or anything other than an address record) should
> just treat the message as undeliverable, a popular
> implementation or two notwithstanding.  And worrying about
> validating the clearly invalid just does not make a lot of sense.

Shouldn't an MTA-STS validator do *exactly* what RFC8461, section 4.1 
says: if the *MX record name* matches one or more of the "mx" fields in 
the applied policy, a receiving candidate MX host is *valid* according 
to an applied MTA-STS Policy? And thus, MX Host Validation passes, even 
if the MX record itself is otherwise invalid. Match the MX record name 
against "mx" fields in the applied policy. That's it. Conditions to pass 
validation here are exhaustive, not inclusive, even if a Sending MTA 
honoring MTA-STS might not like that, and even if it wants to be less 
liberal or whatever. Exhaustive conditions were met -- validation 
passed.

--
Regards,
Kristijonas