On Wed, Oct 28, 2015 at 9:33 AM, Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote: > On Oct 27, 2015, at 7:58 PM, John R Levine <johnl@xxxxxxxxx> wrote: > > Those are separate issues. We strip attachments because people send > messages that say "my kid's school play is tomorrow at 7 PM, tickets $5, and > here's a poster" and attach a 20MB powerpoint horror. > > > Seems like you could just bounce messages with attachments larger than X, > where X is O(1k). We have to allow for MUA-specific attachments, but we > could even handle those by whitelisting them. "Fixing" messages with > attachments is a convenience, not a requirement. Here we are going beyond Internet architecture and into the real of messaging application architecture. I think it is very clear that the owner of example.com can decide to publish DMARC records that prevent use of mail users with accounts in that domain sending to a mailing list and that flows from a correct understanding of the Internet architecture. If you want to fix messaging, it is harder. You essentially have two choices: 1) Attempt to work within the existing deployed infrastructures. 2) Attempt to supersede the existing infrastructure with a new one. Both give abundant opportunity for despair. Deploying a new messaging system is next to impossible. There will always be some parts of the legacy infrastructure that resist incremental change. We have enough trouble trying to change the WebPKI and that is despite the system being actually engineered for things like algorithm updates and having a coordinating body (CABForum) that simply doesn't have an equivalent for mail. Things are not totally hopeless however. I think that there is a good chance we could start to fix this in 2018 when a particular piece of IPR expires. We are not going to persuade people to change their email systems, that is hopeless. That can't happen any more than people would have changed their FTP servers back in 1993. What is quite achievable however is to get people to adopt a system that offers a new set of functionality that incidentally makes the legacy infrastructure obsolete. The Web was not adopted because people were looking for a replacement for FTP but it has effectively replaced FTP. What I would urge people to think about is the need for a standards based infrastructure with 'dropbox' like capability. Further, one that allows for end-to-end encryption of the message contents and for messages to be distributed to groups of users defined by an offline administrator. So for example, I am about to release some code to my engineering team. The code is large (about 200 MB including the test vectors). I do not know the names of the engineers who are going to be working on the systems, they don't report to me. What I want to be able to do is to wrap up the data in a ZIP file, and encrypt it to a security label ( MESHALPHA@xxxxxxxxxxxxxx ) that is administered by the Director of Engineering. The only way to do that with S/MIME and OpenPGP right now is that either I have to encrypt the message for each recipient or some easily breached server has to. If we apply Matt Blaze's proxy re-encryption, 'recryption', my director of engineering can do the administration of the security label using an offline client and upload data to the recryption service. the service can then recrypt the information required for any authorized user to decrypt any of the data I upload. Recryption is a powerful tool. So powerful that I think it is properly regarded as the extension of public key cryptography from bilateral communications to multi-lateral communications. While we all know and understand that email users don't see the need for E2E encryption, this is not the case with pull-model data distribution. People get really worried about putting large chunks of data onto a file service. I think that getting people excited about a re-engineering of SMTP is going to be very hard. But there is a real possibility that people might be interested in a unified messaging infrastructure that merges email, news, dropbox, chat and VOIP and has an integrated security infrastructure built in from day 1.