Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3
Kristijonas Lukas Bukauskas <kr@n0.lt> Mon, 05 April 2021 03:49 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 116073A271E for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 20:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_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 i3c47J6DCdbV for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 20:49:09 -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 8838F3A271B for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 20:49:09 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id 9856BFD7E1; Mon, 5 Apr 2021 03:49:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617594547; bh=vBN9X9d2ZVFu4AlqkvDKsk8kleXHzOLIUk2OhYryVGY=; h=From:To:Subject; b=hApui63I3cyvihgEXMbJ6mRpON4LquHnpi5fx+SMPVFYY4A4VJ2GmOSFlyejMDqgt zWgx0ioqeo5VcZYLTEfOIvq7D2gPyGl0GSDMVwyqIcHYzXGAFy8QRI1prDslhVgecP RwRS7TkHPDq4Y6zYvqMCMRQW+g3kRXj5D/EkQBVk=
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: Mon, 05 Apr 2021 06:49:07 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: Sam Varshavchik <mrsam@courier-mta.com>
Cc: ietf-smtp@ietf.org
In-Reply-To: <cone.1617582431.794624.24718.1004@monster.email-scan.com>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <e87c4a27cb86ec5b32f0539754c341f3@n0.lt> <cone.1617582431.794624.24718.1004@monster.email-scan.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <8cacbb79f17a64ac6fc25769eddb74b3@n0.lt>
X-Sender: kr@n0.lt
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/CsI3M2i-NcaWMSitsWdYu3MoM5w>
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: Mon, 05 Apr 2021 03:49:14 -0000
On 2021-04-05 03:27, Sam Varshavchik wrote: > Kristijonas Lukas Bukauskas writes: > >> 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? > > That is how I interpret it. It seems to be the most direct, plain, > interpretation of it. The MX record gives the name of the host, and it > needs to match the STS policy. The End. > > But it seems that others interpret it as that, plus some additional > requirements. > The MTA's position: > As my colleagues who investigated this issue communicated, our position > is that this is primarily due > to what we believe to be a non-RFC compliant MX record. > Regardless of the liberal acceptance of this for regular mail, in this > case, our implementation of > MTA-STS is not as liberal -- suggests that they are fine with MXs pointing to CNAME for regular mail, but not when delivering mail to domains with MTA-STS. That would be somewhat fine with me as well since it looks like RFC5321 doesn't clearly say what to do with MX to CNAME -- it points out it lies outside the scope of that Standard, it refers to Clarifications on DNS Specification suggesting the RFC5321 sees that as a DNS issue, that is, DNS -- and not SMTP-- should deal with the issue of canonical names, what they are, how CNAME records relate, what names are legal in what parts of the DNS, and what is the valid syntax of a DNS name, etc. I don't see the prohibition of CNAME in MX records as implying that MTA should not deliver messages solely based on that. But let's assume, MTAs do have a choice here, and so, some MTAs exercise their freedom to choose whenever they want, not necessarily always, but in some defined circumstances, preferably by documenting them, or -- if they don't have time for that -- by showing correct error messages. They claim their implementation of MTA-STS is not as liberal for MXs pointing to CNAME as for regular mail. But it becomes liberal and tolerant again as soon as a Receiving MTA updates MTA-STS policy with mx: [CNAME-expanded name], in my case mx: n0.lt (https://mta-sts.n0.lt/.well-known/mta-sts.txt). So it looks like their implementation of MTA-STS validator itself is confused and undecided whether it wants to be liberal for or conservative against MXs pointing to CNAME. Or more realistically -- MX Host Validation is not implemented in the way it is explicitly described in RFC8461, section 4.1. Thus, not only are the errors possibly misleading but their position could also be potentially viewed as such. And all the above in the context of not showing the correct error messages and a failure to disclose they rolled out the feature of the Outgoing MTA-STS Validation. At least not in the Roadmap, the source their very own support sees as the ultimate (it says it is still development? Sorry, we can't help you with this feature until it is rolled out/launched) [the Roadmap was finally updated]. I see that as an extremely ignorant and confusing way of doing things. -- Regards, Kristijonas
- [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