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 22:26 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 C1BC43A1CEA for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 15:26:34 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=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 oLadBAu-zzBv for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 15:26:30 -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 4731A3A1CE9 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 15:26:30 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id F369BFD429; Sun, 4 Apr 2021 22:26:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617575186; bh=R/LZEBi2w1cWVhVy/DSw4JFIg4JrW+hBiItECn3bus8=; h=From:To:Subject; b=h61iULpFDu12janv6fgfzZzcjB/E3v/L6PhcPUW3A3lOThdDYad3CpbsVekwqZvbN F5C+EXpRjPbu/WAz+Nyy5+zKVmUF9uOFCZVp0LVV6OWgjzypqYo+pDEQM7rIhWbpLr DrBa4i0dLGDR5Z2p+EWkKxHAe36/rEfonbOlYrSs=
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 01:26:25 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: John C Klensin <john-ietf@jck.com>
Cc: John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
In-Reply-To: <BE4982F24C6848D1624C4D1D@JcK-HP5>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <e87c4a27cb86ec5b32f0539754c341f3@n0.lt> <a232c63-bf8-2371-51e1-b64d119ad55d@taugh.com> <BE4982F24C6848D1624C4D1D@JcK-HP5>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <2a09c64747a5c027c2655671ada3b3f8@n0.lt>
X-Sender: kr@n0.lt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/cLBpsO9Tt5XF_fqRS9aC2eShGF4>
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 22:26:35 -0000

On 2021-04-04 23:53, John C Klensin wrote:

> (2) With regard to both the above and the note Kristijonas
> posted a few minutes ago, if RFC 8461 says anything that appears
> to contradict the above, it is a bug and those who care should
> be generating errata or, better yet, working on an update.  8461
> can --at least as long as it is consistent with other deployed
> specs-- say anything it likes about certificates, where they
> come from, and how they are validated.  But, it is can be read
> as encouraging violation of 5321 in a specification that is
> clearly about SMTP, that is bad news.

What is MTA-STS when in enforce mode?

> "enforce": In this mode, Sending MTAs MUST NOT deliver the
>      message to hosts that fail MX matching or certificate validation
>      or that do not support STARTTLS.


1) failed MX matching, as per section 4.1;
2) failed certificate validation, as per section 4.2
3) a host doesn't support STARTTLS

Those seem to be the only reasons that a Sending MTA honoring MTA-STS 
MAY and MUST NOT deliver the messages when sending to an MX at a domain 
for which the sender has a valid and non-expired MTA-STS Policy, as 
least per MTA-STS, and to the best of my knowledge.

Can there exist other reasons, not related to MTA-STS, that allows or 
obliges the sending MTA not to deliver messages? It sure can. Is MX 
pointing to CNAME one of them?

Other than interpreting the:

> Any other response, specifically including a value that will return a
>   CNAME record when queried, lies outside the scope of this Standard.

as “It is your problem if the target of the MX refers to a CNAME
and things break"

-- is it explicitly standardized what MTA should do with such MX 
records/hosts when delivering mail?
If not, can an MTA do whatever and report it as an MTA-STS validation 
error when it's not?

On 2021-04-05 00:23, John R Levine wrote:
> You might also consider that some of the people you're arguing with
> have been writing standards documents since before you were born, so
> perhaps they have some experience worth learning from.

My apologies if I sound(ed) cocky. I am really grateful for everyone's 
thoughts. Without a shadow of a doubt, all the responses are valuable to 
me and they will encourage me to keep reading RFCs more carefully and to 
comply with them. After all, it is not fair to ask of others what you 
are not willing to do yourself. :)

But at the same time, I believe it's not too much to ask for from 
Microsoft to either send messages to MXs that point to CNAMEs or at 
least report errors correctly. They are huge. They can handle that.

Thank's everyone!

--
Warm regards,
Kristijonas

       __            /^\
     .'  \          / :.\
    /     \         | :: \
   /   /.  \       / ::: |
  |    |::. \     / :::'/
  |   / \::. |   / :::'/
  `--`   \'  `~~~ ':'/`
          /         (
         /   0 _ 0   \
       \/     \_/     \/
     -== '.'   |   '.' ==-
       /\    '-^-'    /\
         \   _   _   /
        .-`-((\o/))-`-.
   _   /     //^\\     \   _
."o".(    , .:::. ,    )."o".
|o  o\\    \:::::/    //o  o|
  \    \\   |:::::|   //    /
   \    \\__/:::::\__//    /
    \ .:.\  `':::'`  /.:. /
     \':: |_       _| ::'/
  jgs `---` `"""""` `---`

Happy Easter!