1 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ |
2 |
On Tuesday, August 18, 2020 2:21 PM, Remco Rijnders <remco@×××××××××××.com> wrote: |
3 |
|
4 |
> On Tue, Aug 18, 2020 at 07:00:52AM +0000, Caveman wrote in |
5 |
> |
6 |
> > yes. smtp is nasty, and also redundant. |
7 |
> |
8 |
> How is it redundant? |
9 |
|
10 |
redundant as in containing concepts already done |
11 |
in other protocols, so smtp has many re-invented |
12 |
wheels that are already invented in existing |
13 |
protocols. basically smtp, as an application-layer |
14 |
protocol, is needless. imo, smtp should be a |
15 |
much-higher level protocol defined purely on top of |
16 |
how dns and http/2. |
17 |
|
18 |
e.g. for mail submission, there is no need for a |
19 |
separate application-layer protocol as we can |
20 |
simply use http/2. because the concept of mail |
21 |
submission is a special case of data submission, |
22 |
which is already in http/2. |
23 |
|
24 |
here is a more complete example of what i mean: |
25 |
|
26 |
1. we lookup MX records to identify smtp servers |
27 |
to submit mails to. |
28 |
2. from the response to that lookup we get a |
29 |
domain name, say, mail.dom.com. |
30 |
3. then, the standard defines a http/2 request |
31 |
format to submit the mail. |
32 |
|
33 |
an example of step (3) could be this: |
34 |
|
35 |
https://mail.dom.com/from=...&to=...&cc=...\ |
36 |
&bcc=...&subject=...&attach1=...&attach2=...\ |
37 |
&attachn=... |
38 |
|
39 |
i don't know how http/2 works. do they have |
40 |
POST requests? if so maybe fields attach1, |
41 |
attach2, ..., attachn can be submitted as file |
42 |
uploads using POST. |
43 |
|
44 |
further, if we modify steps (1) and (2), we can |
45 |
generalise this concept into tor services. e.g. |
46 |
an email address simply becomes an onion address. |
47 |
e.g. if vagzgdrh747aei0q.onion is the hidden |
48 |
service address of your mail server, then your |
49 |
email address could be written as (for convenience): |
50 |
|
51 |
remco@××××××××××××××××.onion |
52 |
|
53 |
and when a "mail" client tries to submit you an |
54 |
email, it submits it by this url: |
55 |
|
56 |
https://vagzgdrh747aei0q.onion/to=remco&...etc. |
57 |
|
58 |
then, in order to authenticate a source, we simply |
59 |
use public-private keys to sign messages. |
60 |
basically, our public keys become our user |
61 |
identifiers. this will also solve the problem of |
62 |
the case when an onion address changes. |
63 |
|
64 |
i call this protocol mailball for the purpose of |
65 |
making speech this mail thread a bit easier. of |
66 |
course, we can pick better names, and refine the |
67 |
mechanics. |
68 |
|
69 |
> > makes me wonder if i should just create me a |
70 |
> > hidden tor service that is just a normal website, |
71 |
> > and give its url to people (instead of email) who |
72 |
> > want to message me by telling them ``submit your |
73 |
> > messages to me''. then, verify messages by |
74 |
> > mailing their supplied email a confirmation |
75 |
> > message. |
76 |
> |
77 |
> Ah, the "Don't spam us, we'll spam you approach?" |
78 |
|
79 |
for people who use the deprecated smtp protocol, yes, |
80 |
it will be "don't spam us, we'll spam you". |
81 |
|
82 |
however, that's not our fault. they are using a |
83 |
deprecated protocol, and we are just kind enough |
84 |
to allow them an opportunity to talk to us over |
85 |
the superior mailball protocol. basically, they |
86 |
are using deprecated identifiers (email ids) |
87 |
instead of public keys, and we're kind enough to |
88 |
give them a temporary api so that we confirm their |
89 |
emails. |
90 |
|
91 |
on the other hand, people who use mailball will |
92 |
not have this problem. why? because ids are |
93 |
public keys anyway, and their messages are signed |
94 |
by their private keys (the usual drill, won't |
95 |
insult your intelligence). |