Re: [ietf-smtp] starttls-everywhere

keld@keldix.com Sun, 31 March 2019 20:15 UTC

Return-Path: <keld@open-std.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 346E7120222 for <ietf-smtp@ietfa.amsl.com>; Sun, 31 Mar 2019 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Hekpcs4F-EOt for <ietf-smtp@ietfa.amsl.com>; Sun, 31 Mar 2019 13:15:05 -0700 (PDT)
Received: from www.open-std.org (open-std.org [93.90.116.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A1F12021E for <ietf-smtp@ietf.org>; Sun, 31 Mar 2019 13:15:03 -0700 (PDT)
Received: by www.open-std.org (Postfix, from userid 500) id 132DA358ADF; Sun, 31 Mar 2019 22:15:00 +0200 (CEST)
Date: Sun, 31 Mar 2019 22:14:59 +0200
From: keld@keldix.com
To: Jeremy Harris <jgh@wizmail.org>, ietf-smtp@ietf.org
Message-ID: <20190331201459.GB4408@www5.open-std.org>
References: <74074d25-26b0-e597-c05d-62b6b5902a7c@wizmail.org> <20190331113321.GA13658@www5.open-std.org> <20190331191653.GA5690@osmium.pennocktech.home.arpa>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190331191653.GA5690@osmium.pennocktech.home.arpa>
User-Agent: Mutt/1.4.2.2i
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/DtmTdp6wGHZUlb_gYA81MQIDY7k>
Subject: Re: [ietf-smtp] starttls-everywhere
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, 31 Mar 2019 20:15:12 -0000

in my mind that is not a good way forward,
I thnk it will break up email as an internet service.
I would much rather go the upwards compatible path,
like we did for smtp/esmtp which I think has been very succcsful. 

The esmtp transition has been so successful because we designed 
it to be so, and nobody was hurt. Transition to starttls has been very successful
also because it was designed to be smooth. Please don't break email!

keld

n Sun, Mar 31, 2019 at 03:16:53PM -0400, Phil Pennock wrote:
> On 2019-03-31 at 13:33 +0200, keld@keldix.com wrote:
> > is it no the best way to do itnow
> > 
> > something like 95 % of my connections nowadays are tls, but most of
> > the connections are with certificates that do no validate.
> > temporary and the like.
> > 
> > would going to enforcing not invalidate all these connections?
> > and the fallback to non-encrypted smtp? shooting yourself in the foot...
> 
> No: the point of the STARTTLS-Everywhere system is that, like both DANE
> and MTA-STS, the sender does _not_ fall back to unencrypted SMTP.
> 
> Except in Testing mode.  Which is what Jeremy is explicitly asking
> about: moving from "hint, but can still fall back" to "enforce, with no
> fall back".
> 
> -Phil