[Endymail] Restart Endymail to discuss the Mathematical Mesh?
Phillip Hallam-Baker <phill@hallambaker.com> Sun, 07 April 2019 17:23 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923121202C4 for <endymail@ietfa.amsl.com>; Sun, 7 Apr 2019 10:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no 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 YSyFKkdpUqYd for <endymail@ietfa.amsl.com>; Sun, 7 Apr 2019 10:23:18 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8174120333 for <endymail@ietf.org>; Sun, 7 Apr 2019 10:23:17 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id m10so9941930otp.2 for <endymail@ietf.org>; Sun, 07 Apr 2019 10:23:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+KgKAz7OxmL8ppgXnRXWPjNIFb2j3HeBc/wBsUdD37w=; b=TwcsCabnxl1Ue+ILchsMxxB6w6ohPdSf6iNdN7NlwDhccvENPRd33B1lM2+99BzoVo 2NIN2NDx2xgFPWOLQA0LNJswTySyHBdZt6MeQzN07UsYxcQzAY1Evkvd3Kttb2rCGDBw goJNm+WD5vBlIvJw4Zk7iKeDM91Kdz072yfMJuArL/vf63X6oun1h1Zfm1pggfJEhVvj pHx/YlwCxvVGXtPJdlpWRy9wXXl2p0jEd2ssC1VXQ+UDkQVoJsQrf+jtfMeuBuwwRfNI ZQW/xOI8dG5ITRc1CGGr1MF7fNfLncE7Af89F6aUIPpJ6jjp4rF9DAE6cYZimHBXA0ny PbVA==
X-Gm-Message-State: APjAAAXAarqgGqA0Gx/hZbG6x22RAmW/qhr+H4/tfh/In3GFkUSnlf0i gsgJ8D6P579jE6+WxH91P8x3s22EnPKkJnRUIHt3Yg==
X-Google-Smtp-Source: APXvYqypHqWxqYEVmllEZ1kVq7wq+ZZ3eBrGW/zt2Ie4vwgIUD3UqGjppHXHFaqqvMKaQ5Qw9vPGSlS8N+bAVj03x/Y=
X-Received: by 2002:a9d:550d:: with SMTP id l13mr16124114oth.173.1554657796521; Sun, 07 Apr 2019 10:23:16 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 07 Apr 2019 13:23:07 -0400
Message-ID: <CAMm+LwhjPF8QqJ41HQ4__2_KnZZXfmJ_55X2HtrhyTz=i=8j=A@mail.gmail.com>
To: endymail <endymail@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b5846e0585f3f93f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/endymail/8Z-6dlVnnF5OR8PxsuaxO4ClQXk>
Subject: [Endymail] Restart Endymail to discuss the Mathematical Mesh?
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2019 17:23:21 -0000
OK so I have a very comprehensive end-to-end secure messaging protocol that is capable of supporting end-to-end secure mailing lists as well as many other advanced crypto features. Micali fair contracts anyone? I don't propose this as a replacement for SMTP today or tomorrow. That would be silly. But there are many applications that SMTP is horrible for: * Large messages (video files as attachments) * Secure by default * Spam 80% of the emails I sent and received at Comodo and Verisign were internal and we were all required to use Outlook An email system that is only for internal use and required a plug in would be entirely acceptable provided that it was zero-effort secure. If the protocol was adopted by a major email client provider and was in the base version of the client, we might get to a point where the enterprise and its lawyers and accountants all used the Mesh Messaging protocols. So now we can extend the security envelope to 90% of the emails we are concerned with. OK, so I want to transfer 100GB, 2TB files with an email protocol. To do that I need to switch to a Pull protocol for obvious reasons. Which means that my control messages can be very small because all they need to contain is the stuff normally seen in SMTP headers and a link to where the larger messages are. So I am currently working with a hard limit of 64 Kilobytes on messages. If you want to send a longer message, send it as a detachment. Keep the control channel clear, lean and mean. One consequence of this is that I can impose a hard limit on Mesh Service transaction size and time. If I insist that a Mesh Service be on a 10MB/s link or better, any transaction that takes more than 5 seconds to complete can probably be dropped without impact on the user. Either the source or the destination is overloaded or the message itself is some sort of DoS attack. Thoughts?
- [Endymail] Restart Endymail to discuss the Mathem… Phillip Hallam-Baker
- Re: [Endymail] Restart Endymail to discuss the Ma… Jeremy Harris
- Re: [Endymail] Restart Endymail to discuss the Ma… Tom Mitchell
- Re: [Endymail] Restart Endymail to discuss the Ma… John R. Levine
- Re: [Endymail] Restart Endymail to discuss the Ma… Phillip Hallam-Baker
- Re: [Endymail] Restart Endymail to discuss the Ma… Steven M. Bellovin
- Re: [Endymail] Restart Endymail to discuss the Ma… Phillip Hallam-Baker
- Re: [Endymail] Restart Endymail to discuss the Ma… Mark Rousell
- Re: [Endymail] Restart Endymail to discuss the Ma… Phillip Hallam-Baker
- Re: [Endymail] Restart Endymail to discuss the Ma… Mark Rousell