From nobody Sun Apr 7 10:23:29 2019 Return-Path: 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 ; 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 ; 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 ; Sun, 7 Apr 2019 10:23:17 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id m10so9941930otp.2 for ; 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 Date: Sun, 7 Apr 2019 13:23:07 -0400 Message-ID: To: endymail Content-Type: multipart/alternative; boundary="000000000000b5846e0585f3f93f" Archived-At: Subject: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 17:23:21 -0000 --000000000000b5846e0585f3f93f Content-Type: text/plain; charset="UTF-8" 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? --000000000000b5846e0585f3f93f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 othe= r advanced crypto features. Micali fair contracts anyone?

I don't propose this as a replacemen= t for SMTP today or tomorrow. That would be silly. But there are many appli= cations that SMTP is horrible for:

* Large messages (video files as attachments)
* Secure by default
* Spam

80% of the emails I sent and received at Comod= o and Verisign were internal and we were all required to use Outlook An ema= il system that is only for internal use and required a plug in would be ent= irely acceptable provided that it was zero-effort secure.=C2=A0

If the protocol was adopted by a maj= or email client provider and was in the base version of the client, we migh= t get to a point where the enterprise and its lawyers and accountants all u= sed the Mesh Messaging protocols. So now we can extend the security envelop= e to 90% of the emails we are concerned with.

OK, so I want to transfer 100GB, 2TB files with an ema= il protocol. To do that I need to switch to a Pull protocol for obvious rea= sons. Which means that my control messages can be very small because all th= ey 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 messa= ges. If you want to send a longer message, send it as a detachment. Keep th= e 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?=

--000000000000b5846e0585f3f93f-- From nobody Sun Apr 7 10:40:15 2019 Return-Path: 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 66FA5120337 for ; Sun, 7 Apr 2019 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org 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 Lwc4O8b57Vy7 for ; Sun, 7 Apr 2019 10:40:12 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 8920012008F for ; Sun, 7 Apr 2019 10:40:12 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1554658812; b=miysFMIX0xNc0Bd/nQOMSJ/Co17mF5ns7LbKDbD2vatZBKSOeB4zVFXBfucavyYEN5GCpowkhy d4O2i04vIu9RuV92zm4FCRzwX1cQaxulPYtd8k2sVe40o9GF632Q1vfd4kC2FGrowJIX5xb/4F rH7mUqD4Ga2FYqU/V0qbfAQ=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1554658812; bh=iZXKqQKTPzpqcLGERlx3aYOXZPKFdJGPhtsy2F4Ilj0=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=Tlwx6v9BoFglu50Z86clkVzbc6gqmDQS1WpNAxR9dr2By/SrgC8WxZChiEdU6BP+WdxB59hUxN M+bvyQ2VVVrQ1RcbEHWgd3yvdiJe9yYe2xG/ot/EJiUZFMKW/uq4NJgCQMoDrOqbd4F1jOrQa4 VhwaGe9Z5FhyrycUw4RJF34=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=JsxYAkRfJ+FazkYQdExn/ypkFOqVxKNTPSvWSblllmo=; b=E ELeqmz+dSa8NaqhDH5M0k9ZHHB7297MIsHVZCEyibnhl0XJhTi+f9JYgEp/w8d+vwLJ2woVRPKO30 04UuLG9G5faxv/BTNTgycErzgD3azBDbQB+Qi6FaqRj5EV6CdW38TiUItuSKmf7XPn2ZPQoZ8t5e7 fVm7isty6/eobku8=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.92.106) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1hDBm6-0006DD-9m for endymail@ietf.org (return-path ); Sun, 07 Apr 2019 17:40:10 +0000 To: endymail@ietf.org References: From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <5911d78d-a9de-90f7-bbeb-2eb4f565f84b@wizmail.org> Date: Sun, 7 Apr 2019 18:40:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 17:40:14 -0000 On 07/04/2019 18:23, Phillip Hallam-Baker wrote: > 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? I think that disenfranchises anyone on a basic DSL, plus three-quarters of the African continent's rural population? -- Cheers, Jeremy From nobody Sun Apr 7 12:49:47 2019 Return-Path: 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 F25AE1201BC for ; Sun, 7 Apr 2019 12:49:44 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=niftyegg-com.20150623.gappssmtp.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 RCV9KaDol0ql for ; Sun, 7 Apr 2019 12:49:42 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 EEF6A1200D6 for ; Sun, 7 Apr 2019 12:49:41 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id f6so9248153iop.3 for ; Sun, 07 Apr 2019 12:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niftyegg-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FIjzgyk/R3osrMp7js9rDHMnO4HtgV0PEhfmXWnUSfU=; b=o097bu9ngX65SH/sLj07CgSNHtP6QhVIOFwjP+67hywyWKPACNVlWlE5lJr0TlzKGC GLWwajECrONKDgKtjvYYHOhITz/x8Uu5EPdeGnBz2DqxPmRO4Fp1/tiAyw3fgqs86qXl YP1mub2LzLyMMyCyUrOl1kT+ecajZQwfbBAslbKiqbRVdcGEB5lZNV5Znog2mqOlKBWY qUYSo4QOLd6YDbd85xGRU5X+1frT7GHp47SO6y9eNhNIYsbi3XCCmY5CqyYtdMUXuAow 0wESdIVnqVugna6LnhD5lup7pj3ey8llQevIJYvliAYjg3NNIWtbgRgFci3E95/2uZB1 AiPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FIjzgyk/R3osrMp7js9rDHMnO4HtgV0PEhfmXWnUSfU=; b=N7OlDAmvLBeffcwMQN4f2daT24GzYG0vpwMmq62ZvydKgYIM6uV76oZcHT4rWfYKFm RBiX4H/nLMRK/Rvztz2lGk7/NtTYUVDJvr7sAF/bgq7A17jSJvP2f5qwJG6VRdjIPUjM Wot0r3rPg0oUIYNq4ZmyEKoAQkizy2QL4CllzZxtEatGiYhcmyOc58zfDehHjnWBSgJS FHXj5Rq4yjZ401awweYiaqnz+TIBRoanZrmD2/rJEunVyHEIUyeWYLrx1pgMc4XWwv3e e/2imwzz5kZGdCr9l++7zhS/JiUQmDaNb3qnRvXDBRda6dGJvv+K1FeE+WH66aeD/9l2 5fQA== X-Gm-Message-State: APjAAAUc0DfjVBN2iVFrLfU0k5vZGfX+Y0bjxsITvJO+qcbo+AfkgR3o qwG086JTv/b3NSas293Ml4VavEm5WbnQEld6eCWjpq5OYIw= X-Google-Smtp-Source: APXvYqxCPX+1S3Kx/gkWlXEI9lKuFzQ9VsQbstKbt+PWcO6JdPdPMz/vJ4rtSKMxDEb4O8zdnfswwZbwWoXmew0xkBs= X-Received: by 2002:a6b:4a09:: with SMTP id w9mr17094063iob.79.1554666580801; Sun, 07 Apr 2019 12:49:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Mitchell Date: Sun, 7 Apr 2019 12:49:04 -0700 Message-ID: To: Phillip Hallam-Baker Cc: endymail Content-Type: multipart/alternative; boundary="0000000000004b11f40585f60513" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 19:49:45 -0000 --0000000000004b11f40585f60513 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 7, 2019 at 10:23 AM Phillip Hallam-Baker wrote: > 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. > ..... > 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. > .... "Thoughts?".. I see a like option set already in Gmail. I can attach an object in line or add a link to it in their cloud. I can forward with or without attachments.. (Note images are special cases, marketing?). Gmail has total message size limits by default, pick one. References can almost any size. URIs outside of Google are possible. I get warnings when I reply to someone not in my organization or address book. The attachment link can have partial or full credentials to open up an identity exchange even an access authorization token for the object. Encryption and cryptographic class hashes are possible. See Google Drive features. It solves data duplication. It leverages a central corporate repository strategy that can block external transfers and audit access. A central resource is not prohibited from watermarking fetched documents much the way color printers add yellow dots, more inventive tricks are possible. It permits all messages and parts to be a document (attachment) and separates the to/from/date/host(s) meta data from the data. So all attachments even the text itself can require a fetch from the central server a bit like tiny, small, medium and large beacon (pay per eyeball) images in todays email. Each object can have its own fetch, see, save, download policy. Gmail does have trouble with composing "PURE" text as kernel.org rules require (sort of sux). http://vger.kernel.org/majordomo-info.html must be TEXT/PLAIN, there can be no multipart messages, no VCARDs, nothing ``fancy''. SMTP is store and forward but inside the system direct connection to a central server resource seems possible (eggs in one basket disclaimer). Store and forward has MX record hooks today that are possibly necessary to traverse firewalls including internal ones. Data retention policy on a central server could be enforced for good and bad. Data access can have a timer features enforced at the server. Encryption of data at rest is possible is encryption of each component. Address books can contain public keys so content by reference can be encrypted with the public key of each recipient when fetched. Server latency and availability may be an issue. Lost keys are a monster issue but the server has the master data and need not retain my encrypted copy. So sure. It is important to have a policy for "external" communications so the only mail tool anyone needs is the enhanced one. My #1 feature compete requirement is $EDITOR. vi, vim, ed, edit, emacs, MStools. Character sets, and language tags... -- T o m M i t c h e l l --0000000000004b11f40585f60513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Apr 7, 2019 at 10:23 AM Phillip H= allam-Baker <phill@hallambaker.= com> wrote:
OK so I have a very comp= rehensive end-to-end secure messaging protocol that is capable of supportin= g end-to-end secure mailing lists as well as many other advanced crypto fea= tures. Micali fair contracts anyone?
I don't propose this as a replac= ement for SMTP today or tomorrow.
.....=C2=A0=
80% of the emails I sent and received at Comod= o and Verisign were internal and we were all required to use Outlook An ema= il system that is only for internal use and required a plug in would be ent= irely acceptable provided that it was zero-effort secure.=C2=A0
=
.... "Thoughts?"..=C2=A0
=C2=A0
I = see a like option set already in Gmail.

