On 8/18/20 5:59 AM, Caveman Al Toraboran wrote:
redundant as in containing concepts already done in other protocols,
so smtp has many re-invented wheels that are already invented in
existing protocols.
Please elaborate. Please be careful to provide information about /when/
the protocols that SMTP is supposedly redundant of were developed.
I suspect that you will quickly find that SMTP predates the protocols
that you are stating it's redundant of. I further suspect that you will
find that SMTP predates them by 10, or more likely 20, if not 30 years.
Here's a hint. SMTP was ~82. HTTP (1.0) was ~89. We couldn't post
thing in HTTP 1.0. HTTP 2.0 was ~15.
basically smtp, as an application-layer protocol, is needless.
We are all entitled to our own opinion.
imo, smtp should be a much-higher level protocol defined purely on
top of how dns and http/2.
How do you get any higher layer than the application layer?
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.
HTTP /now/ has a way to submit data. HTTP didn't exist when SMTP was
developed. Further, HTTP didn't have the ability to submit data for a
while.
If you look at multiple layers of the network stack, HTTP and SMTP are
both at the application layer. Now you are suggesting moving equal
peers so that mail is subservient of / dependent on web?
Does HTTP or the web servers have the ability to queue messages to send
between systems? How many web servers handle routing of incoming
messages to send to other servers? How dynamic is this web server
configuration to allow servers for two people who have never exchanged
email to do so?
This routing, queuing, and many more features are baked into the email
ecosystem. Features that I find decidedly lacking in the web ecosystem.
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.
#1 and 2 are par for what we have today. No improvement.
3. then, the standard defines a http/2 request format to submit
the mail.
Given how things never die on the Internet, you're going to need both
SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive
email with people on the Internet.
So you now have a HUGE net negative in that you have the existing
service plus a new service. You're in many ways doubling the exposure
and security risk of email servers.
an example of step (3) could be this:
https://mail.dom.com/from=...&to=...&cc=...\
&bcc=...&subject=...&attach1=...&attach2=...\
&attachn=...
If you were to do this, you would NOT do it via GETs with URL
parameters. You would do it as POSTs.
You will also have to find a way to deal with all the aspects of SMTP
and RFC 822 email + mime. I suspect that you will find this to be
extremely tricky. Especially if you try to avoid SMTP / RFC 822
semantics b/c SMTP is apparently a bad thing.
How does your example scheme account for the fact that the SMTP envelope
from address frequently diff from the RFC 822 From: header? Remember,
this very feature is used thousands of times per day. So you have to
have it.
There's also many Many MANY other features of SMTP that are also used
thousands of times a day that I'm seeing no evidence of.
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
I ... I don't have the words. Go run that idea past an SEO expert.
Go ask people to drop their domain name in favor of a hash.
I'm not going to hold my breath.
How are you going to handle the billions of email clients that exist
today, many of which will never be updated, to handle ToR? You're going
to have to have something to gateway old and new.
That means that you're still going to have steps #1 and #2. You can't
get away from them without everybody and everything migrating to the new
system. Even then, chances are still extremely good that you're /still/
going to have #2.
and when a "mail" client tries to submit you an email, it submits it
by this url:
https://vagzgdrh747aei0q.onion/to=remco&...etc.
I haven't the words.
then, in order to authenticate a source, we simply use public-private
keys ...
Because that has worked out so well and with so few problems in the past
25 years.
... to sign messages.
Even /more/ unlikely to be ubiquitously adopted.
basically, our public keys become our user identifiers.
What?!
Now you are taking away the human friendly name in addition to the
domain name.
People are going to be lined up to hang you.
this will also solve the problem of the case when an onion address
changes.
I don't think so.
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.
There are a LOT of mechanics that need to be defined before they can
even be refined.
for people who use the deprecated smtp protocol, yes, it will be
"don't spam us, we'll spam you".
I think you'll find that your mail(fire)ball will be excommunicated form
the rest of the SMTP speaking Internet and never gain enough traction,
much less take over and become the norm.
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.
Oh, how graciously thoughtful of yo.... See my previous statement.
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.
LOL
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).
So, how will mail(fire)ball prevent me from creating as many key pairs
as I want and sending you a message from each and every one of them?
How does this do anything to prevent spam or viruses?
How well does your security hold up when, not if, someone creates a
gateway to make it trivial to send SMTP based email into mail(fire)ball?
It will happen just after mail(fire)ball gets just enough traction
that people scratch the surface to look at it. That is if it doesn't
happen as part of getting enough people Interested. Or even your own
""API that you are graciously providing.
--
Grant. . . .
unix || die
