6 ms·

I like what the author is saying, but I want everyone to keep in mind that how we send email is mutually exclusive from how we read/create email. You can solve

I like what the author is saying, but I want everyone to keep in mind that how we send email is mutually exclusive from how we read/create email. You can solve issues related to one while not dealing at all with the other. For example, something I'd love to see is SMTP2. What can we do to improve SMTP and make it faster? Can we require TLS? Can we standardize and lockdown sender authentication? We wouldn't necessarily need to have a separate DNS records because it could be handled in a fashion similar to HTTP and HTTP2 and use the same ports. This new protocol could be tied to a new standardized email format, if that's what people wanted to do.

sangupta 2y ago
Why not standardize on using HTTP3 using POST requests with JSON payload instead?
- gjsman-1000 2y ago
  Heck, after writing this article, I’m wondering why email can’t be a standardized JSON-driven API implemented on a web server..:
  - sangupta 2y ago
    Just left this comment on your site. Would be much simpler to maintain, switch-to, and motivate for migration.
  - immibis 2y ago
    It could, but why change what isn't broken? Email messages are quite agnostic to how you deliver them, though. IIRC Google and Microsoft use a proprietary protocol with each other. Outlook uses a proprietary protocol with Exchange. Email used to be transferred through a non-internet packet-switched point-to-point network of intermittently connected dial-up links. The fact that the email messages are agnostic to how they're transmitted is actually very cool, because it enables switching to future technologies without any changes to the user agents, and vice versa. You put a file in your outbox and it magically appears in someone else's inbox later. Originally mail readers had to be executed on the mail server and read directly from your inbox directory, then we created new last-mile protocols so the reader could run on a separate computer (which in my understanding is basically identical to a Fidonet "point"). You can easily imagine a mail server connected to an onion router, or to Yggdrasil or some other meshnet, or even to whatever remnant of the original UUCP net someone is still running for fun. The current design enables this sort of thing.
    - sangupta 2y ago
      If these are basic questions, pardon my limited knowledge of email-transport internals. - May be the transport is better than HTTP, but HTTP is well understood and easy to debug for developers (debugging a web-app is easy). Similarly, a JSON payload will bring structure than the current way of creating boundaries. Moving to HTTP+JSON will allow far easier access to developers who want to build on top of it, or self-hosting. Get a domain, run a web-app, set a few records and you are done. - Put a file in outbox and it get's out. From my outlook experience, it seems to be a cron that scans a particular DB query. Should still be possible. - I have no idea on how onion routers etc work so won't comment on that. - And lastly, if Google <> MS, Outlook <> Exchange use a proprietary protocol then I will read that as an indication to improve current standard.
      - immibis 2y ago
        My vote for the most important improvement to SMTP would simply be pipelining. It was designed in a time of nodes with low memory connected by links that are fast relative to everything else, and therefore, it uses a turn-taking command/response paradigm where each side keeps having to stop and wait for the other. "Hello." "Hello." "user1@mydomain wants to send a mail." "Okay, continue." "He is sending it to user2@yourdomain." "Okay, continue." "He is sending a copy to user3@yourdomain." "Okay, continue." "Here is the data." "Mail accepted." (at least there isn't an extra step after the data to say "that was all") A redesigned version would send all parameters at once, and then get a single success or fail response at the end. Perhaps one pause could be useful to validate the headers before the main body is sent, but only for large messages (e.g. with attachments). "Hello, user1@mydomain is sending to user2@yourdomain and user3@yourdomain. Here is the message. Bye." "Hello. Sorry, user2@yourdosmain is unknown. Bye." An extension like this exists for NNTP, in RFC4644, since that really is a mesh topology instead of everyone-talks-to-everyone and some central links have extremely high traffic. It requires two round trips per message and processing of different messages can be interleaved while waiting for the reply. "Do you want message 1? Do you want message 2? Do you want message 3?" "I want message 1. I already have message 2." "Here is message 1. Do you want message 4? Do you want message 5?"
- amanda99 2y ago
  I'm not sure if this is sarcasm or not.
  - sangupta 2y ago
    Nopes. I am not deep into how email works, but always had this genuine curiosity. Unless, your reply was for the reply to this comment ;)

sangupta 2y ago

Why not standardize on using HTTP3 using POST requests with JSON payload instead?

gjsman-1000 2y ago
Heck, after writing this article, I’m wondering why email can’t be a standardized JSON-driven API implemented on a web server..:
- sangupta 2y ago
  Just left this comment on your site. Would be much simpler to maintain, switch-to, and motivate for migration.
- immibis 2y ago
  It could, but why change what isn't broken? Email messages are quite agnostic to how you deliver them, though. IIRC Google and Microsoft use a proprietary protocol with each other. Outlook uses a proprietary protocol with Exchange. Email used to be transferred through a non-internet packet-switched point-to-point network of intermittently connected dial-up links. The fact that the email messages are agnostic to how they're transmitted is actually very cool, because it enables switching to future technologies without any changes to the user agents, and vice versa. You put a file in your outbox and it magically appears in someone else's inbox later. Originally mail readers had to be executed on the mail server and read directly from your inbox directory, then we created new last-mile protocols so the reader could run on a separate computer (which in my understanding is basically identical to a Fidonet "point"). You can easily imagine a mail server connected to an onion router, or to Yggdrasil or some other meshnet, or even to whatever remnant of the original UUCP net someone is still running for fun. The current design enables this sort of thing.
  - sangupta 2y ago
    If these are basic questions, pardon my limited knowledge of email-transport internals. - May be the transport is better than HTTP, but HTTP is well understood and easy to debug for developers (debugging a web-app is easy). Similarly, a JSON payload will bring structure than the current way of creating boundaries. Moving to HTTP+JSON will allow far easier access to developers who want to build on top of it, or self-hosting. Get a domain, run a web-app, set a few records and you are done. - Put a file in outbox and it get's out. From my outlook experience, it seems to be a cron that scans a particular DB query. Should still be possible. - I have no idea on how onion routers etc work so won't comment on that. - And lastly, if Google <> MS, Outlook <> Exchange use a proprietary protocol then I will read that as an indication to improve current standard.
    - immibis 2y ago
      My vote for the most important improvement to SMTP would simply be pipelining. It was designed in a time of nodes with low memory connected by links that are fast relative to everything else, and therefore, it uses a turn-taking command/response paradigm where each side keeps having to stop and wait for the other. "Hello." "Hello." "user1@mydomain wants to send a mail." "Okay, continue." "He is sending it to user2@yourdomain." "Okay, continue." "He is sending a copy to user3@yourdomain." "Okay, continue." "Here is the data." "Mail accepted." (at least there isn't an extra step after the data to say "that was all") A redesigned version would send all parameters at once, and then get a single success or fail response at the end. Perhaps one pause could be useful to validate the headers before the main body is sent, but only for large messages (e.g. with attachments). "Hello, user1@mydomain is sending to user2@yourdomain and user3@yourdomain. Here is the message. Bye." "Hello. Sorry, user2@yourdosmain is unknown. Bye." An extension like this exists for NNTP, in RFC4644, since that really is a mesh topology instead of everyone-talks-to-everyone and some central links have extremely high traffic. It requires two round trips per message and processing of different messages can be interleaved while waiting for the reply. "Do you want message 1? Do you want message 2? Do you want message 3?" "I want message 1. I already have message 2." "Here is message 1. Do you want message 4? Do you want message 5?"
amanda99 2y ago
I'm not sure if this is sarcasm or not.
- sangupta 2y ago
  Nopes. I am not deep into how email works, but always had this genuine curiosity. Unless, your reply was for the reply to this comment ;)