I can attach an object in li= ne or add a link to it in their cloud.
I can forward with or without att= achments.. (Note images are special cases, marketing?).
Gmail has total = message size limits by default, pick one.=C2=A0 References can almost any s= ize.=C2=A0
URIs outside of Google are possible.=C2=A0
I get warnings = when I reply to someone not in my organization or address book.
The atta= chment link can have partial or full credentials to open up an identity exc= hange
even an access authorization token for the object.=C2=A0 Encrypti= on and cryptographic
class hashes are possible.=C2=A0 See Google Drive f= eatures.=C2=A0

It solves data duplication.
It leverages a central= corporate repository strategy that can block external transfers and audit = access.
A central resource is not prohibited from watermarking fetched d= ocuments much the way color printers=C2=A0
add yellow dots, more inventi= ve tricks are possible.=C2=A0
It permits all messages and parts to be a = document (attachment) and separates the to/from/date/host(s) meta data
f= rom the data. So all attachments even the text itself can require a fetch f= rom the central server a bit
like tiny, small, medium and large beacon (= pay per eyeball)=C2=A0 images in todays email.=C2=A0 Each object can have i= ts own
fetch, see, save, download policy.

Gmail does have trouble= with composing "PURE" text as kern= el.org rules require (sort of sux).=C2=A0
http://vger.kernel.org/majordomo-info.html=
=C2= =A0must be TEXT/PLAIN, there can be no multipart messages, no VCARDs= , nothing ``fancy''.

SMTP is store and forward but inside th= e system direct connection to a central server
resource seems possible (= eggs in one basket disclaimer). Store and forward has MX record hooks
to= day that are possibly necessary to traverse firewalls including internal on= es.=C2=A0

