[Top] [All Lists]

Re: Recipient is offline

2011-09-03 11:21:54

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:

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:

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.

<Prev in Thread] Current Thread [Next in Thread>