‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, August 18, 2020 2:21 PM, Remco Rijnders <re...@webconquest.com>
wrote:
> On Tue, Aug 18, 2020 at 07:00:52AM +0000, Caveman wrote in
>
> > yes. smtp is nasty, and also redundant.
>
> How is it redundant?
redundant as in containing concepts already done
in other protocols, so smtp has many re-invented
wheels that are already invented in existing
protocols. basically smtp, as an application-layer
protocol, is needless. imo, smtp should be a
much-higher level protocol defined purely on top of
how dns and http/2.
e.g. for mail submission, there is no need for a
separate application-layer protocol as we can
simply use http/2. because the concept of mail
submission is a special case of data submission,
which is already in http/2.
here is a more complete example of what i mean:
1. we lookup MX records to identify smtp servers
to submit mails to.
2. from the response to that lookup we get a
domain name, say, mail.dom.com.
3. then, the standard defines a http/2 request
format to submit the mail.
an example of step (3) could be this:
https://mail.dom.com/from=...&to=...&cc=...\
&bcc=...&subject=...&attach1=...&attach2=...\
&attachn=...
i don't know how http/2 works. do they have
POST requests? if so maybe fields attach1,
attach2, ..., attachn can be submitted as file
uploads using POST.
further, if we modify steps (1) and (2), we can
generalise this concept into tor services. e.g.
an email address simply becomes an onion address.
e.g. if vagzgdrh747aei0q.onion is the hidden
service address of your mail server, then your
email address could be written as (for convenience):
remco@vagzgdrh747aei0q.onion
and when a "mail" client tries to submit you an
email, it submits it by this url:
https://vagzgdrh747aei0q.onion/to=remco&...etc.
then, in order to authenticate a source, we simply
use public-private keys to sign messages.
basically, our public keys become our user
identifiers. this will also solve the problem of
the case when an onion address changes.
i call this protocol mailball for the purpose of
making speech this mail thread a bit easier. of
course, we can pick better names, and refine the
mechanics.
> > makes me wonder if i should just create me a
> > hidden tor service that is just a normal website,
> > and give its url to people (instead of email) who
> > want to message me by telling them ``submit your
> > messages to me''. then, verify messages by
> > mailing their supplied email a confirmation
> > message.
>
> Ah, the "Don't spam us, we'll spam you approach?"
for people who use the deprecated smtp protocol, yes,
it will be "don't spam us, we'll spam you".
however, that's not our fault. they are using a
deprecated protocol, and we are just kind enough
to allow them an opportunity to talk to us over
the superior mailball protocol. basically, they
are using deprecated identifiers (email ids)
instead of public keys, and we're kind enough to
give them a temporary api so that we confirm their
emails.
on the other hand, people who use mailball will
not have this problem. why? because ids are
public keys anyway, and their messages are signed
by their private keys (the usual drill, won't
insult your intelligence).