Data retention policy on a central server could be enforce= d for good and bad.

Data access can have a timer features enforced a= t the server.=C2=A0=C2=A0

Encryption of data at rest is possible is = encryption of each component.

Address books can contain public keys = so content by reference can be=C2=A0
encrypted with the public key of ea= ch recipient when fetched.=C2=A0 Server latency
and availability may be = an issue. Lost keys are a monster issue but the server
has the master da= ta and need not retain my encrypted copy.=C2=A0

So sure.
It is im= portant to have a policy for "external" communications so the onl= y mail tool
anyone needs is the enhanced one.=C2=A0 My #1 feature compet= e requirement is $EDITOR.
vi, vim, ed, edit, emacs, MStools.=C2=A0 =C2= =A0Character sets, and language tags...



--
=
=C2=A0 =C2=A0T o m =C2= =A0 =C2=A0M i t c h e l l
--0000000000004b11f40585f60513-- From nobody Sun Apr 7 13:26:11 2019 Return-Path: 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 6973F12007C for ; Sun, 7 Apr 2019 13:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 uwVfXR_6aoz3 for ; Sun, 7 Apr 2019 13:26:09 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 ACF4412007A for ; Sun, 7 Apr 2019 13:26:08 -0700 (PDT) Received: (qmail 56141 invoked from network); 7 Apr 2019 20:26:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=db44.5caa5cdd.k1904; bh=W/QVqCpQJaKK1P5vu3FDZkyWa1TrdtN+IbbZQqesQro=; b=vhxJpp9cst8WTPdHLWbstrcjbA/AZKAH3HZpyB8eV3pAuHGL56nUv/wMC2JzbQmCL8770Y27qPBHS8V9izl9v/scYbh53ga/Ci9UJMrp5pK7q+b5AeALt/dwhXGny1kU7Kf7sJAqJB+Ubs3pi5b+OCBZD7QeCO6gWG+dMeLbhrprJTnvXH0f3wNMxPGrOrO3KXinvidz4uXd+vnVccQquw+2HVdqsTc+Ux0mTNVElXrhuSjwdpTN4ybMQ4U7vPHz Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Apr 2019 20:26:05 -0000 Date: 7 Apr 2019 16:26:05 -0400 Message-ID: From: "John R. Levine" To: "Tom Mitchell" Cc: "Phillip Hallam-Baker" , "endymail" In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 20:26:10 -0000 > I see a like option set already in Gmail. > > I can attach an object in line or add a link to it in their cloud. We've had message/external-body for over 20 years. See RFC 2017. I realize it's not implemented all that widely but it's there if anyone wants it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Apr 7 15:22:48 2019 Return-Path: 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 DFD23120126 for ; Sun, 7 Apr 2019 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 JXWn5fJuLcIW for ; Sun, 7 Apr 2019 15:22:44 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 3B2D512011E for ; Sun, 7 Apr 2019 15:22:44 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id n187so8978900oih.6 for ; Sun, 07 Apr 2019 15:22:44 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kCej3Pe29+GJgpB1ViYmMsnoQhJHq+2r5RJO0ZRFdYg=; b=Ly1TVz5aGGAoW8UgN1sTSg9Vxu2aVSXE8QlBkBQZC/THoDZRqSZr4+UI8+AZMgOQPt 6/nAx26nN7aMwRwVF/e+q3wwnbrAtACbHmzZbTIU5Z+iM5oFrbDMWVhYycIg/bOLahWS m3dCRnJsaUhaPLAXPQew4uOaxmZBtiLmKF8zE5Bvo2WowPkCZEQWPoskpxE0J9zuEW92 rMUBQtIDM0U5MPjHD5I7p6CI2kvOMS/ad2mfRPTl64NZl27sLsW0lbtugAWNcgd7HP7p vhwLX/a8VUti4h0QD78CINiaPTKwQPpeZ5JDABgpHrixaHwUmbr5xqyl0edpQiD3uqSD KWkQ== X-Gm-Message-State: APjAAAW3Jt7i9PxhFLZP1YKAvbOOmmFaETR97WlMmLhKpkCEECIyJV+b geMJjcDqKYIuVwKefohuHMFrCXyaU0tD0wFg3ag= X-Google-Smtp-Source: APXvYqzEpPFI1CLeCCHmEsFzIpEINJWgW1vq+bJLidgRQHdiy0cnyModwoqWCRkb53D3QLYVVNn5llt22rf+mJpGjmM= X-Received: by 2002:aca:5a89:: with SMTP id o131mr14904920oib.17.1554675762991; Sun, 07 Apr 2019 15:22:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Sun, 7 Apr 2019 18:22:32 -0400 Message-ID: To: "John R. Levine" Cc: Tom Mitchell , endymail Content-Type: multipart/alternative; boundary="0000000000009816340585f8287a" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 22:22:46 -0000 --0000000000009816340585f8287a Content-Type: text/plain; charset="UTF-8" On Sun, Apr 7, 2019 at 4:26 PM John R. Levine wrote: > > I see a like option set already in Gmail. > > > > I can attach an object in line or add a link to it in their cloud. > > We've had message/external-body for over 20 years. See RFC 2017. > > I realize it's not implemented all that widely but it's there if anyone > wants it. > The aim of the Mesh was to start off with a completely green field approach ignoring all existing infrastructure to see what the system would then look like. Having done that, it is of course entirely reasonable to look at how we might retrofit the feature set to the existing mail infrastructure. And in fact that is one of the things that the Mesh helps with. I can use the Mesh to manage my S/MIME and OpenPGP keys across my devices and achieve zero-effort security. But this is also like building a high speed rail system and only using it to move the spare parts needed to keep Amtrack running. The other point here is that there is a big difference between use of detachments as an optional feature you can choose to implement and use and use of detachments as something you are absolutely forced to use because Mesh Messages are limited to 65535 bytes and the service won't accept them if they are 65536. Limiting the messages in the control channel means that a service should never end up being blocked because 16 different users are all receiving 10MB files at the same time. It also means that we can support really enormous files seamlessly - provided that the recipient actually wants the data. --0000000000009816340585f8287a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Apr 7, 2019 at 4:26 PM John R. Levine <johnl@iecc.com> wrote:
> = I see a like option set already in Gmail.
>
> I can attach an object in line or add a link to it in their cloud.

