On 8/27/20 7:00 AM, Caveman Al Toraboran wrote:
but i this way of looking at protocols (despite being common) is wrong.
Why do you think that it is wrong?
What is not factually correct about it?
i also disagree with the network layering proposed by osi or the
other ones commonly published in books. i specially disagree with
using such layering for studying the complexity of protocols.
If you're going to make such a statement, which is fine to do, you must
provide information ~> evidence as to why you are doing so and why you
think what you think.
so i suggest that if we want to study the complexity of messaging
systems, we better not count SMTP as a single thing (like how it is
normally done in books and talks), but instead talk about it based on
the fundamental tasks that it actually does. this way, SMTP becomes
at least 2 layers:
I think that I see part of a problem.
RFC 822 - Standard for the format of ARPA Internet Text Message - is
what defines what I was referring to as the opaque blob sent between
systems.
I will argue that the content of the opaque blob that SMTP transfers is
independent of SMTP itself.
1. "resource exchange" layer where binaries are made into a single
giant text file by base64 encoding and then partitioned by rfc822.
this part overlaps with http* and is much less efficient (rightfully,
since email had to be backwards compatible as it is critical).
SMTP* does not support binary in any (original) capacity. As such,
email service, which /rides/ /on/ /top/ /of/ SMTP, is where the encoding
""hack was placed. This /encoding/ and / or /formatting/ is completely
independent of the SMTP protocol used to exchange opaque blobs between
mail servers.
*I did elide some more modern SMTP extensions to simplify the previous
statement.
To whit: It is conceptually possible that there could be an SMTP
exchange consisting of the following:
S: Hello...
C: EHLO <client FQDN>
S: Nice to meet you...
C: MAIL FROM:<envelope from>
S: Okay. Continue
C: RCPT TO:<envelope recipient>
S: Okay. Continue
C: DATA
S: Okay. Continue
C:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
.
S: Okay. Thank you.
C: QUIT
S: Goodbye.
The XXX...XXX content is /OUTSIDE/ of the SMTP specification. That
content could conceptually be anything that you want it to be. The only
limitation is that the communications channel must safely support the
bit pattern and there must not be any way to cause confusion for the
protocol outside of it.
SMTP doesn't care /what/ the contents of the XXX...XXX is. SMTP's ob is
to exchange the XXX...XXX between servers based on the envelope from and
recipients.
Some, if not many, email servers have instituted sanity checks to make
sure that the XXX...XXX has some specific content (headers) and is well
formatted. But this sanity checking is outside of the SMTP protocol.
So, your "where binaries are made into a single giant text file by
base64 encoding and then partitioned by rfc822" is /NOT/ about SMTP.
Instead it is about RFC 822 - Internet Message Format.
SMTP is RFC 821 - Simple Mail Transfer Protocol
2. "resource use" where the mail server parses such exchanged resources
(e.g. email bodies, attachments, etc) and then acts upon them (e.g.
forward them, discard them, etc).
Again, this is outside of the SMTP protocol. It has nothing to do with
how the opaque blob is transferred between servers.
and so will pop* and imap.
I'm guessing that you are making a similar mistake with POP3 and IMAP.
Both POP3 and IMAP are also about transferring an opaque blob between
the email server and the client.
The base POP3 and IMAP protocol do not care what the contents of the
opaque blob are. Their goal is to get said opaque blob of XXX...XXX
from the email server to the client.
I say base protocol because I think there are some - what I'll call -
fancier POP3 and / or IMAP commands that can be issued to search and /
or retrieve messages based on content in the blob.
At their base, SMTP and POP3 and IMAP are about transferring opaque
blobs between servers.
In fact, they are the most recent replacement for alternative methods
for exchanging the same opaque blobs. Historically, SMTP replaced FTP
and UUCP for exchanging the same opaque blobs. Something could, and
probably eventually will, replace SMTP, POP3, and IMAP. But that has
not happened yet.
this way, if we ignore the problem of maintaining backwards
compatibility,
That is a HUGE if. One that I do not accept at all. You absolutely
*MUST* have backwards compatibility in some way. Even if that
compatibility is something that acts as an edge gateway between SMTP and
your new method. You MUST have backward compatibility in some way.
then having http* in the "resource exchange" layer would be more
efficient and simpler as there will be less protocols doing the
"resource exchange" task (instead of having each do its own).
So you want to take two completely different protocols that serve two
completely different functions and force them into a third completely
different protocol that serve yet another completely different function.
I feel the need to back up and call out what HTTP is. (HTTPS included
because it's really just HTTP wrapped in encryption.)
C: HTTP/1(.0)
C: GET <path>
S:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
S: 200 ...
Notice how the HTTP /protocol/ doesn't care what the opaque blob is either.
Also notice how there is no exchange about who the message is from or
two either. This might not seem like a problem. But what happens when
i start sending you an email from someone you won't accept or to one or
more recipients that you won't accept? I'm still sending you the email.
You have to receive it, process it, and then reject it. This is a
HUGE vector for a denial of service.
You might be able to do each client & server exchange as separate requests.
C: HTTP/1(.0)
C: GET /path/that/encodes/from
C: XXX...XXX
S: <return code>
C: GET /path/that/encodes/recipient
C: XXX...XXX
S: <return code>
C: GET /path/that/encodes/message-body
C: XXX...XXX
S: <return code>
Now you're getting REALLY close to SMTP run through a find and replace
filter.
i also think that the kind of resource that email exchanges is
fundamentally identical to a subset of resources that are natively
exchanged in the web.
As stated above, that's the opaque blob that SMTP exchanges. I has
nothing to do with the Simple Mail Transfer /Protocol/.
The /protocol/ is about /how/ things are exchanged. The /protocol/ is
*NOT* about /what/ is exchanged.
I feel like you genuinely believe what you are saying. I also feel like
you are tilting at the /wrong/ windmill.
so i think the only reason that smtp/pop/imap have different resource
exchange protocols is purely due to backwards compatibility due to
how things evolved historically.
It's not backwards compatibility.
SMTP is for sending email from server to server.
POP3 is about pulling email from a single mailbox down to the local client.
IMAP is about remotely accessing multiple different mailboxes on a
remote server.
They do three fundamentally different things.
SMTP is akin to the postal service exchanging post between businesses.
POP3 is you collecting email from your inbox in the mail room and taking
it back to your desk.
IMAP is you going to the file room to access a file in one of the many
file cabinets.
They are very different actions on what is potentially the same content.
But what is done and how it is done is completely different.
i suspect that we actually agree on everything, but speak different
languages (possibly due to how books commonly talk about protocols
and layering), or assume things beyond what's written.
No. We definitely do NOT agree on everything.
I'll thank you for not altering what I say / think / believe.
e.g. we agree that:
1. smtp/pop*/imap make the best messaging system today,
So why are you trying to change them if they are the "best messaging
system today"?
and is not going away any time soon, thanks to its wide spread.
Absolutely.
most likely i'll be dead and still have multiple active smtp/imap/pop
account.
2. smtp/imap/pop are imperfect and have many shortcomings
I believe that SMTP can adequately address current needs.
I believe that IMAP does things very well. I have no issues at all with
IMAP.
I believe that POP3 does what it does quite well. I have no issues at
all with POP3.
that are "rightfully" not solved "cleanly" due to historical reasons
I don't like that statement. Something about it doesn't seem accurate
to me.
and its critical nature which imposed on us the constraint of having
to maintaining its backwards compatibility.
You are completely free to do your own completely independent thing.
Just know that in doing so, you are very likely not going to have people
adopt it without some interoperability.
3. trying new protocols is fine. and is also fine to have
sub-communities that use different messaging protocols if they find
it more fitting.
Sure.
We already have that today.
e.g. i'll probably end up using smtp/imap for talking to people
in general, and use hillarymail [1] for talking to a closer nerdy
community.
To each their own.
--
Grant. . . .
unix || die
