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

[Rich Freeman]

On Thu, Aug 20, 2020 at 9:39 PM Caveman Al Toraboran
<toraboracaveman@××××××××××.com> wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, August 20, 2020 11:41 AM, antlists <antlists@××××××××××××.uk> wrote:
>
> > Will that python script allow for the situation that the message is
> > received, but the message was NOT safely stored for onwards transmission
> > before the receiver crashed, and as such the message has not been
> > SUCCESSFULLY received?
> >
> > SMTP has lots of things specifically meant to ensure messages survive
> > the internet jungle on their journey ...
>
> thanks for the point.  would it suffice if we have
> these notifications:
>
>     1. receipt by final mail server (mandatory).
>     2. receipt by end user(s) (optional).
>     3. opening by end user(s) (optional).
>

I don't really want to get into the gory details and have only skimmed
the discussion, but my sense is that you're talking about a new way to
deliver mail that makes two sorts of changes:

1. Modernizing the actual data exchange using http/etc.
2. Changing the model around email moving to something more
PKI-based/etc and redefining what an email address is.

This stuff can be interesting to discuss, but email is SO entrenched
that I don't see any of this changing because of all the legacy
issues.  You would need to offer something that is both easier and
better to use to such a degree that people are willing to change.

However, I'll comment on both of these issues:

1. Modernizing the actual data exchange using http/etc.

I don't think you'll get much argument that SMTP isn't the way
somebody would do things if they were designing everything from
scratch.  I'm not an API expert but I imagine that just about any of
the modern alternatives would be an improvement.  http would be a
pretty likely protocol to handle the transportation, likely with
something like JSON/xml/etc carrying the payload.  You might want to
tweak things slightly so that recipient validity can be tested prior
to transferring data.  A mail server doesn't want to accept a 20MB
encrypted payload if it can bounce the whole message based on the
recipient or a non-authenticated sender or whatever.  However, in
principle there are plenty of modern ways to build a transport
protocol that would be an improvement on SMTP and use more standard
libraries/etc.

I think this is actually the part of your proposal that might be more
likely to take off.  You could have a new type of MX field in DNS and
if it is set then it defines servers that will use the new protocol,
and you could have backup SMTP servers for legacy transition.  You
could change the transport side of things without redefining how email
works, so the same messages are interoperable with both systems.

On the flip side, while I think this is an easier change to make, I
don't think it necessarily offers huge improvements.  SMTP still gets
the job done, and the new system wouldn't really be a major
improvement from a sysadmin standpoint, so I don't see everybody
running out to change.  Just changing the transport protocols doesn't
provide any anti-spam/etc benefits.  SMTP already supports TLS so it
isn't any more secure.  No doubt if we were starting from scratch this
is how it would be done, but it isn't enough of a reason to change.
That said, if there were even modest benefits for large mail providers
I could see it taking off simply because it could leverage a lot of
existing libraries and standards, and could have legacy compatibility.

2. Changing the model around email moving to something more
PKI-based/etc and redefining what an email address is.

This is where you could have revolutionary improvements for
privacy/spam/etc.  However, it completely breaks everything that
exists with email today, so it is a hard change.  Most of the benefits
only accrue if you adopt PKI as well, which is a problem that is hard
to scale out to the masses.

If somebody comes up with a way to make PKI take off in a real way,
then I could see something like this taking off eventually.
Otherwise, this stuff is only going to be of interest to the sorts who
use gpg to sign their email, and nobody else.

-- 
Rich