Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
Date: Fri, 21 Aug 2020 23:58:25
Message-Id: CAGfcS_kBA4dGFCqmBB0enpd-ybN3TONazTQSoxPkJJVUKqUmGA@mail.gmail.com
In Reply to: Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins? by Grant Taylor
1 On Fri, Aug 21, 2020 at 3:37 PM Grant Taylor
2 <gtaylor@×××××××××××××××××××××.net> wrote:
3 >
4 > On 8/21/20 6:37 AM, Rich Freeman wrote:
5 > > This stuff can be interesting to discuss, but email is SO entrenched
6 > > that I don't see any of this changing because of all the legacy issues.
7 > > You would need to offer something that is both easier and better to
8 > > use to such a degree that people are willing to change.
9 >
10 > "something that is /both/ *easier* and *better*".
11 >
12 > That's a VERY tall bar to clear.
13
14 Hence I'm going to basically reply to only a few lines of your email -
15 this isn't going to go anywhere so I really don't want to get into an
16 endless argument about why people use webservices/etc.
17
18 > What does JSON / XML / etc. on top of HTTP(S) provide that SMTP doesn't
19 > provide?
20
21 It is what just about every other modern application in existence
22 uses. I'm sure there are hundreds of articles on the reasons for this
23 that are far better than anything I'd come up with here.
24
25 > > ... use more standard libraries/etc.
26 >
27 > There are many libraries to interface with SMTP.
28
29 And they don't work for anything OTHER than SMTP.
30
31 A library for JSON/webservices/whatever works for half the
32 applications being written today.
33
34
35 >
36 > Stop focusing on HTTP(S) <any version thereof> for a few minutes.
37 >
38 > If you were to create a new protocol from the ground up, why would you
39 > introduce additional layers into the application stack — which represent
40 > additional dependencies and complications — if you didn't have to?
41 >
42 > Not everything is a web server. Not everything can benefit from being
43 > forced through a web server.
44
45 This is simple. This is how just about EVERYBODY does it these days.
46 http works as a transport mechanism. And obviously when I say http I
47 mean http/https with the latter being preferred. That is the beauty
48 of standards like this - somebody else figured out SSL on top of HTTP
49 so we don't need an email-specific reimplementation of that.
50
51 I mean, why use TCP? Why not use something more tailored to email?
52 TCP probably has a dozen optional features that nobody uses with
53 email, so why implement all that just to send email?
54
55 The answer is that it makes WAY more sense to recycle a standard
56 protocol than to invent one. If SMTP didn't exist, and we needed a
57 way to post a bunch of data to a remote server, you'd use HTTP,
58 because it already works.
59
60 > > Most of the benefits only accrue if you adopt PKI as well, which is
61 > > a problem that is hard to scale out to the masses.
62 >
63 > PKI is relatively easy to scale. (For a given value.) Hence the
64 > thriving CA industry.
65 >
66 > Doing so in a trust worthy manner is the problem. Especially if you
67 > want to avoid a single point of control / failure / GEO political / etc.
68
69 It isn't just the trust problem. It is also the ease of use problem.
70
71 Let's assume you trust all the CAs out there. Why isn't anybody using
72 SSL for email? It is built into half the email clients out there.
73 The problem is that exchanging certificates at an individual level is
74 hard.
75
76 Oh, for an organization with an IT department it isn't a problem. The
77 IT department can just issue a certificate to everybody, generating
78 keys for them. Then it can stick all the certs in some kind of
79 directory that their email clients all use.
80
81 Getting your cousin to use SSL certs for their email is a whole
82 different matter. Heck, just using it between two different
83 companies, both supported by professional IT depts, is a pain. You
84 could use TLS for the transport itself and have the email servers
85 configured to only use TLS for those domains, but actually doing E2E
86 encryption is hard with email because there aren't a lot of standards
87 for key exchange across unrelated orgs.
88
89 > If we throw all the trusted CAs out the window, how do you /bootstrap/
90 > encrypted communications? - My personal opinion is DNS.
91 >
92
93 DNSSEC is:
94
95 1. Still poorly supported even where it makes sense.
96 2. A great hypothetical solution for the 0.002% of email users who
97 own a domain name, like you and me.
98
99 --
100 Rich

Replies

Subject Author
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins? Grant Taylor <gtaylor@×××××××××××××××××××××.net>