Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh?

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Apr 10, 2019 at 1:04 PM Mark Rousell <[e-mail]>
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..