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