On Sun, Apr 7, 2019 at 10:23 AM Phillip Hallam-Baker <[email protected]> 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
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