We've had message/external-body for over 20 years.=C2=A0 See RFC 2017.<= br>
I realize it's not implemented all that widely but it's there if an= yone
wants it.

The aim of the Mesh was to start off with a completely= green field approach ignoring all existing infrastructure to see what the = system would then look like.

Having done that, it is of course entirely reasonable to look at how we= might retrofit the feature set to the existing mail infrastructure. And in= fact that is one of the things that the Mesh helps with. I can use the Mes= h to manage my S/MIME and OpenPGP keys across my devices and achieve zero-e= ffort security.

But this = is also like building a high speed rail system and only using it to move th= e spare parts needed to keep Amtrack running.=C2=A0

The other point here is that there is a big diff= erence between use of detachments as an optional feature you can choose to = implement and use and use of detachments as something you are absolutely fo= rced to use because Mesh Messages are limited to 65535 bytes and the servic= e won't accept them if they are 65536.

Limiting the messages in the control channel means that a= service should never end up being blocked because 16 different users are a= ll receiving 10MB files at the same time. It also means that we can support= really enormous files seamlessly - provided that the recipient actually wa= nts the data.
--0000000000009816340585f8287a-- From nobody Mon Apr 8 11:32:06 2019 Return-Path: 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 94538120174 for ; Mon, 8 Apr 2019 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 XII_C8LpsnIl for ; Mon, 8 Apr 2019 11:32:02 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 E36E41200EC for ; Mon, 8 Apr 2019 11:32:01 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x38ISvX6043241; Mon, 8 Apr 2019 14:31:59 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 1FCCF80; Mon, 8 Apr 2019 14:31:59 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id 0B03980; Mon, 8 Apr 2019 14:31:59 -0400 (EDT) Received: from [10.216.42.96] ([150.108.242.86]) (user=smb2132 mech=PLAIN bits=0) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x38IVwTA034043 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Apr 2019 14:31:58 -0400 From: "Steven M. Bellovin" To: "Phillip Hallam-Baker" Cc: endymail Date: Mon, 08 Apr 2019 14:31:49 -0400 X-Mailer: MailMate (2.0BETAr6135) Message-ID: <2E619909-61A1-4DB6-B073-DA55958F38EE@cs.columbia.edu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.13 Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 18:32:04 -0000 Slightly off-topic, but folks on this list may be interested in https://www.cs.columbia.edu/~smb/papers/eurosys-2019-submission408-e3-fin= al-1.pdf. We plan to release the code as open source. From nobody Mon Apr 8 12:24:26 2019 Return-Path: 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 542F312032B for ; Mon, 8 Apr 2019 12:24:24 -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 MRIh9UW0Eff6 for ; Mon, 8 Apr 2019 12:24:23 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 0E61E120424 for ; Mon, 8 Apr 2019 12:24:23 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id t8so13276436otp.7 for ; Mon, 08 Apr 2019 12:24:23 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tiBO40rMTJ/yccdBbBu/D+byaeVzh/w2c0PZohjMfnc=; b=o87khw2U7cpgW3QQBAGUm62RnEjVXDcP01je9WalgvqsdKhKRYwmsRkfajoRJhgB3A 7dIG3rJ50yonjF8Fk1tZrNPIttBI8QKRm1UPasVEmB0QZs+/YkQFGyer1/cuBRwkXM32 IJj/8Sr15+c9eSv5yvwq8oOcN+RpgCOkkYyI36bn4QuDljwfLvDa2sxd1bjMGpcckuHH pi7aIPAX9uODRLrCOPqjxK0FNteku5AWK7dyb7y7FsDY8m4loCqX9Vh0JjTFNMrsGhM5 +O13AN20QG9anOEI0nPfaFOR1c3RDH64hIznlKRnnfTOIxEYH3N8Qekjmo3oLaPACaoI 2m0g== X-Gm-Message-State: APjAAAWzIte5r56sclAZP3Ev8jdDpaqoyxbhydezSDe3m8A8z41xW/1v O6gwyLt7LRlTG0qBWHC9ibKpo7QGRq2n8Wfb4Qs= X-Google-Smtp-Source: APXvYqxVYDT9LuSjy2MujyrP1J9TxMK4NrXuPObc5MeSEOG5+A/36C74/+mw6SGQBw5sXz4ewf4XJt15Vx7p4t3iX4c= X-Received: by 2002:a9d:550d:: with SMTP id l13mr20370736oth.173.1554751462286; Mon, 08 Apr 2019 12:24:22 -0700 (PDT) MIME-Version: 1.0 References: <2E619909-61A1-4DB6-B073-DA55958F38EE@cs.columbia.edu> In-Reply-To: <2E619909-61A1-4DB6-B073-DA55958F38EE@cs.columbia.edu> From: Phillip Hallam-Baker Date: Mon, 8 Apr 2019 15:24:11 -0400 Message-ID: To: "Steven M. Bellovin" Cc: endymail Content-Type: multipart/alternative; boundary="0000000000009faabf058609c843" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 19:24:24 -0000 --0000000000009faabf058609c843 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 8, 2019 at 2:32 PM Steven M. Bellovin wrote: > Slightly off-topic, but folks on this list may be interested in > > https://www.cs.columbia.edu/~smb/papers/eurosys-2019-submission408-e3-final-1.pdf > . > We plan to release the code as open source. > Looks interesting. I can see some clear convergence in mechanism. Though it is not clear to me how you are dealing with the per device keys. My approach is to split the decryption key. Which means I can add and remove devices etc. in no time at all. When I provision a new device, the administration device knows the private key for each of the applications I might provision to it. To add S/MIME capabilities, it splits the private key in two, sends one to the service and encrypts the other under the public key of the device. So the service only has a random number and the device can't decrypt without the device helping. The crypto is a scheme Matt Blaze and Torben Pederssen discovered. Depending on how you look at it, you can consider this to be Proxy Re-encryption or Distributed Key Generation. It is actually a simple case that sits at the intersection of both. --0000000000009faabf058609c843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2019 at 2:32 PM Steven M. Bellovin <smb@cs.columbia.edu> wrote:
Slightly off-topic, but folks on this list may be interested in<= br> https://www.cs.colu= mbia.edu/~smb/papers/eurosys-2019-submission408-e3-final-1.pdf.
We plan to release the code as open source.

