| 1 |
On 8/27/20 7:00 AM, Caveman Al Toraboran wrote: |
| 2 |
> but i this way of looking at protocols (despite being common) is wrong. |
| 3 |
|
| 4 |
Why do you think that it is wrong? |
| 5 |
|
| 6 |
What is not factually correct about it? |
| 7 |
|
| 8 |
> i also disagree with the network layering proposed by osi or the |
| 9 |
> other ones commonly published in books. i specially disagree with |
| 10 |
> using such layering for studying the complexity of protocols. |
| 11 |
|
| 12 |
If you're going to make such a statement, which is fine to do, you must |
| 13 |
provide information ~> evidence as to why you are doing so and why you |
| 14 |
think what you think. |
| 15 |
|
| 16 |
> so i suggest that if we want to study the complexity of messaging |
| 17 |
> systems, we better not count SMTP as a single thing (like how it is |
| 18 |
> normally done in books and talks), but instead talk about it based on |
| 19 |
> the fundamental tasks that it actually does. this way, SMTP becomes |
| 20 |
> at least 2 layers: |
| 21 |
|
| 22 |
I think that I see part of a problem. |
| 23 |
|
| 24 |
RFC 822 - Standard for the format of ARPA Internet Text Message - is |
| 25 |
what defines what I was referring to as the opaque blob sent between |
| 26 |
systems. |
| 27 |
|
| 28 |
I will argue that the content of the opaque blob that SMTP transfers is |
| 29 |
independent of SMTP itself. |
| 30 |
|
| 31 |
> 1. "resource exchange" layer where binaries are made into a single |
| 32 |
> giant text file by base64 encoding and then partitioned by rfc822. |
| 33 |
> this part overlaps with http* and is much less efficient (rightfully, |
| 34 |
> since email had to be backwards compatible as it is critical). |
| 35 |
|
| 36 |
SMTP* does not support binary in any (original) capacity. As such, |
| 37 |
email service, which /rides/ /on/ /top/ /of/ SMTP, is where the encoding |
| 38 |
""hack was placed. This /encoding/ and / or /formatting/ is completely |
| 39 |
independent of the SMTP protocol used to exchange opaque blobs between |
| 40 |
mail servers. |
| 41 |
|
| 42 |
*I did elide some more modern SMTP extensions to simplify the previous |
| 43 |
statement. |
| 44 |
|
| 45 |
To whit: It is conceptually possible that there could be an SMTP |
| 46 |
exchange consisting of the following: |
| 47 |
|
| 48 |
S: Hello... |
| 49 |
C: EHLO <client FQDN> |
| 50 |
S: Nice to meet you... |
| 51 |
C: MAIL FROM:<envelope from> |
| 52 |
S: Okay. Continue |
| 53 |
C: RCPT TO:<envelope recipient> |
| 54 |
S: Okay. Continue |
| 55 |
C: DATA |
| 56 |
S: Okay. Continue |
| 57 |
C: |
| 58 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 59 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 60 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 61 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 62 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 63 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 64 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 65 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 66 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 67 |
. |
| 68 |
S: Okay. Thank you. |
| 69 |
C: QUIT |
| 70 |
S: Goodbye. |
| 71 |
|
| 72 |
The XXX...XXX content is /OUTSIDE/ of the SMTP specification. That |
| 73 |
content could conceptually be anything that you want it to be. The only |
| 74 |
limitation is that the communications channel must safely support the |
| 75 |
bit pattern and there must not be any way to cause confusion for the |
| 76 |
protocol outside of it. |
| 77 |
|
| 78 |
SMTP doesn't care /what/ the contents of the XXX...XXX is. SMTP's ob is |
| 79 |
to exchange the XXX...XXX between servers based on the envelope from and |
| 80 |
recipients. |
| 81 |
|
| 82 |
Some, if not many, email servers have instituted sanity checks to make |
| 83 |
sure that the XXX...XXX has some specific content (headers) and is well |
| 84 |
formatted. But this sanity checking is outside of the SMTP protocol. |
| 85 |
|
| 86 |
So, your "where binaries are made into a single giant text file by |
| 87 |
base64 encoding and then partitioned by rfc822" is /NOT/ about SMTP. |
| 88 |
Instead it is about RFC 822 - Internet Message Format. |
| 89 |
|
| 90 |
SMTP is RFC 821 - Simple Mail Transfer Protocol |
| 91 |
|
| 92 |
> 2. "resource use" where the mail server parses such exchanged resources |
| 93 |
> (e.g. email bodies, attachments, etc) and then acts upon them (e.g. |
| 94 |
> forward them, discard them, etc). |
| 95 |
|
| 96 |
Again, this is outside of the SMTP protocol. It has nothing to do with |
| 97 |
how the opaque blob is transferred between servers. |
| 98 |
|
| 99 |
> and so will pop* and imap. |
| 100 |
|
| 101 |
I'm guessing that you are making a similar mistake with POP3 and IMAP. |
| 102 |
|
| 103 |
Both POP3 and IMAP are also about transferring an opaque blob between |
| 104 |
the email server and the client. |
| 105 |
|
| 106 |
The base POP3 and IMAP protocol do not care what the contents of the |
| 107 |
opaque blob are. Their goal is to get said opaque blob of XXX...XXX |
| 108 |
from the email server to the client. |
| 109 |
|
| 110 |
I say base protocol because I think there are some - what I'll call - |
| 111 |
fancier POP3 and / or IMAP commands that can be issued to search and / |
| 112 |
or retrieve messages based on content in the blob. |
| 113 |
|
| 114 |
At their base, SMTP and POP3 and IMAP are about transferring opaque |
| 115 |
blobs between servers. |
| 116 |
|
| 117 |
In fact, they are the most recent replacement for alternative methods |
| 118 |
for exchanging the same opaque blobs. Historically, SMTP replaced FTP |
| 119 |
and UUCP for exchanging the same opaque blobs. Something could, and |
| 120 |
probably eventually will, replace SMTP, POP3, and IMAP. But that has |
| 121 |
not happened yet. |
| 122 |
|
| 123 |
> this way, if we ignore the problem of maintaining backwards |
| 124 |
> compatibility, |
| 125 |
|
| 126 |
That is a HUGE if. One that I do not accept at all. You absolutely |
| 127 |
*MUST* have backwards compatibility in some way. Even if that |
| 128 |
compatibility is something that acts as an edge gateway between SMTP and |
| 129 |
your new method. You MUST have backward compatibility in some way. |
| 130 |
|
| 131 |
> then having http* in the "resource exchange" layer would be more |
| 132 |
> efficient and simpler as there will be less protocols doing the |
| 133 |
> "resource exchange" task (instead of having each do its own). |
| 134 |
|
| 135 |
So you want to take two completely different protocols that serve two |
| 136 |
completely different functions and force them into a third completely |
| 137 |
different protocol that serve yet another completely different function. |
| 138 |
|
| 139 |
I feel the need to back up and call out what HTTP is. (HTTPS included |
| 140 |
because it's really just HTTP wrapped in encryption.) |
| 141 |
|
| 142 |
C: HTTP/1(.0) |
| 143 |
C: GET <path> |
| 144 |
S: |
| 145 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 146 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 147 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| 148 |
|
| 149 |
S: 200 ... |
| 150 |
|
| 151 |
Notice how the HTTP /protocol/ doesn't care what the opaque blob is either. |
| 152 |
|
| 153 |
Also notice how there is no exchange about who the message is from or |
| 154 |
two either. This might not seem like a problem. But what happens when |
| 155 |
i start sending you an email from someone you won't accept or to one or |
| 156 |
more recipients that you won't accept? I'm still sending you the email. |
| 157 |
You have to receive it, process it, and then reject it. This is a |
| 158 |
HUGE vector for a denial of service. |
| 159 |
|
| 160 |
You might be able to do each client & server exchange as separate requests. |
| 161 |
|
| 162 |
C: HTTP/1(.0) |
| 163 |
C: GET /path/that/encodes/from |
| 164 |
C: XXX...XXX |
| 165 |
S: <return code> |
| 166 |
C: GET /path/that/encodes/recipient |
| 167 |
C: XXX...XXX |
| 168 |
S: <return code> |
| 169 |
C: GET /path/that/encodes/message-body |
| 170 |
C: XXX...XXX |
| 171 |
S: <return code> |
| 172 |
|
| 173 |
Now you're getting REALLY close to SMTP run through a find and replace |
| 174 |
filter. |
| 175 |
|
| 176 |
> i also think that the kind of resource that email exchanges is |
| 177 |
> fundamentally identical to a subset of resources that are natively |
| 178 |
> exchanged in the web. |
| 179 |
|
| 180 |
As stated above, that's the opaque blob that SMTP exchanges. I has |
| 181 |
nothing to do with the Simple Mail Transfer /Protocol/. |
| 182 |
|
| 183 |
The /protocol/ is about /how/ things are exchanged. The /protocol/ is |
| 184 |
*NOT* about /what/ is exchanged. |
| 185 |
|
| 186 |
I feel like you genuinely believe what you are saying. I also feel like |
| 187 |
you are tilting at the /wrong/ windmill. |
| 188 |
|
| 189 |
> so i think the only reason that smtp/pop/imap have different resource |
| 190 |
> exchange protocols is purely due to backwards compatibility due to |
| 191 |
> how things evolved historically. |
| 192 |
|
| 193 |
It's not backwards compatibility. |
| 194 |
|
| 195 |
SMTP is for sending email from server to server. |
| 196 |
POP3 is about pulling email from a single mailbox down to the local client. |
| 197 |
IMAP is about remotely accessing multiple different mailboxes on a |
| 198 |
remote server. |
| 199 |
|
| 200 |
They do three fundamentally different things. |
| 201 |
|
| 202 |
SMTP is akin to the postal service exchanging post between businesses. |
| 203 |
|
| 204 |
POP3 is you collecting email from your inbox in the mail room and taking |
| 205 |
it back to your desk. |
| 206 |
|
| 207 |
IMAP is you going to the file room to access a file in one of the many |
| 208 |
file cabinets. |
| 209 |
|
| 210 |
They are very different actions on what is potentially the same content. |
| 211 |
But what is done and how it is done is completely different. |
| 212 |
|
| 213 |
> i suspect that we actually agree on everything, but speak different |
| 214 |
> languages (possibly due to how books commonly talk about protocols |
| 215 |
> and layering), or assume things beyond what's written. |
| 216 |
|
| 217 |
No. We definitely do NOT agree on everything. |
| 218 |
|
| 219 |
I'll thank you for not altering what I say / think / believe. |
| 220 |
|
| 221 |
> e.g. we agree that: |
| 222 |
> |
| 223 |
> 1. smtp/pop*/imap make the best messaging system today, |
| 224 |
|
| 225 |
So why are you trying to change them if they are the "best messaging |
| 226 |
system today"? |
| 227 |
|
| 228 |
> and is not going away any time soon, thanks to its wide spread. |
| 229 |
|
| 230 |
Absolutely. |
| 231 |
|
| 232 |
> most likely i'll be dead and still have multiple active smtp/imap/pop |
| 233 |
> account. |
| 234 |
> |
| 235 |
> 2. smtp/imap/pop are imperfect and have many shortcomings |
| 236 |
|
| 237 |
I believe that SMTP can adequately address current needs. |
| 238 |
|
| 239 |
I believe that IMAP does things very well. I have no issues at all with |
| 240 |
IMAP. |
| 241 |
|
| 242 |
I believe that POP3 does what it does quite well. I have no issues at |
| 243 |
all with POP3. |
| 244 |
|
| 245 |
> that are "rightfully" not solved "cleanly" due to historical reasons |
| 246 |
|
| 247 |
I don't like that statement. Something about it doesn't seem accurate |
| 248 |
to me. |
| 249 |
|
| 250 |
> and its critical nature which imposed on us the constraint of having |
| 251 |
> to maintaining its backwards compatibility. |
| 252 |
|
| 253 |
You are completely free to do your own completely independent thing. |
| 254 |
Just know that in doing so, you are very likely not going to have people |
| 255 |
adopt it without some interoperability. |
| 256 |
|
| 257 |
> 3. trying new protocols is fine. and is also fine to have |
| 258 |
> sub-communities that use different messaging protocols if they find |
| 259 |
> it more fitting. |
| 260 |
|
| 261 |
Sure. |
| 262 |
|
| 263 |
We already have that today. |
| 264 |
|
| 265 |
> e.g. i'll probably end up using smtp/imap for talking to people |
| 266 |
> in general, and use hillarymail [1] for talking to a closer nerdy |
| 267 |
> community. |
| 268 |
|
| 269 |
To each their own. |
| 270 |
|
| 271 |
|
| 272 |
|
| 273 |
-- |
| 274 |
Grant. . . . |
| 275 |
unix || die |
Archives