[immibis]

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?"

[MiscIdeaMaker99]

Apologies 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]

I 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.