Re: [ietf-smtp] why are we reinventing mta-sts ?

Rich Kulawiec <rsk@gsp.org> Wed, 09 October 2019 08:22 UTC

Return-Path: <rsk@gsp.org>
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 615841200B5 for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Oct 2019 01:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oCkuwWpnw0dR for <ietf-smtp@ietfa.amsl.com>; Wed, 9 Oct 2019 01:22:28 -0700 (PDT)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E8012000F for <ietf-smtp@ietf.org>; Wed, 9 Oct 2019 01:22:27 -0700 (PDT)
Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id x998MUJG026287 for <ietf-smtp@ietf.org>; Wed, 9 Oct 2019 04:22:30 -0400 (EDT)
Date: Wed, 09 Oct 2019 04:22:26 -0400
From: Rich Kulawiec <rsk@gsp.org>
To: SMTP Discuss <ietf-smtp@ietf.org>
Message-ID: <20191009082225.GA9444@gsp.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <78878.1570543102@turing-police>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/iO6rwKXoiQqp5FhlrF7_IdYWQuY>
Subject: Re: [ietf-smtp] why are we reinventing mta-sts ?
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: Wed, 09 Oct 2019 08:22:29 -0000

On Tue, Oct 08, 2019 at 09:58:22AM -0400, Valdis Kl??tnieks wrote:
> The point is that there's 3 basic cases:

[ good analysis elided ]

It's the resources outside these that can be a major problem.  In some
environments, "offering another service to the public Internet" requires
formal proposals, discussions, meetings, i's dotted and t's crossed,
auditors placated, security people mollified, and so on.  And while
in this particular case it can be argued "we're making email more secure
by doing this" it still won't be an easy sell to some.

(more generally) Making email more secure/private is goodness.  Doing it
via multiple kludges based on TXT records and hostnames and HTTP and
so on is not.  I'm (painfully) well aware of the obstacles in the way
of doing it cleanly, but doing it this way incurs debt that sooner or
later we'll have to pay.

---rsk