5 ms·
Why not standardize on using HTTP3 using POST requests with JSON payload instead?
by sangupta 2y ago
Why not standardize on using HTTP3 using POST requests with JSON payload instead?
- gjsman-1000 2y agoHeck, after writing this article, I’m wondering why email can’t be a standardized JSON-driven API implemented on a web server..:
- sangupta 2y agoJust left this comment on your site. Would be much simpler to maintain, switch-to, and motivate for migration.
- immibis 2y agoIt 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 agoIf 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 agoMy 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?"
- MiscIdeaMaker99 2y agoApologies if you already know this, but pipelining has existing in SMTP for decades now. You can see if an SMTP server supports it when using EHLO (instead of HELO). Trying 74.125.202.26... Connected to smtp.google.com. Escape character is '^]'. 220 mx.google.com ESMTP 8926c6da1cb9f-489374a766fsi10850940173.171 - gsmtp EHLO testing 250-mx.google.com at your service, [47.227.77.52] 250-SIZE 157286400 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING <============= HERE 250-CHUNKING 250 SMTPUTF8 I believe this RFC 2920 is the original standard going back to 2000. I remember pipelining being a thing in Postfix about 20 years ago, at least.
- immibis 2y agoI believe you still have to stop at certain points to check the responses. You might not want to send a message if one of the recipients is invalid, but only that command will return an error code, and the message sending will succeed. You'd also need to prevent command injection. If the response code to DATA is an error, but you sent the message anyway, the whole message body will be interpreted as commands. Oops! The line ending bug (SMTP smuggling discovered early this year) was bad enough.
- amanda99 2y agoI'm not sure if this is sarcasm or not.
- sangupta 2y agoNopes. I am not deep into how email works, but always had this genuine curiosity. Unless, your reply was for the reply to this comment ;)