4 ms·

You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a

by jerf 2y ago

You don't need all that much to ensure integrity in a brand-new system without decades of legacy. I mean, still non-trivial, getting that "not much" right is a professional cryptographer's job, but you don't need all that much. Getting it right in a system the size of the world with decades of legacy in an environment where right up until DKIM came out pretty much every player in the system expected and used the ability to make arbitrary modifications to emails passing through it is really hard. It makes even the simplest thing takes decades. Unfortunately, there isn't going to be a replacement to email either, because at this point anyone with the resources to pull it off will also insist on making it a closed box that you have to pay way, way too much to use.

gjsman-1000 2y ago
I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.
- cameronh90 2y ago
  If we were going to do this, can we come up with a well defined subset/derived specification of HTML5 for email, along with a conformity test ala Acid2/Acid3? Outlook for Windows still uses the venerable Microsoft Word HTML rendering engine.
  - dsr_ 2y ago
    Sure. My primary request is that it not be allowed to show links as anything other than full URLs. My secondary priority is in not loading anything from an external site.
    - gjsman-1000 2y ago
      Unfortunately, we know that most people who aren't in tech, are terrible at reading and understanding URLs to begin with, so I'm not sure that there's any point to be gained here.
    - rebane2001 2y ago
      It'd be impossible to prevent non-full URLs without also imposing extremely heavy restrictions on images, styling, and html. There are way too many ways to hide, spoof, or obfuscate an url. And even then, you'd need to somehow render the link in a way where the average user can understand it (which part of the URL is the domain and what implications it has).
- mvid 2y ago
  The benefit of email is its ubiquity and existing deployment. Throwing it away for a new protocol loses all existing value.
  - gjsman-1000 2y ago
    The same could be said of HTTP, but we threw it away in favor of HTTPS. Thank goodness we did - and I don’t think anyone wants to go back to the time we tried securing HTTP without HTTPS. Again, my proposal is not that we completely kill classic email - but rather, we make a new standard, the big players get on board, and there’s a clear deadline that says “your emails will always be junk past this date if they don’t comply.” They’ll still arrive though. Nobody wants their emails to go to Junk automatically - that’s incentive enough. This is like what we did with HTTP. There came a day where HTTP login screens now have warnings in many browsers. But they still work.
    - crote 2y ago
      But we didn't. There are still plenty of HTTP-only devices out there, and there isn't a single browser out there which refuses to work with HTTP servers. Heck, you don't even get a warning if you're just reading the website - you only get that when you try to log in! If we can't do the equivalent of "your emails will always be junk past this date if they don’t comply" with HTTP, what makes you think we can do it with email?
      - gjsman-1000 2y ago
        I answer that, email is a very different beast than HTTP. 1. If we were to transition to my hypothetical Email2, that doesn't mean it's all or nothing. The transition to HTTPS, does not mean that HTTP no longer is readable. Similarly, the transition would not mean classic emails are automatically unreadable either - but there's a strong incentive for corporations relying on it to fix it. Hypothetically, there would be an MX2, and an MX record. MX would be the fallback for if MX2 sending is not available. So if an out-of-date client from 10 years ago sends an email, it finds the MX record and sends it, no problem. However, the receiver expecting MX2, automatically classifies the email as Insecure and Junk. Meanwhile, an MX2-enabled sender could identify the MX record for a website that does not support MX2 yet, and still deliver the message. 2. Email is not the same as a device. Most emails are sent from an email server with hundreds of inboxes. Take Google and Microsoft - they are 40% of global email traffic. Add Yahoo, GoDaddy, and the other big names, and you're well on the way. Unlike HTTP, the transition may actually be much quicker, because self-hosting email is not very popular (and those that do, are using commercial or open-source packages which could easily add support).
- jerf 2y ago
  "If you could even just get Gmail, Outlook, Zoho, and Yahoo" Well, that's where you hit the blocker I'm talking about. They're only on board if there's some sort of benefit they can get from closing the standard. I didn't think of this when I wrote my post first, but we've basically been down this road in something close enough to be relevent: Instant messaging. Such interop as was supported has been the result of the open source community laboriously fighting against the commercial interests... and, ultimately, losing comprehensively. Nobody is interested in a standardized instant messaging system.

by jerf 2y ago

