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

[Grant Taylor]

On 8/21/20 10:11 PM, Caveman Al Toraboran wrote:
> not a major point but just to clarify a thing.
>
> i think it's unfair to look at SMTP as a single thing that compares
> against HTTP*.  because while HTTP* is a single-ish thing, SMTP is
> several things.  i.e. SMTP is at least 2 parts:

Fair point.

As I see it, we have two things; 1) what is transferred (email message) 
and 2) how it is transferred (SMTP, UUCP, etc.).

> 1. resource exchange layer where people are defined as some kind of
> URL (e.g.  name@×××.zone) and attachments are base64-ed text balls
> referred to by some numbers in RFC822.

That sounds like the "what is transferred" to me.

As in the opaque value of the sender / recipient / body / attachments. 
It does not matter what the contents of those opaque values are.  They 
make up what is transferred.

> This part overlaps with HTTP*.  let's call this "RESXCH_SERVER".

HTTP(S) can overlap with the "how" part of the transfer.

But I believe that the HTTP(S) "how" part is independent of the opaque 
blob part of "what".

> 2. the part where it defines how to process the exchanged resources
> (e.g. safe storage, routing, etc).  this part is beyond HTTP*'s scope,
> and is the "web app" scope.  let's call this "RESUSE_SERVER"

Okay.

> of course, email still doesn't work with those 2 parts, because you
> need a way to get mails to your email client, so you end up using
> POP or IMAP.  now, this --itself-- is also two parts:

That is highly dependent on your email client.  Many traditional Unix 
email clients read email directly off the file system of the email server.

In fact, most POP3(S) and IMAP(S) implementations read the same data off 
of the email server.  The only difference being that the allow the email 
client to be remote from the email server.

I'd like to point out that thus far this thread has been about how to 
get email between email servers.  As such, I think client access 
protocols are somewhat outside of the existing scope.

> 1. resource exchange layer to send resources to users.  which also
> overlaps with HTTP* (again).  let's call this "RESXCH_CLIENT".

The "how".

> 2. the part where it defines how the mail client to treat the
> resources.  let's call this "RESUSE_CLIENT".

See above comment about scope.

This is also a "how".  But "how" clients get email from servers is 
decidedly different than "how" servers exchange email.

They can both use any underlying transport, be it TCP (like POP3 & IMAP) 
or HTTP(S).

> i disagree.  i think this is more like it about the current email
> system:
>
> RESXCH_SERVER / RESUSE_SERVER / RESXCH_CLIENT / RESUSE_CLIENT

I'm having trouble unpacking that.  So I'll provide my version of what I 
think you're trying to say.

Since all of this rides on top of TCP, I'm not going to call it out.

1)  The sender (who-sender) sends their email (what) to their outbound 
email server (who-recipient) with SMTP (how).

2)  (The sender's) outbound server (who-sender) sends (the sender's) 
email (what) to the (the recipient's) inbound server (who-recipient) 
with SMTP (how).

3)  The recipient (who-recipient) pulls email (what) from their inbound 
server (who-sender) with POP3S / IMAPS (how).

Notice how we have a what, who-sender, who-recipient, and how in each of 
these.  The who-sender and who-recipient are the parties of each 
discrete conversation; 1, 2, or 3.

Notice how the what (email) is an opaque blob on each leg of the 
transmission journey.

There are four distinct points with three distinct paths in between.

A)   [1]---(SMTP)---[2]---(SMTP)---[3]---(POP3S/IMAPS)---[4]

1) Person sending the email.
2) #1's email server.
4) Person receiving the email.
3) #4's email server.

(Yes I know those are not in numerical order.  #3 and #4 are in 
dependency order.)

The only way to remove a point and transmission path from this process 
end-to-end process is for #2 and #3 to be the same.

B)   [1]---(SMTP)---[2/3]---(POP3S/IMAPS)---[4]

Other than mega email providers; Google, Microsoft, Yahoo, et al., you 
are going to have scenario A above.

Each step of the way you have what is transferred (the message) and how 
it is transferred (the protocol) between two points.

The what (email) is still an opaque blob on each leg of the transfer.

> it's 4 different layers to exchange mail between people.

We apparently aren't using layers the same way.  You seem to be using 
layers in place of hops.  That is both inaccurate and unfair for a 
number of reasons.

There can be any number of additional hops in between # 2 & 3 above for 
any number of reasons; legal, technical, political, etc.

> but if we plug HTTP* in the mix, it because only 3 different layers:
>
> HTTP* / RESUSE_SERVER / HTTP* / RESUSE_CLIENT

You also seem to be describing scenario B above.

Here is a variation on scenario A above that is completely realistic if 
not probable.

C) 
[1]---(SMTP)---[2]---(SMTP)---[3]---(SMTP)---[4]---(SMTP)---[5]---(SMTP)---[6]---(POP3S/IMAPS)---[7]

1)  The person sending the email.
2)  The person sending the email's work SMTP server.
3)  The ESP server that the sender's employer is using.  E.g. their ISP 
or SendGrid.
5)  The ESP server that the recipients employer is using.  E.g. Postini 
or MailRoute.
6)  The person receiving the email's work SMTP server.
7)  The person receiving the email.

This completely realistic scenario is more hops but still the same 
number of layers as scenarios A and B above.

Scenario A with some layering detail.

            email         email         email
            SMTP          SMTP          POP3S/IMAPS
A)   [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4]

Now what you are proposing:



            email         email         email
             TBD           TBD           TBD
            HTTPS         HTTPS         HTTPS
A)   [1]---(TCP)---[2]---(TCP)---[3]---(TCP)---[4]

The number of layers has increased from three to four.

The number of hops in the path doesn't matter.

You can freely replace TCP with UDP (QUIC) or some other transport layer.

You are free to define your own email exchange protocol in place of TBD 
in the lower of the two layered diagrams.

The email layer (opaque contents of the message) is effectively the 
same.  How it's executed doesn't really matter.

You can't get around the fact that you have /added/ a layer to the stack 
in between the transport and the email exchange protocol.

I have not heard any compelling reasons for adding HTTPS in between the 
email transport protocol (SMTP / TBD) and the underlying network 
transport protocol (TCP / UDP / ...).

The only reasons that I have heard are:  "there are more libraries" 
which for me translates to "it's easier (for the developer)" which 
translates to "laziness".

NONE of these reasons qualify as "easier" or "better" for email 
administrators / the email ecosystem to migrate.

> and it is even nicer for when HTTP* is plugged, because it is also
> the protocol used for most of internet's traffic (web browsing).

It may be the protocol that you see.  Trust me when I say that the World 
Wide Web (which is predominantly HTTP(S)) is a subset of the Internet 
(which is many, Many, MANY other protocols).

Email and DNS are probably the most visible things on the Internet that 
aren't part of the World Wide Web.

> so basically total expected number of protocols/layers used in the
> universe, per second, will be much less if we, on planet earth,
> use a mail system that uses HTTP* instead of RESXCH_*.

I obviously disagree.



-- 
Grant. . . .
unix || die