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> Sun, 04 April 2021 15:01 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 2BEC43A164B for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 08:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PLfyPzmPFtfP for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 08:01:33 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B77C3A164A for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 08:01:33 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lT4Et-000CLB-2c; Sun, 04 Apr 2021 11:00:35 -0400
Date: Sun, 04 Apr 2021 11:00:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
cc: mrsam@courier-mta.com
Message-ID: <70B5B7CCF6D64FBA195CCAA5@JcK-HP5>
In-Reply-To: <20210402002416.1825171CC176@ary.qy>
References: <20210402002416.1825171CC176@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/xIaj_Lbgr4wVEsmkxL4pFo755V0>
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: Sun, 04 Apr 2021 15:01:38 -0000
--On Thursday, 01 April, 2021 20:24 -0400 John Levine <johnl@taugh.com> wrote: > It appears that Sam Varshavchik <mrsam@courier-mta.com> said: >> My viewpoints are somewhat dated. The persona-non-grata >> status of MXs pointing to CNAMEs – that verbiage appears >> to be new to the current SMTP standard, I checked and did >> not find any equivalent language in the prior one; so my >> implementation reflected that. > > The author of 5321 is on this list so perhaps he recalls what > the motivation for the change was. I'm sure it wasn't > accidental. No, and my apologies if parts of what follow sounds like a rant. Actually, the rule is in RFC 1123 Section 5.2.2 with the text in5321 as just a clarification. My memory of that part of the discussion in the late 1980s is very vague, but I think that it includes some concern about the combination of performance, what action should be taken on a CNAME loop if one were detected, and the whole situation being error-prone. That combines with the obvious: because users are not expected to see those target names, there is no good reason to have them be anything but final (1123 says "canonical") names. Approximately the same reasoning applies to the DATA of one MX record, when resolved, pointing to another MX record with the addition of questions of what would then be two sets of priorities would mean in that case. Once upon a time, we used to try to design protocols so that the functionality that was needed was available but that the number of different ways to do something was minimized, more or less on the assumption that two or three ways to do the same thing created opportunities for errors, vulnerabilities, and/or the need to make the specifications to make things more complicated by considering the interactions. So, given that there is no real reason why an MX RR should point to either another MX RR, a CNAME RR, or, for that matter, TXT or anything else, why allow it. Noting my recent comments about how 2821 (and hence 5321 and the evolving 5321bis) were assembled, 5321 is inconsistent about where it says "don't do that", "if you do that, bad things may happen and what they are and what you should do about them lies outside the specification", and "if you decide to violate the rule in Section X.Y.Z, then you should...". In general, there are reasons for each case, but there are probably exceptions. 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. john
- [ietf-smtp] MTS-STS validation when MX host point… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Mark Andrews
- Re: [ietf-smtp] MTS-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTA-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTA-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Hector Santos
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] CNAME considered harmful, was MTS… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Arnt Gulbrandsen
- Re: [ietf-smtp] CNAME considered harmful, was MTS… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Mark Andrews
- Re: [ietf-smtp] on liberality, was MTS-STS_valida… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] on liberality, was MTS-STS_valida… Dave Crocker
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Bron Gondwana
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Arnt Gulbrandsen
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas