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] =?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: 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