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

Keith Moore <moore@network-heretics.com> Tue, 08 October 2019 13:30 UTC

Return-Path: <moore@network-heretics.com>
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 3F4F9120178 for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 06:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 ftWQUKJUL51K for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 06:30:01 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B697012013F for <ietf-smtp@ietf.org>; Tue, 8 Oct 2019 06:29:46 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7949521FB5; Tue, 8 Oct 2019 09:29:45 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 08 Oct 2019 09:29:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KeCZ3e KiuqpyPmBN1YRpwTpNg3Oqls+hy+JUHSyB6d4=; b=k7q23CN25E5XDcB09MFvDu jd2Zlb6Yhktp/lfu1zvV6ttcXCyet5/mYfv6hCr+xGT1RscPgUtQ7XGJJyUPQUFx A4rArZUZ+Spwg+aINzUlmiNFK9ZawJ+K+O+U3z60HXq3tcw9L023il7fxFubdk9A FGW6GQNrePaHX8I/C4kdSNH6J+CU/QHC5IUDuAZ9tF05kQQvtt8Pd3VOyp+PoTmg kh+InFXqr/fU/JjXcPNugEWlj3pj1F+mm8E1mvOTDRHeb9mUpmtRSkgN10NFhrn8 4JFt+FNyuIH8x9jo/wCH12vkwl+OSA8PpaK32SFRvknsjnbrmNHkZOZbt6uEGh5A ==
X-ME-Sender: <xms:SY-cXeEWGkJ-hR9RYjE0egY1xksTfjAuln8Sr9Hi8X3qOmzmoeNqmA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheelgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucffohhmrghinhepvgigrghmphhlvgdrtghomh enucfkphepuddtkedrvddvuddrudektddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhm pehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:SY-cXb8vsgeb2_AUk1jztJYzlbk-PBYNzKMGBn6GEk9RVs1wbXhEZA> <xmx:SY-cXehT-KfLuxT9IcO7-P2HMlMwjh2VgRHaYiR3yIzZsESa_GwmVQ> <xmx:SY-cXR_Aiwc4d-21Ya-QR-lZOKdQ2yI-GramuU8Chrfu143G9BC4Bg> <xmx:SY-cXaKMer99UlbhS64UrlUGDtivsbT02RL6syQrvpSZ1DkljZAfdw>
Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C5D6F80069; Tue, 8 Oct 2019 09:29:44 -0400 (EDT)
To: ietf-smtp@ietf.org
References: <20191007162824.64ED8BB6CA1@ary.qy> <53D231EA-D749-4437-9759-6F1B3ECC6142@network-heretics.com> <alpine.OSX.2.21.99999.368.1910071506250.38715@ary.qy> <CAOEezJQt-6GNJ08MsZ5PUOBD6mf9CBXc8duu7xVLDxirzeqauQ@mail.gmail.com> <5b90d08f-8277-6c50-d069-4709880f932f@network-heretics.com> <alpine.DEB.2.20.1910081229230.8949@grey.csi.cam.ac.uk>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <07145df5-1b27-ba93-4a9f-9d878032cbd5@network-heretics.com>
Date: Tue, 08 Oct 2019 09:29:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1910081229230.8949@grey.csi.cam.ac.uk>
Content-Type: multipart/alternative; boundary="------------8A6EEC6E891D0D57B59B2027"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/vO5a9Dzh-hNEUmBLgnnOZoikA14>
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: Tue, 08 Oct 2019 13:30:03 -0000

On 10/8/19 7:34 AM, Tony Finch wrote:

> Keith Moore<moore@network-heretics.com>  wrote:
>
>> I was thinking more in terms of a new DNS RR type:
>>
>> example.com      DOTNS ns1.example.com
> There are interesting problems with using extra delegation records to
> bootstrap DoT:
>
> The DNS protocol has to have special logic for every RRtype that appears
> at a delegation, so you would need some kind of signalling to indicate
> that this is OK for all the parties involved. (I have not thought about
> the details of what would be required...)
I'm curious about this.   I thought all of the logic required was on the 
server end.
> You also need to upgrade EPP so that registrars can get the extra records
> into the registry database so that the registry can put them in the TLD.

Ah, that makes sense.

But I've been convinced for at least 20 years that the DNS protocol 
needed an upgrade path anyway, and that having new kinds of "NS" records 
was the only good way to do it.   So to me the effort required to add 
support for new delegation records seems like a necessary investment.

> And then wait an indefinite time for the registrars to upgrade their
> customer-facing interfaces so that you can tell them about the extra
> records.

Yes, this is a given.   One of the big problems with the 
registry-registrar model is that registrars get too much latitude about 
their customer interfaces.

Keith