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