DNS-over-HTTPS
You know, I&#x27;ve had thoughts along similar lines in the email space (SMTP). HTTP is such a fantastic protocol and an amazing amount of engineering effort has gone into it compared to SMTP. I&#x27;ve wondered whether there would be any interest in defining a translation from SMTP into HTTP, with an eye toward eventually deprecating SMTP in the fullness of time.<p>For example, to send an email, perhaps you just send an HTTP POST request to a canonical endpoint (email.example.com), instead of all the rigamarole that SMTP servers require with a unique text protocol requiring multiple round trips. Have you seen the number of SMTP commands involved in sending a <i>single</i> email? Here&#x27;s an abbreviated transcript of what it&#x27;s like to send an email using `telnet`:<p><pre><code>  # Wait for banner from server (RT #1)
  220 email-inbound-relay-1234.example.com ESMTP Sendmail 1.0.0; Thu, 29 Sep 2016 19:22:12 GMT
  
  # Send EHLO and wait for reply (RT #2)
  EHLO example.com
  250-email-inbound-relay-1234.example.com Hello ws-1.example.com [1.2.3.4], pleased to meet you
  250-ENHANCEDSTATUSCODES
  250-PIPELINING
  250-EXPN
  ...
  250 HELP

  # At this phase you should really send STARTTLS and negotiate a TLS connection,
  # but we&#x27;ll just ignore that for now and proceed plaintext.
  
  # Specify sender (RT #3)
  MAIL FROM: jcrites@example.com
  250 2.1.0 jcrites@example.com... Sender ok
  
  # Specify recipient (RT #4)
  RCPT TO: jcrites@example.net
  250 2.1.5 jcrites@example.net... Recipient ok
  
  # Specify message headers and content (RT #5)
  DATA
  354 Enter mail, end with &quot;.&quot; on a line by itself
  Subject: Hello, world!
  
  Fun stuff
  .

  # Wait for reply (RT #6) 
  250 2.0.0 u8U1LC1l022963 Message accepted for delivery
</code></pre>
Furthermore, if you skip these steps or front-run them, some servers will consider that suspicious or spammy behavior. (RFC 2920 properly allows this as an extension called pipelining, advertised in the EHLO reply above.)<p>With full use of SMTP extensions, things are a bit better than I imply but still frustratingly suboptimal. For example, I&#x27;ve run across ISPs who purely for their own load management reasons want to close an SMTP session at the TCP level after an arbitrary number of emails have been sent (N &lt; 100)! Why would they desire that? If we&#x27;re going to exchange more messages, then it&#x27;s certainly <i>less</i> efficient for us both to negotiate a new TCP session and TLS session, rather than reuse the one we already have, but such is the practice of email. So message sending often can be as inefficient as this. When sending to some ISPs worldwide it&#x27;s not uncommon for a single message to take seconds to deliver under normal network conditions.<p>How about we replace all of that with an HTTP POST to email.example.com, specifying the email headers and content with the POST body, and the sender and recipient as headers or querystring parameters? I think it&#x27;d be nice to get there eventually rather than drag SMTP on forever. All of the effort that goes into HTTP clients, servers, and security could benefit the email community as well.<p>Proper TLS security is still nascent in SMTP -- only because of Google&#x27;s actions with Gmail and their Safer Email [1] initiative has TLS really come into widespread adoption at all. Today, although a lot of email is <i>nominally</i> taking place over TLS, most clients are not involving any sort of path validation and the connections are susceptible to MITM; and email clients don&#x27;t specify client TLS certificates nor do servers examine them. If we were to employ it, TLS client certificate authentication could be an effective way to prevent email forgery, e.g., require email from example.com to be sent from a client with a TLS certificate for that domain. This kind of thing would be much easier to achieve in the HTTP world than in the SMTP world. We could also take advantage of HTTP&#x2F;2 pipelining to efficiently deliver a lot of traffic across just one TCP connection.<p>We&#x27;d still need <i>most</i> of the effort invested into email, such as all of the effort fighting abuse, and mail servers would still need to buffer outbound messages and authenticate inbound ones, etc. (and we&#x27;d still need SPF, DKIM, DMARC) but at least it would simplify the foundational and protocol-level work, like what&#x27;s involved in bootstrapping a new email client or server from scratch. You could write basic code to send an email in a few minutes using an HTTP library in any language. SMTP is pretty well entrenched, however, and the incremental benefit is probably not large enough, so I don&#x27;t have my hopes up.<p>[1] <a href="https:&#x2F;&#x2F;www.google.com&#x2F;transparencyreport&#x2F;saferemail&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;transparencyreport&#x2F;saferemail&#x2F;</a>