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
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