gjsman-1000 2y ago

I’m a bit nuts, so bear with me: Maybe we should seriously have discussions about, let’s just call it, Email2. We have a new DNS record type, MX2, with a proper signing algorithm that’s mandatory. Meanwhile, we put it in spec that every MX2 mailbox, must be a valid MX mailbox, if the receiver chooses to accept MX. This might sound insane - except, I argue, with proper planning, it would be like the HTTPS transition. If you could even just get Gmail, Outlook, Zoho, and Yahoo on board - every piece of software would be forced to start supporting Email2. Especially, especially, if they announced that come 2030, all non-Email2 letters always go to Junk. They’ll still arrive - possibly forever - but the incentive to fix it will be there.

cameronh90 2y ago
If we were going to do this, can we come up with a well defined subset/derived specification of HTML5 for email, along with a conformity test ala Acid2/Acid3? Outlook for Windows still uses the venerable Microsoft Word HTML rendering engine.
- dsr_ 2y ago
  Sure. My primary request is that it not be allowed to show links as anything other than full URLs. My secondary priority is in not loading anything from an external site.
  - gjsman-1000 2y ago
    Unfortunately, we know that most people who aren't in tech, are terrible at reading and understanding URLs to begin with, so I'm not sure that there's any point to be gained here.
  - rebane2001 2y ago
    It'd be impossible to prevent non-full URLs without also imposing extremely heavy restrictions on images, styling, and html. There are way too many ways to hide, spoof, or obfuscate an url. And even then, you'd need to somehow render the link in a way where the average user can understand it (which part of the URL is the domain and what implications it has).
mvid 2y ago
The benefit of email is its ubiquity and existing deployment. Throwing it away for a new protocol loses all existing value.
- gjsman-1000 2y ago
  The same could be said of HTTP, but we threw it away in favor of HTTPS. Thank goodness we did - and I don’t think anyone wants to go back to the time we tried securing HTTP without HTTPS. Again, my proposal is not that we completely kill classic email - but rather, we make a new standard, the big players get on board, and there’s a clear deadline that says “your emails will always be junk past this date if they don’t comply.” They’ll still arrive though. Nobody wants their emails to go to Junk automatically - that’s incentive enough. This is like what we did with HTTP. There came a day where HTTP login screens now have warnings in many browsers. But they still work.
  - crote 2y ago
    But we didn't. There are still plenty of HTTP-only devices out there, and there isn't a single browser out there which refuses to work with HTTP servers. Heck, you don't even get a warning if you're just reading the website - you only get that when you try to log in! If we can't do the equivalent of "your emails will always be junk past this date if they don’t comply" with HTTP, what makes you think we can do it with email?
    - gjsman-1000 2y ago
      I answer that, email is a very different beast than HTTP. 1. If we were to transition to my hypothetical Email2, that doesn't mean it's all or nothing. The transition to HTTPS, does not mean that HTTP no longer is readable. Similarly, the transition would not mean classic emails are automatically unreadable either - but there's a strong incentive for corporations relying on it to fix it. Hypothetically, there would be an MX2, and an MX record. MX would be the fallback for if MX2 sending is not available. So if an out-of-date client from 10 years ago sends an email, it finds the MX record and sends it, no problem. However, the receiver expecting MX2, automatically classifies the email as Insecure and Junk. Meanwhile, an MX2-enabled sender could identify the MX record for a website that does not support MX2 yet, and still deliver the message. 2. Email is not the same as a device. Most emails are sent from an email server with hundreds of inboxes. Take Google and Microsoft - they are 40% of global email traffic. Add Yahoo, GoDaddy, and the other big names, and you're well on the way. Unlike HTTP, the transition may actually be much quicker, because self-hosting email is not very popular (and those that do, are using commercial or open-source packages which could easily add support).
jerf 2y ago
"If you could even just get Gmail, Outlook, Zoho, and Yahoo" Well, that's where you hit the blocker I'm talking about. They're only on board if there's some sort of benefit they can get from closing the standard. I didn't think of this when I wrote my post first, but we've basically been down this road in something close enough to be relevent: Instant messaging. Such interop as was supported has been the result of the open source community laboriously fighting against the commercial interests... and, ultimately, losing comprehensively. Nobody is interested in a standardized instant messaging system.