IETF Logo Mail Archive

Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

Kristijonas Lukas Bukauskas <kr@n0.lt> Tue, 06 April 2021 20:04 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 A49143A2EA1 for <ietf-smtp@ietfa.amsl.com>; Tue, 6 Apr 2021 13:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_BLOCKED=0.001, 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 cpJjJN70DI19 for <ietf-smtp@ietfa.amsl.com>; Tue, 6 Apr 2021 13:04:55 -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 2225E3A2EA5 for <ietf-smtp@ietf.org>; Tue, 6 Apr 2021 13:04:55 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id 67B7BFC204; Tue, 6 Apr 2021 20:04:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617739488; bh=wXa9GG4N56JtJAm4qQbt+GDLj9cu9FTYXWTO6IWxXmA=; h=From:To:Subject; b=n1LvW0C3R2P7hDLEsYQ59XbSlC9t2QacJe9kpueQN4AApQjxFIry+Ot8EQYy9o2WJ HDEIwTR9bwvRlwCh9ZIKrbF1qq40KO6g+CTzqxCvLNZVfikoZANBLffSzZphgG4JMP v/ge3LWizwWRnK6d+/K9CZlSAKqddAm/e/DHEDMA=
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: Tue, 06 Apr 2021 23:04:48 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: ietf-smtp@ietf.org
In-Reply-To: <71ceffea-7837-4502-9eff-929008b032c5@dogfood.fastmail.com>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <e87c4a27cb86ec5b32f0539754c341f3@n0.lt> <a232c63-bf8-2371-51e1-b64d119ad55d@taugh.com> <BE4982F24C6848D1624C4D1D@JcK-HP5> <2a09c64747a5c027c2655671ada3b3f8@n0.lt> <71ceffea-7837-4502-9eff-929008b032c5@dogfood.fastmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <741de85508e5d4d8622ccb178bc82fbf@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/LU95Ocym1gFkvDkCk3adIM8MS1g>
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: Tue, 06 Apr 2021 20:05:00 -0000

On 2021-04-06 10:16, Bron Gondwana wrote:

> It's not an ideal world, but we don't live in an ideal world.  We live 
> in a real world, and in the real world "Microsoft are huge so they can 
> handle the cost of doing what I want them to do" only works if you have 
> a significant enough stick to incentivise them to do so.

I believe O365 clients of *paid* services could argue this is a breach 
of the contract. A client wants to deliver a message to 
user@example.com. Sending MTA misleadingly says: Receiving MTA of 
user@example.com has the problem A (MTA-STS validation failed), that's 
why we can't provide you a service you paid for. If that's not the case 
(and I suppose it's not: RFC8461, section 4.1 defines MX host Validation 
by matching MX record *name* against MTA-STS policy; the end).

Things are more complicated, I believe, and it depends on the 
jurisdiction(s), but when refusing to provide a paid service, I'd see 
the correct error reporting as a minimum requirement: by either showing 
generic or more specific errors, but never misleading ones.

That's more of a legal question though.

--
Regards,
Kristijonas

v2.23.0 | Report a Bug | By Email