=
Looks interesti= ng. I can see some clear convergence in mechanism. Though it is not clear t= o me how you are dealing with the per device keys.

My approach is to split the decryption key. Which= means I can add and remove devices etc. in no time at all. When I provisio= n a new device, the administration device knows the private key for each of= the applications I might provision to it. To add S/MIME capabilities, it s= plits the private key in two, sends one to the service and encrypts the oth= er under the public key of the device. So the service only has a random num= ber and the device can't decrypt without the device helping.
=C2=A0
The crypto is a scheme = Matt Blaze and Torben Pederssen discovered. Depending on how you look at it= , you can consider this to be Proxy Re-encryption or Distributed Key Genera= tion. It is actually a simple case that sits at the intersection of both.
--0000000000009faabf058609c843-- From nobody Wed Apr 10 10:04:11 2019 Return-Path: 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 1A8CE120106 for ; Wed, 10 Apr 2019 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363] 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 SLmWEcctkhxv for ; Wed, 10 Apr 2019 10:04:08 -0700 (PDT) Received: from mail.signal100.net (5751e297.skybroadband.com [87.81.226.151]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5D1200EB for ; Wed, 10 Apr 2019 10:04:07 -0700 (PDT) Received: from [192.168.1.5] ([87.81.226.151]) by mail.signal100.net with MailEnable ESMTP; Wed, 10 Apr 2019 18:04:05 +0100 To: endymail@ietf.org References: From: Mark Rousell Message-ID: <5CAE2203.50602@signal100.com> Date: Wed, 10 Apr 2019 18:04:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030105050003070504010503" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:04:09 -0000 This is a multi-part message in MIME format. --------------030105050003070504010503 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 07/04/2019 18:23, Phillip Hallam-Baker wrote: > 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. How about seeing if it could be integrated into a popular thick client like Thunderbird? Conceivably this sort of protocol support might be doable as an addon. Initially, perhaps, this protocol could be proven and/or extended to legacy mail thick clients using a local proxy. > 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. If this were to be exposed to end users then it would be over-complex and would be a disincentive to uptake. So if you are going to have a hard limit of 64KB per message (which I have to say seems small to me) then it needs to be utterly transparent to both senders and receivers. No extra actions of any sort can be required for users on either end; it has to look and act like any other email. And this aspect must not be implementation-specific, i.e. the standard must require the UX to be fully transparent, otherwise the social aspects of UX (which impact take up and popularity) will be negatively impacted. > 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. No, I can't see that scaling well or flexibly. Again, a hard limit like this would be a serious disincentive to ubiquitous take up. Vast numbers of users have slower connections than this, even in the first world. I think that one can reasonably suggest recommended minimum bandwidth in a non-normative/recommendations section of a standard but I believe it is counter-productive to make specific bandwidths a requirement. -- Mark Rousell --------------030105050003070504010503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 07/04/2019 18:23, Phillip Hallam-Baker wrote:
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.

How about seeing if it could be integrated into a popular thick client like Thunderbird? Conceivably this sort of protocol support might be doable as an addon.

Initially, perhaps, this protocol could be proven and/or extended to legacy mail thick clients using a local proxy.

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.

If this were to be exposed to end users then it would be over-complex and would be a disincentive to uptake. So if you are going to have a hard limit of 64KB per message (which I have to say seems small to me) then it needs to be utterly transparent to both senders and receivers. No extra actions of any sort can be required for users on either end; it has to look and act like any other email. And this aspect must not be implementation-specific, i.e. the standard must require the UX to be fully transparent, otherwise the social aspects of UX (which impact take up and popularity) will be negatively impacted.

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.

No, I can't see that scaling well or flexibly. Again, a hard limit like this would be a serious disincentive to ubiquitous take up. Vast numbers of users have slower connections than this, even in the first world.

I think that one can reasonably suggest recommended minimum bandwidth in a non-normative/recommendations section of a standard but I believe it is counter-productive to make specific bandwidths a requirement.


-- 
Mark Rousell
 
 
 
--------------030105050003070504010503-- From nobody Wed Apr 10 10:54:09 2019 Return-Path: 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 26451120253 for ; Wed, 10 Apr 2019 10:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MLqG2F_z9RAL for ; Wed, 10 Apr 2019 10:54:06 -0700 (PDT) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 04F261202CB for ; Wed, 10 Apr 2019 10:54:06 -0700 (PDT) Received: by mail-oi1-f178.google.com with SMTP id n187so2543307oih.6 for ; Wed, 10 Apr 2019 10:54:05 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KCPT0JQzO2ZIhS6VfrCvIxyPGAr9j16TlksEN4GETAo=; b=kkwYqAElzY6iENLCme/7INey8M3x3x+gDxKKbo9US6Icb3ALZ2QORsZ6M7p8J0ay91 q3UgFlyWq85/UNCPGS2i+1INEy+wbXSYuuQw92SBUqV34gNZYfQdJUFUap63I3asoIex ll948o2I4NnXIxw6H6EgW3eCYZtPbz0T0aOtSTn4g+1t8HhXeUTDhE5eeKfBb+VHqhqi 2tQtmof9p9XeNxicUy+foaj/8jymFcIyz9MafTiItKE5+2fd7HDCol3k0mY/8e8OOfO5 j9sCYJAYiXlFQHqZ19DeIC24N+cFW8YTVfOpJzxRniM6ZbwABAUiomlGsezu08YvwUfm SmcQ== X-Gm-Message-State: APjAAAVcCl6LG5Ujo3ehN6IaTmQZVPxvJ6ckvCU1hUTydAFXV3tn7KZF Y4YOQN77OYcYxDnWwW+/CQHkdVsjsvwse5aq53E= X-Google-Smtp-Source: APXvYqweZw5WoRogGMk3pVPqEOiH97X7FimTaQGvc7fG8IQtB97Px4BYKf4oexLkvXDILyTYXA+YE1eBo22NR0Imse4= X-Received: by 2002:aca:c68b:: with SMTP id w133mr3515852oif.58.1554918844870; Wed, 10 Apr 2019 10:54:04 -0700 (PDT) MIME-Version: 1.0 References: <5CAE2203.50602@signal100.com> In-Reply-To: <5CAE2203.50602@signal100.com> From: Phillip Hallam-Baker Date: Wed, 10 Apr 2019 13:53:53 -0400 Message-ID: To: Mark Rousell Cc: endymail Content-Type: multipart/alternative; boundary="00000000000067375b058630c13c" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:54:08 -0000 --00000000000067375b058630c13c Content-Type: text/plain; charset="UTF-8" On Wed, Apr 10, 2019 at 1:04 PM Mark Rousell wrote: > On 07/04/2019 18:23, Phillip Hallam-Baker wrote: > > 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. > > > How about seeing if it could be integrated into a popular thick client > like Thunderbird? Conceivably this sort of protocol support might be doable > as an addon. > > Initially, perhaps, this protocol could be proven and/or extended to > legacy mail thick clients using a local proxy. > That is exactly my strategy in the short term. I have an SMTP proxy but it applies a much older approach. After that, Outlook and TBird. It is quite possible that Microsoft Windows Mail would be the easiest though. > 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. > > > If this were to be exposed to end users then it would be over-complex and > would be a disincentive to uptake. So if you are going to have a hard limit > of 64KB per message (which I have to say seems small to me) then it needs > to be utterly transparent to both senders and receivers. > I totally agree. For some of the messages sent, 64KB is enough. But for an SMTP replacement, the scheme has to be send everything as a control message and detachments unless the message is short enough to fit in the control message The reason to allow content in the message at all is that the overwhelming number of messages are really small, a few lines at most. So unless there is a really long stream of included messages in the thread, we can avoid the need for a detachment. The reason for picking 64KB is that the Ethernet MTU will get up to the IP max packet size at some point but it is really unlikely we will increase IP packet size. Processing a 64KB message as 8 9001 byte Jumbo frames is entirely practical. I suspect that while we would set 64KB as the MUST ACCEPT size, most UDP clients would likely send a message as a detachment if it was going to hit the 9001 MTU. It doesn't make much difference on a TCP transport of course. > No extra actions of any sort can be required for users on either end; it > has to look and act like any other email. And this aspect must not be > implementation-specific, i.e. the standard must require the UX to be fully > transparent, otherwise the social aspects of UX (which impact take up and > popularity) will be negatively impacted. > Total agreement modulo a few small details when we get to managing huge detachments. If I wanted to send a video to this list, I couldn't. Too big. But I want to be able to send files of 100GB without having to switch applications like I do today. But when we deal with really large chunks of data, well, the recipient might not want them and certainly not on their Apple Watch, Android cufflinks etc. So If I send an email that is 300KB to you and I am in your contacts directory, your Mesh Service would perform access control on the inbound message and decide something like * Its from PHB, its authentic * PHB in contacts accept the message * Detachment is less than 1MB, PHB is a friend, account is not short of space, prefetch it and stage. If the detachment was larger, handling would likely be different. Instead of staging it, the clients might pull it directly. For 1TB files we would probably want the transfer to be direct. 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. > > > No, I can't see that scaling well or flexibly. Again, a hard limit like > this would be a serious disincentive to ubiquitous take up. Vast numbers of > users have slower connections than this, even in the first world. > > I think that one can reasonably suggest recommended minimum bandwidth in a > non-normative/recommendations section of a standard but I believe it is > counter-productive to make specific bandwidths a requirement. > The key thing here is establishing some sort of expectation that you deliver the data in a certain length of time most of the time. The situation we have today with SMTP is that most email senders have to hire an email deliverability specialist or use one of less than a hundred MSPs or their email won't get delivered because it is considered to be spam. I would rather have a published expectation than have it left to random policies at random sites.. --00000000000067375b058630c13c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 10, 2019 at 1:04 PM Mark Rousell <mark.rousell@signal100.com&= gt; wrote:
=20 =20 =20
On 07/04/2019 18:23, Phillip Hallam-Baker wrote:
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.

How about seeing if it could be integrated into a popular thick client like Thunderbird? Conceivably this sort of protocol support might be doable as an addon.
=C2=A0
Initially, perhaps, this protocol could be proven and/or extended to legacy mail thick clients using a local proxy.

Th= at is exactly my strategy in the short term. I have an SMTP proxy but it ap= plies a much older approach.

After that, Outlook and TBird.

It is quite possible that Microsoft Wind= ows Mail would be the easiest though.

=C2=A0
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.

If this were to be exposed to end users then it would be over-complex and would be a disincentive to uptake. So if you are going to have a hard limit of 64KB per message (which I have to say seems small to me) then it needs to be utterly transparent to both senders and receivers.

I totally agree. For some of = the messages sent, 64KB is enough. But for an SMTP replacement, the scheme = has to be send everything as a control message and detachments unless the m= essage is short enough to fit in the control message

The reason to allow co= ntent in the message at all is that the overwhelming number of messages are= really small, a few lines at most. So unless there is a really long stream= of included messages in the thread, we can avoid the need for a detachment= .=C2=A0

The reason for picking 64KB is that the Ethernet MTU will get up to= the IP max packet size at some point but it is really unlikely we will inc= rease IP packet size. Processing a 64KB message as 8 9001 byte Jumbo frames= is entirely practical.

I= suspect that while we would set 64KB as the MUST ACCEPT size, most UDP cli= ents would likely send a message as a detachment if it was going to hit the= 9001 MTU. It doesn't make much difference on a TCP transport of course= .

=C2=A0
No extra actions of any sort can be req= uired for users on either end; it has to look and act like any other email. And this aspect must not be implementation-specific, i.e. the standard must require the UX to be fully transparent, otherwise the social aspects of UX (which impact take up and popularity) will be negatively impacted.

Total agreement modulo a few= small details when we get to managing huge detachments.

If I wanted to send a video to this list, I= couldn't. Too big. But I want to be able to send files of 100GB withou= t having to switch applications like I do today. But when we deal with real= ly large chunks of data, well, the recipient might not want them and certai= nly not on their Apple Watch, Android cufflinks etc.

So If I send an email = that is 300KB to you and I am in your contacts directory, your Mesh Service= would perform access control on the inbound message and decide something l= ike
=
* Its from PHB, its authentic
* PHB in contacts accept the message
* Detachment is less than 1MB, PHB is= a friend, account is not short of space, prefetch it and stage.
If the detachment was larger, handling = would likely be different. Instead of staging it, the clients might pull it= directly. For 1TB files we would probably want the transfer to be direct.= =C2=A0

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.

No, I can't see that scaling well or flexibly. Again, a hard limit like this would be a serious disincentive to ubiquitous take up. Vast numbers of users have slower connections than this, even in the first world.

I think that one can reasonably suggest recommended minimum bandwidth in a non-normative/recommendations section of a standard but I believe it is counter-productive to make specific bandwidths a requirement.

The key thing here is establishing some s= ort of expectation that you deliver the data in a certain length of time mo= st of the time.

The situ= ation we have today with SMTP is that most email senders have to hire an em= ail deliverability specialist or use one of less than a hundred MSPs or the= ir email won't get delivered because it is considered to be spam. I wou= ld rather have a published expectation than have it left to random policies= at random sites..
--00000000000067375b058630c13c-- From nobody Wed Apr 10 22:20:26 2019 Return-Path: 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 4A52E120043 for ; Wed, 10 Apr 2019 22:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, URIBL_BLOCKED=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 BQPMTe4MAGu3 for ; Wed, 10 Apr 2019 22:20:22 -0700 (PDT) Received: from mail.signal100.net (5751e297.skybroadband.com [87.81.226.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3CB12002E for ; Wed, 10 Apr 2019 22:20:21 -0700 (PDT) Received: from [192.168.1.5] ([87.81.226.151]) by mail.signal100.net with MailEnable ESMTP; Thu, 11 Apr 2019 06:20:18 +0100 To: endymail@ietf.org References: <5CAE2203.50602@signal100.com> From: Mark Rousell Message-ID: <5CAECE90.4060401@signal100.com> Date: Thu, 11 Apr 2019 06:20:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020909040200030000040309" Archived-At: Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh? X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 05:20:24 -0000 This is a multi-part message in MIME format. --------------020909040200030000040309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/04/2019 18:53, Phillip Hallam-Baker wrote: > > That is exactly my strategy in the short term. I have an SMTP proxy > but it applies a much older approach. > > After that, Outlook and TBird. > > It is quite possible that Microsoft Windows Mail would be the easiest > though. Seems like a good plan. Surprises me about Windows Mail, though. I've not looked at Windows Mail but I would never have thought it was designed to be open to extension. > I totally agree. For some of the messages sent, 64KB is enough. But > for an SMTP replacement, the scheme has to be send everything as a > control message and detachments unless the message is short enough to > fit in the control message > > The reason to allow content in the message at all is that the > overwhelming number of messages are really small, a few lines at most. > So unless there is a really long stream of included messages in the > thread, we can avoid the need for a detachment.. > > The reason for picking 64KB is that the Ethernet MTU will get up to > the IP max packet size at some point but it is really unlikely we will > increase IP packet size. Processing a 64KB message as 8 9001 byte > Jumbo frames is entirely practical. > > I suspect that while we would set 64KB as the MUST ACCEPT size, most > UDP clients would likely send a message as a detachment if it was > going to hit the 9001 MTU. It doesn't make much difference on a TCP > transport of course.. Ah I see, that makes sense, thanks for this further explanation. > > Total agreement modulo a few small details when we get to managing > huge detachments. > > If I wanted to send a video to this list, I couldn't. Too big. But I > want to be able to send files of 100GB without having to switch > applications like I do today. But when we deal with really large > chunks of data, well, the recipient might not want them and certainly > not on their Apple Watch, Android cufflinks etc. > > So If I send an email that is 300KB to you and I am in your contacts > directory, your Mesh Service would perform access control on the > inbound message and decide something like > > * Its from PHB, its authentic > * PHB in contacts accept the message > * Detachment is less than 1MB, PHB is a friend, account is not short > of space, prefetch it and stage. > If the detachment was larger, handling would likely be different. > Instead of staging it, the clients might pull it directly. For 1TB > files we would probably want the transfer to be direct. > That all makes sense. > The key thing here is establishing some sort of expectation that you > deliver the data in a certain length of time most of the time. > > The situation we have today with SMTP is that most email senders have > to hire an email deliverability specialist or use one of less than a > hundred MSPs or their email won't get delivered because it is > considered to be spam. I would rather have a published expectation > than have it left to random policies at random sites.. I do note that you started this thread by suggesting (if I understood correctly) that the protocol would initially be promoted for corporate internal email-style use and so my concerns about potentially limited bandwidth in the world at large would likely not apply in that scenario. Nevertheless, it seems to me that the standard needs to be got right from the beginning for both internal and broad external usage scenarios, otherwise it risks not being able to catch on and grow outside of a niche. (As an aside: It seems to me that for corporate scenarios your new protocol will effectively compete against the combination of Exchange/O365/Outlook/Sharepoint. In particular in my opinion, O365 is a specially powerful tool for ecosystem lock in for Microsoft). In general I can agree with documenting reasonable/recommended/non-normative values as a kind of statement of ideals but if you specify too much bandwidth as being a hard requirement then I feel certain that it will kill broad uptake of a very innovative new protocol like this one. In a protocol that is (eventually, as I understand it) intended to connect together heterogeneous nodes (heterogeneous in terms of ownership, bandwidth and quality of connectivity) then I think it is virtually impossible for the designer of the protocol to realistically specify delivery time expectations. Surely the protocol (in order to (a) work in the real world and (b) to be attractive to a wide range of users) must work as well as possible over a wide range of connection type and speeds (which means, in very common scenarios, considerably less than 10Mb/s). Despite my concerns, it seems to me that your concept has great potential. We're in a time of considerable innovation amongst messaging protocols but almost all of it is (a) within walled, non-standard gardens, and (b) designed with a focus on instant messaging-style applications, and so it would be very good indeed to see a new standard-driven protocol that can provide the traditional benefits of email in a more modern way (something which walled garden instant messaging-style protocols and apps fail to do). I had previously noticed discussion of your Mathematical Mesh drafts and I've just gone to look at them, as well as mathmesh.com. I had not realised until just now how expansive a concept you have. I realise now that it's about far more than just a modernised form of email. It seems to be very exciting indeed. It's so broad that focussing on a potentially achievable goal such as email-style usage seems like it might be a good way to proceed. -- Mark Rousell --------------020909040200030000040309 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/04/2019 18:53, Phillip Hallam-Baker wrote:

That is exactly my strategy in the short term. I have an SMTP proxy but it applies a much older approach.

After that, Outlook and TBird.

It is quite possible that Microsoft Windows Mail would be the easiest though.

Seems like a good plan.

Surprises me about Windows Mail, though. I've not looked at Windows Mail but I would never have thought it was designed to be open to extension.

 I totally agree. For some of the messages sent, 64KB is enough. But for an SMTP replacement, the scheme has to be send everything as a control message and detachments unless the message is short enough to fit in the control message

The reason to allow content in the message at all is that the overwhelming number of messages are really small, a few lines at most. So unless there is a really long stream of included messages in the thread, we can avoid the need for a detachment.. 

The reason for picking 64KB is that the Ethernet MTU will get up to the IP max packet size at some point but it is really unlikely we will increase IP packet size. Processing a 64KB message as 8 9001 byte Jumbo frames is entirely practical.

I suspect that while we would set 64KB as the MUST ACCEPT size, most UDP clients would likely send a message as a detachment if it was going to hit the 9001 MTU. It doesn't make much difference on a TCP transport of course..

Ah I see, that makes sense, thanks for this further explanation.


Total agreement modulo a few small details when we get to managing huge detachments.

If I wanted to send a video to this list, I couldn't. Too big. But I want to be able to send files of 100GB without having to switch applications like I do today. But when we deal with really large chunks of data, well, the recipient might not want them and certainly not on their Apple Watch, Android cufflinks etc.

So If I send an email that is 300KB to you and I am in your contacts directory, your Mesh Service would perform access control on the inbound message and decide something like

* Its from PHB, its authentic
* PHB in contacts accept the message
* Detachment is less than 1MB, PHB is a friend, account is not short of space, prefetch it and stage.
If the detachment was larger, handling would likely be different. Instead of staging it, the clients might pull it directly. For 1TB files we would probably want the transfer to be direct. 


That all makes sense.

The key thing here is establishing some sort of expectation that you deliver the data in a certain length of time most of the time.

The situation we have today with SMTP is that most email senders have to hire an email deliverability specialist or use one of less than a hundred MSPs or their email won't get delivered because it is considered to be spam. I would rather have a published expectation than have it left to random policies at random sites..

I do note that you started this thread by suggesting (if I understood correctly) that the protocol would initially be promoted for corporate internal email-style use and so my concerns about potentially limited bandwidth in the world at large would likely not apply in that scenario. Nevertheless, it seems to me that the standard needs to be got right from the beginning for both internal and broad external usage scenarios, otherwise it risks not being able to catch on and grow outside of a niche.

(As an aside: It seems to me that for corporate scenarios your new protocol will effectively compete against the combination of Exchange/O365/Outlook/Sharepoint. In particular in my opinion, O365 is a specially powerful tool for ecosystem lock in for Microsoft).

In general I can agree with documenting reasonable/recommended/non-normative values as a kind of statement of ideals but if you specify too much bandwidth as being a hard requirement then I feel certain that it will kill broad uptake of a very innovative new protocol like this one.

In a protocol that is (eventually, as I understand it) intended to connect together heterogeneous nodes (heterogeneous in terms of ownership, bandwidth and quality of connectivity) then I think it is virtually impossible for the designer of the protocol to realistically specify delivery time expectations. Surely the protocol (in order to (a) work in the real world and (b) to be attractive to a wide range of users) must work as well as possible over a wide range of connection type and speeds (which means, in very common scenarios, considerably less than 10Mb/s).

Despite my concerns, it seems to me that your concept has great potential. We're in a time of considerable innovation amongst messaging protocols but almost all of it is (a) within walled, non-standard gardens, and (b) designed with a focus on instant messaging-style applications, and so it would be very good indeed to see a new standard-driven protocol that can provide the traditional benefits of email in a more modern way (something which walled garden instant messaging-style protocols and apps fail to do).

I had previously noticed discussion of your Mathematical Mesh drafts and I've just gone to look at them, as well as mathmesh.com. I had not realised until just now how expansive a concept you have. I realise now that it's about far more than just a modernised form of email. It seems to be very exciting indeed. It's so broad that focussing on a potentially achievable goal such as email-style usage seems like it might be a good way to proceed.

-- 
Mark Rousell
 
 
 
--------------020909040200030000040309--