IETF Logo Mail Archive

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

Peter Saint-Andre <stpeter@stpeter.im> Sat, 18 June 2022 17:56 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0790C14F73B for <uta@ietfa.amsl.com>; Sat, 18 Jun 2022 10:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.006
X-Spam-Level:
X-Spam-Status: No, score=-4.006 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, NICE_REPLY_A=-1.876, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=d1UPNy1U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=POR6cON0
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUAco1b-RcVD for <uta@ietfa.amsl.com>; Sat, 18 Jun 2022 10:56:34 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2ADC14F6EC for <uta@ietf.org>; Sat, 18 Jun 2022 10:56:34 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 694815C00C1; Sat, 18 Jun 2022 13:56:33 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 18 Jun 2022 13:56:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1655574993; x= 1655661393; bh=Lcyxg9mWS+LajiMrjqJLGZLM4WLmWHeBhuFiATIZrYI=; b=d 1UPNy1U22bIlvnBnqo5OyxDZLRhV8SGukCr8ryWIv7FOrvrYlu/KSMBLc81M7Xbw kSAV9ZGo2jvMrfV/2STYsya43DhPxfcSKtiNJOSp3JJyoorM3sn8YGAummsj7WlP lFK/H0ZC6/piSl+ey37pDiW1FGsvjm3wh2R9Cq9uvw8z4nb0/SZdFHhJlWV6oj8S fAfSDnMSuu58bcxMkEH8HMu/uf55wY/VapIzLM1PVLHQqLODIPMmnWVZczDn7BAI D1ezC5CQxbJXOnAh5R99jM9Z1tsXk4pkZXejS6W4UVNDyM0d0hkRdVkcR/FN5N/8 XcX4iMLR10n19HfHCKWTg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1655574993; x=1655661393; bh=L cyxg9mWS+LajiMrjqJLGZLM4WLmWHeBhuFiATIZrYI=; b=POR6cON0ZYaeIy+Jt 6BKZUAOt646aYD6oefwfiSKJKoSKkEQn5ViFcO4jJy1oJ9ioDMZNtn+QyGQjZCzA 72xLpxoXgM0K/A1vXfN/zXxoP+hCxvehnLufCmHDwUyYX54xEH1OQNkPGq9J4FmS PRrfeBVTfOKVactgMqkuHWhjOQHkz4xZ7wHqi1WDZue/dj+xckj0PhomWvn4TYuu p/jqUdBWoGW0FTK5qRMtz2WCtBb64kPMuytPD3x4LNGSBD1SdFo48q+S/xO8aA14 LtV0JwDbe9/axJYmJ0scxaEk3xYpHZScSYNQXjnnyBiuveDkOmGCTtNWkzIYrU0M OdOBg==
X-ME-Sender: <xms:0BGuYpNgxKqROZLG_X983U70isRkcHpVKH6qGlCG51dI0M1Ff4v1rA> <xme:0BGuYr9M2-03pljBrxYs_W0TDlEpdhanEWyQdrNZubdp5eMKj-JTw31RhCJlGibY3 1vumbREW11_WtPlxw>
X-ME-Received: <xmr:0BGuYoSfx6YZXNU-vkA58V7X2EmBG4O8k0BylL1O2QrIhVnf56rL8m_v18Lp>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvjedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfvfhfhufgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvght vghrucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqe enucggtffrrghtthgvrhhnpefgueegfedvkeetfeegkeekgefggfeuteetheegvdfgffev geekgfelhedtgeetfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh
X-ME-Proxy: <xmx:0BGuYlvv4iaRgIgU4gUGwZwjKQKqBVwewW9TKvF9y0ZG0fC4C1TQgg> <xmx:0BGuYhdw0z8k7mEnVlbkS9JPd7FWA1yB1y1kOKKE-_q92p9Bp0E7SQ> <xmx:0BGuYh0A1uvoC2nmxJPrzQvH1692yf6zJz4XDfrs67uz8GvOX7vUkQ> <xmx:0RGuYhFraC5wg-mL0S7khItT9OKmzzUQkf-ZQ4LWWJQ_hezjh1mSvw>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 18 Jun 2022 13:56:32 -0400 (EDT)
Message-ID: <00b3db53-9523-db44-1b18-e09dab2ff343@stpeter.im>
Date: Sat, 18 Jun 2022 11:56:30 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, uta@ietf.org
References: <165360014937.7348.791812490092301727@ietfa.amsl.com> <39887905-080d-0caa-86d9-45adea8705b9@cs.tcd.ie>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <39887905-080d-0caa-86d9-45adea8705b9@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/tzW9E2sSrkDuHh6x_7_XhRSHXaQ>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2022 17:56:38 -0000

On 5/27/22 7:51 AM, Stephen Farrell wrote:

> - section 3.2: I wondered why no mention of MTA-STS or
>    DANE? Could/should we say that MTA implementations
>    SHOULD include support for such strictness?

Hi Stephen,

Although these technologies (RFC 8461 and RFC 7672) seem sensible, I 
don't think we authors have a good handle on whether they are widely 
deployed enough to justify a SHOULD in a BCP. We will reach out to folks 
in the email community for guidance.

I also wonder how far this document should go in making recommendations 
for various application protocols - SIP, IRC, XMPP, NNTP, etc.

Peter

v2.23.0 | Report a Bug | By Email