John C Klensin wrote:
--On Saturday, September 03, 2011 03:23 -0400 Hector
<sant9442(_at_)gmail(_dot_)com> wrote:
You might this reading interesting by Chuck Forberg of the
early comm issues, including UUCP, leading up to his
development of ZMODEM:
http://www.omen.com/zmdmev.html
Saw it when it came out. Chuck hurt his case a bit by those who
knew both sides by going a little over the top in his outrage
(e.g., claiming that Columbia's non-profit mailing certificate
is equivalent to mailing at public expense). Frank responded by
going over the top too, which didn't help -- Kermit's main
strength was transfers among dissimilar machines with option
negotiation, especially with dissimilar character sets or other
data encodings, while X/Y/ZMODEM assumed either homogeneity or a
"get information about encodings out of band and then sort it
out at the endpoints" logic. ...
My memory with this was mostly: used Columbia Kermit for testing SSL
TELNET & Kermit protocol implementation and for recommending it to
customers with SSL Telnet needs; Mostly unix clients that used it,
probably universities; Was not impressed with performance, i.e. more
problems reported. If I remember mostly related to Window sizes and
different client/server kermit versions. I think it worked better
under RLOGIN as the other XYZ protocols. ZMODEM and even YMODEM-G1K
was excellent and for batching. I never saw problems as you described
with ZMODEM over any wire, but ultimately not as efficient with a TCP
stream since TCP already did the error corrections.
This is a typical arrangement with higher end customers:
TCP/Dialup --> PBX/TELCO --> CommServer --> TCP services
TCP Services could be RLogin, FTP, HTTP, SMTP, POP3. Customer
programmed methods. CommServers includes many vendors such older EICON
(Dialogic), Cisco, Pattons (like these) routers and others. With
automated dialup text based console scripts already done for dialup,
clients did not lose with a passive dialup virtual comm to RLOGIN.
The backend was now able to start reducing modem banks.
- RFC822 headers resolved major issues with Kludge lines
(network control lines) in the Fidonet mail format,
I would add that the introduction of really clear boundaries
between applications-layer transport and message functions
(i.e., the invention of the envelope-message distinction) was
also important and, ultimately simplifying (even though, in
retrospect, they got the details wrong)
That is what I meant with FTN1 packets, which had:
Fixed FTN1 block
^A control lines (routing/sender/reply addresses
msgid, pid, etc)
Message Body
--- [31 bytes MailerID] <--- required tear line with brag line
^A SeenBy lines for distribution and dupe protection
Fixed FTN1 block
...
As far as adding more commands is concerned... yes, but doing so
caused horrible interoperability problems, resulting in our
having to invent the rather complex EHLO handshake mechanisms in
order to take advantage of that flexibility.
I only added EHLO after you were finished with RFC2821 :) but with
821, some proprietary local only helpdesk, stats, debug, dumps, etcs
commands were added.
What the Internet had instead was Postel's robustness principle
and its aggressive (perhaps excessive) application to making email work.
Its a natural principle applicable to many areas. I had a "Flow
Control" rule of thumb for RS232:
Send LOW, Receive HIGH
Receivers know how much they handle, but they know what the other side
can handle. Another thing you
didn't have to worry with TCP using the same receive/transmit packet size.
Having worked for a couple of phone companies, I think they (and
lots of others, of course) are deluding themselves when they
assume that the PSTN is inherently more secure than a
properly-set-up IP-based arrangement, especially with
distributed routing.
+1 I keep quiet on that! I just presumed different trunk lines were
used but I am increasing seeing stories that its all put under same
trunks. Even then, encrypted modems can be used to help. A recent DOE
customer is using this with encrypted modems:
http://www.winserver.com/public/wcnavigator.wct
This uses a dialup with a mini-PPP frame wire. It also has a 821 SMTP
MTA to send new messages. This was to avoid APIs calls over the wire
to post a message with attachments. SMTP was easier. :)
Too many people (including some at the
ITU) still have a model of PSTN routing and security that worked
only with uninterrupted, non-multiplexed, copper between the
call endpoints (and with the only real security risk being
eavesdropping by the operator in the middle with the plug
cords). But, no, I have no trouble believing it at all.
Or Russian Vans with electronic magnetic field snooping which required
Tempest-ready computer and devices! :)
but otherwise in many ways more
similar to the FidoNet model than to today's MUA-> MSA -> SMTP
Relay -> SMTP Relay -> Delivery MTA -> Mailstore <-> Split-UA
server -> Split-UA MTA story.
You mean Fidonet inherent dual role vs SMTP single role?
HTTP WebSockets will make that one!
While, I'm sure, causing their own set of problems :-(
High Potential though. Hosting systems should not ignore.