Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?

[Grant Taylor]

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@××××××××××××××××.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