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. n...@dom.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
