On Fri, Aug 21, 2020 at 3:37 PM Grant Taylor <gtay...@gentoo.tnetconsulting.net> wrote: > > On 8/21/20 6:37 AM, Rich Freeman wrote: > > This stuff can be interesting to discuss, but email is SO entrenched > > that I don't see any of this changing because of all the legacy issues. > > You would need to offer something that is both easier and better to > > use to such a degree that people are willing to change. > > "something that is /both/ *easier* and *better*". > > That's a VERY tall bar to clear.
Hence I'm going to basically reply to only a few lines of your email - this isn't going to go anywhere so I really don't want to get into an endless argument about why people use webservices/etc. > What does JSON / XML / etc. on top of HTTP(S) provide that SMTP doesn't > provide? It is what just about every other modern application in existence uses. I'm sure there are hundreds of articles on the reasons for this that are far better than anything I'd come up with here. > > ... use more standard libraries/etc. > > There are many libraries to interface with SMTP. And they don't work for anything OTHER than SMTP. A library for JSON/webservices/whatever works for half the applications being written today. > > Stop focusing on HTTP(S) <any version thereof> for a few minutes. > > If you were to create a new protocol from the ground up, why would you > introduce additional layers into the application stack — which represent > additional dependencies and complications — if you didn't have to? > > Not everything is a web server. Not everything can benefit from being > forced through a web server. This is simple. This is how just about EVERYBODY does it these days. http works as a transport mechanism. And obviously when I say http I mean http/https with the latter being preferred. That is the beauty of standards like this - somebody else figured out SSL on top of HTTP so we don't need an email-specific reimplementation of that. I mean, why use TCP? Why not use something more tailored to email? TCP probably has a dozen optional features that nobody uses with email, so why implement all that just to send email? The answer is that it makes WAY more sense to recycle a standard protocol than to invent one. If SMTP didn't exist, and we needed a way to post a bunch of data to a remote server, you'd use HTTP, because it already works. > > Most of the benefits only accrue if you adopt PKI as well, which is > > a problem that is hard to scale out to the masses. > > PKI is relatively easy to scale. (For a given value.) Hence the > thriving CA industry. > > Doing so in a trust worthy manner is the problem. Especially if you > want to avoid a single point of control / failure / GEO political / etc. It isn't just the trust problem. It is also the ease of use problem. Let's assume you trust all the CAs out there. Why isn't anybody using SSL for email? It is built into half the email clients out there. The problem is that exchanging certificates at an individual level is hard. Oh, for an organization with an IT department it isn't a problem. The IT department can just issue a certificate to everybody, generating keys for them. Then it can stick all the certs in some kind of directory that their email clients all use. Getting your cousin to use SSL certs for their email is a whole different matter. Heck, just using it between two different companies, both supported by professional IT depts, is a pain. You could use TLS for the transport itself and have the email servers configured to only use TLS for those domains, but actually doing E2E encryption is hard with email because there aren't a lot of standards for key exchange across unrelated orgs. > If we throw all the trusted CAs out the window, how do you /bootstrap/ > encrypted communications? - My personal opinion is DNS. > DNSSEC is: 1. Still poorly supported even where it makes sense. 2. A great hypothetical solution for the 0.002% of email users who own a domain name, like you and me. -- Rich
