Deployment strategy for email+ Was: Mail is worse than everything except...
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 13 May 2022 16:28 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B0AC14F743 for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 09:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.393
X-Spam-Level:
X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
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 AD87D2QGhVBT for <ietf@ietfa.amsl.com>; Fri, 13 May 2022 09:28:22 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 A803EC15EB27 for <ietf@ietf.org>; Fri, 13 May 2022 09:28:02 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id i11so16153700ybq.9 for <ietf@ietf.org>; Fri, 13 May 2022 09:28:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JwzM4SqZ3f6qE6bc/02XkeO+9sIQerEiHxcv2VYEwbc=; b=5xIXY8gZ7TxLKF3Lr4k2TZb6jC0cD5914C6h5OZ3AUAYJd5+Og3yR69bTvGIst58qM U4+eL1i0ABlpeAygrB5jvgfrgNGRh0f3odPDWNs7iyF4HJIs5DjzvXAALRZ4KPRRWnTD oy+OAryUBTt2sS3ZUyUWoxhDvOXQ7cU2ecDJcZm5Dgtb6JtFmtbGdHs7DS8nsY7Iwaj2 6y+E+Z5qk+EuPdjyNzTMdrxs3bWh+EahAwkzQbSupKmB9arv3twWRolAFRe/LBNay1Ei UYb4hZiU2Rmb/C6EWlnFa/gRKx/2eb2y748N4zu2XGh0RZNgaDK0yZGJfdOuy7dWGPf+ D/Lw==
X-Gm-Message-State: AOAM532YbhGIlndJZoAZqoMKc0TRYOoM9ItxnZzLzSefv26DLKZC1xxN O8YSbWFH+rfbWAZFqD+iSYL0VP9biSL48vfIBA/0R3CI
X-Google-Smtp-Source: ABdhPJyhZdfk1dMMmoPTrZXMI4Zi57HUtUV0HvDReUr9mXjsjtd9xlW6Fm0H4vmJ27iutVyxt0UXO4NoATaplcY6Q/I=
X-Received: by 2002:a25:d314:0:b0:649:1be0:505e with SMTP id e20-20020a25d314000000b006491be0505emr5476897ybf.501.1652459281704; Fri, 13 May 2022 09:28:01 -0700 (PDT)
MIME-Version: 1.0
References: <20220428221138.9BFD63F11488@ary.qy> <e11aeebf-22f6-b067-db4f-ea84fe41abc5@network-heretics.com> <CAMm+Lwj7ZZn_enfkfMgLiSRaQbyEi6pBwoEdkdppA-=eOt8RRQ@mail.gmail.com> <f2856072-7c03-cf1f-9ee4-f48d84290f6c@taugh.com>
In-Reply-To: <f2856072-7c03-cf1f-9ee4-f48d84290f6c@taugh.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 13 May 2022 12:27:49 -0400
Message-ID: <CAMm+LwgtH=2G8VbdDeUWRO9KtZxByqmjW=Wh1JVvux9_zU2K1w@mail.gmail.com>
Subject: Deployment strategy for email+ Was: Mail is worse than everything except...
To: John R Levine <johnl@taugh.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007deea905dee72897"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ui5hQOkPALG2rHUAj_T16i5LH94>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 16:28:24 -0000
On Fri, Apr 29, 2022 at 11:20 PM John R Levine <johnl@taugh.com> wrote: > > It will certainly be an unpopular thing to say but I will say it: > Protocols > > wear out over time. > > In principle I wouldn't disagree, but in practice I don't see how we > migrate from SMTP to SMTP++ or whatever. > The devil is in the deployment. That is why I have always had a deployment plan and designed for deployment. First: The Web succeeded, every other network hypertext scheme failed. Tim Berners-Lee knew what he was doing, he calculated his moves. I watched him and I am copying the same approach. At this point, I have running code: Demo Reel - YouTube <https://www.youtube.com/playlist?list=PLK2hHAOxepEgZtTxX3BtkPUDIJ3--_FAu> https://www.youtube.com/playlist?list=PLK2hHAOxepEgZtTxX3BtkPUDIJ3--_FAu It is not a replacement for SMTP at this point. It does contain a messaging system but that is limited to messages of 32 KB. It does not compete with SMTP or even SMTP+S/MIME. It is a secure messaging layer for supporting asynchronous workflow interactions. That is something which has value in the enterprise as a basis for automating clerical processes. One big failure in the IETF way of doing things is to limit the scope so the deliverable doesn't come close to being a minimum viable product. Another is that discussion of the UI is out of scope. Both doom efforts to fail. The Mesh is not a vast amount of code, in fact the code base has shrunk considerably over the past three years. But the functionality is now comprehensive. Mesh users currently get: * An end-to-end secure password vault. * A contacts directory that automatically updates. * A means to secure data at rest and easily share it with their co-workers. * Management of keys and credentials over all their user and IoT devices. * End to end secure sharing of bookmarks, network configs, application credentials across devices. * Provisioning of OpenPGP and S/MIME keys. * A 2FA replacement that is better than anything on the market today. I am currently working on adding: * The ability to create life-long callsigns that do not expire and do not require 'rent'. * An end to end secure messaging client with text, voice and video modalities. * A GUI management tool to replace the linemode. * A Web browser that has the bookmark and password management integrated. My profound gratitude to the folk at Microsoft whose .NET7, MAUI and WebView2 platforms enable me to produce demoware that is close to production quality in a remarkably short space of time. The first iteration of the Web Browser took less than a day and the skeleton was up in under an hour. The big difference between my work and others in the industry is that I have no shareholders. I am not building a walled garden designed to acquire a group of users and bind them to my service. Mesh accounts are fully portable. There are no switching costs. If Alice decides she is fed up with service from Mathmesh.com, she can move to a rival and take all her data with her. The contact details and forwarding addresses all update automatically. You know as well as anyone that for decades people have been saying e-mail > is dead, everyone uses X instead, but the X keeps changing and e-mail is > still around. > And here is how I plan to unthrone SMTP. First get people to make use of my contacts book to exchange signed context assertions which can include the credentials required to establish end-to-end secure communications by means of any messaging, chat, mail etc protocol. So your Skype, Signal, WhatsApp, SMTP, OpenPGP, SSH, S/MIME etc contact info can all be presented in a contact. [NB, this email is going to be too long as it is without folk quibbling about whatifs. Yes Alice can create separate contacts so she only exposes her email address and phone number to a select number of important contacts.] Alice and Bob can exchange contact information in various ways. They can do so directly if they meet in person and bump phones. There used to be a wonderful app for that until Yahoo bought it up and shuttered it. Yes, iPhones can bump to iPhones via airdrop but that is a walled garden. Alternatively Alice can put a QR code on her business card and Bob can scan it. Alice can send Bob an email with a link. Support for cases where Alice and Bob interact directly is relatively straightforward. But for cases where there is an employer, I need PKIX style capabilities. And for cases where Bob is going to get Alice's contact information from Carol, I need a really short, really easy to use identifier with the absolute minimum of clutter. Which is where my callsign registry comes in. This allows Carol to tell Bob to contact @alice. So at this point, if everyone is using my contacts book, the conditions have been created that make the emergence of SMTP+ inevitable. Because Alice's contact details will contain both her RFC822 SMTP address and the contact details for email+. The way I see email+ initially getting traction is within enterprises. 80% of the employees in most large enterprises have little or no email interaction with external users in an enterprise setting. So having one email protocol for internal emails and a separate protocol for external communications is entirely practical. In fact this is already the case with Outlook and Exchange. Adding an extra protocol handler to Outlook and Thunderbird is actually pretty straightforward. Once the switching costs for deploying a new email protocol are addressed, the only thing we need to add is some advantage for the new scheme. This is really not a problem. Mesh Messaging is limited to 32KB but messages can contain a link to an attachment of any size. So while I don't have code yet, I know what advantages Mesh Mail can provide: * Every mail is signed, no spam impersonating the ceo * Every mail is end-to-end encrypted * Every mail is subject to access control, no spam from unauthorized parties * Mail messages can be of any size because large messages are pulled, not pushed. * Mail messages integrate into workflow. If this type of open, mail messaging scheme gains ground inside enterprises, it will start being used between enterprises as well. Seems worth a shot. PHB
- Service outages planned for April 25 Robert Sparks
- Re: Service outages planned for April 25 Robert Sparks
- Re: Service outages planned for April 25 tom petch
- Re: Service outages planned for April 25 Jay Daley
- Re: Service outages planned for April 25 Keith Moore
- Re: Service outages planned for April 25 Carsten Bormann
- Re: Service outages planned for April 25 Keith Moore
- Re: Service outages planned for April 25 Carsten Bormann
- Re: Service outages planned for April 25 Keith Moore
- Email and reputation (was Re: Service outages pla… Vittorio Bertola
- Re: Email and reputation (was Re: Service outages… Keith Moore
- Re: Mail is worse than everything except all the … John Levine
- Re: the introduction problem, was Email and reput… John Levine
- Re: Mail is worse than everything except all the … Keith Moore
- Re: Mail is worse than everything except all the … Phillip Hallam-Baker
- Re: Mail is worse than everything except all the … Keith Moore
- Re: Mail is worse than everything except all the … John R Levine
- Re: Mail is worse than everything except all the … Keith Moore
- Re: Mail is worse than everything except all the … touch@strayalpha.com
- Re: Mail is worse than everything except all the … Keith Moore
- Re: Mail is worse than everything except all the … Viktor Dukhovni
- Re: Mail is worse than everything except all the … Keith Moore
- Re: Mail is worse than everything except all the … touch@strayalpha.com
- Re: Mail is worse than everything except all the … Keith Moore
- Re: the introduction problem, was Email and reput… Vittorio Bertola
- Re: the introduction problem, was Email and reput… John R Levine
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Viktor Dukhovni
- Re: the introduction problem, was Email and reput… Christian Huitema
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Viktor Dukhovni
- Re: the introduction problem, was Email and reput… Masataka Ohta
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Masataka Ohta
- Re: the introduction problem, was Email and reput… Viktor Dukhovni
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Michael Richardson
- Re: the introduction problem, was Email and reput… Laurence Lundblade
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… John Levine
- Re: the introduction problem, was Email and reput… Lyndon Nerenberg (VE7TFX/VE6BBM)
- Re: mail crypto, was the introduction problem, wa… John Levine
- Re: mail crypto, was the introduction problem, wa… Keith Moore
- Re: mail crypto, was the introduction problem, wa… Christopher Morrow
- Re: mail crypto, was the introduction problem, wa… Keith Moore
- Re: mail crypto, was the introduction problem, wa… John Levine
- Re: mail crypto, was the introduction problem, wa… Keith Moore
- Re: mail crypto, was the introduction problem, wa… Christopher Morrow
- Re: mail crypto, was the introduction problem, wa… Keith Moore
- Deployment strategy for email+ Was: Mail is worse… Phillip Hallam-Baker
- Re: mail crypto, was the introduction problem, wa… Phillip Hallam-Baker
- Re: the introduction problem, was Email and reput… Phillip Hallam-Baker
- Re: the introduction problem, was Email and reput… Phillip Hallam-Baker
- Re: the introduction problem, was Email and reput… John Levine
- Re: the introduction problem, was Email and reput… Keith Moore
- Re: the introduction problem, was Email and reput… Phillip Hallam-Baker
- Re: the introduction problem, was Email and reput… John R Levine
- Re: the introduction problem, was Email and reput… Phillip Hallam-Baker
- Re: the introduction problem, was Email and reput… Masataka Ohta
- Re: the introduction problem, was Email and reput… Masataka Ohta
- Trying to do too much (was Re: the introduction p… Jim Fenton
- Re: Trying to do too much (was Re: the introducti… lloyd.wood@yahoo.co.uk
- Re: Trying to do too much (was Re: the introducti… Phillip Hallam-Baker
- Re: Trying to do too much (was Re: the introducti… Keith Moore
- Re: Trying to do too much (was Re: the introducti… Keith Moore
- Re: Trying to do too much (was Re: the introducti… Michael Richardson
- Re: Trying to do too much (was Re: the introducti… Masataka Ohta
- Re: Trying to do too much (was Re: the introducti… Masataka Ohta
- Re: potable e-mail, now Trying to do too much (wa… John Levine
- Re: Trying to do too much (was Re: the introducti… Phillip Hallam-Baker
- Re: Trying to do too much (was Re: the introducti… Phillip Hallam-Baker
- Re: potable e-mail, now Trying to do too much (wa… Michael Richardson
- Re: Trying to do too much (was Re: the introducti… Keith Moore
- Re: portable e-mail, now Trying to do too much (w… John R Levine
- Re: potable e-mail, now Trying to do too much (wa… Keith Moore
- Re: Trying to do too much (was Re: the introducti… Masataka Ohta
- Re: potable e-mail, now Trying to do too much (wa… Masataka Ohta
- Re: portable e-mail, now Trying to do too much (w… Michael Richardson
- Re: portable e-mail, now Trying to do too much (w… John Levine
- Re: portable e-mail, now Trying to do too much (w… Michael Richardson
- We are not a mail forwarding service Carsten Bormann
- Re: We are not a mail forwarding service John R Levine
- ugly hacks (was: Re: We are not a mail forwarding… Keith Moore
- Re: ugly hacks (was: Re: We are not a mail forwar… John Levine
- Re: ugly hacks (was: Re: We are not a mail forwar… Keith Moore
- Re: We are not a mail forwarding service Robert Sparks
- Re: We are not a mail forwarding service Carsten Bormann
- Re: portable e-mail, now Trying to do too much (w… Phillip Hallam-Baker
- Re: potable e-mail, now Trying to do too much (wa… Phillip Hallam-Baker
- Re: portable e-mail, now Trying to do too much (w… Keith Moore
- Re: portable e-mail, now Trying to do too much (w… Phillip Hallam-Baker