ietf-smtp
[Top] [All Lists]

Re: Recipient is offline

2011-09-03 02:39:09

John C Klensin wrote:

A very significant and important improvement, IMO.  Presumably,
if a telephone# still appears and is supported at both ends, it
continues to work.

It was from the standpoint it allowed Fidonet mailers to get away from the FTN1 protocol (XMODEM, no error correction) constraints not working under X.25 and TCP and use instead its more modern WAZOO (Yoohoo / Yoohoo2) text based handshaking protocol to negotiate capabilities, authentication with matching network addresses, and selection of the data transfer protocol, ZMODEM was the default designed specifically for X.25.

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

I recall really easily liking SMTP because it reminded me of flexibility WAZOO provided and how much more power and flexibility RFC822/821 had to offer.

SMTP (821/822) just simplified things:

- Design complexity for Queuing/Schedule reduce, less used and
  even removed.

- Dynamic Delivery/Receiving benefits were immediate.

- Remove the need for error-correction protocols. TCP did that for us.

- RFC822 headers resolved major issues with Kludge lines (network
  control lines) in the Fidonet mail format,

- RFC822 text base format allowed for expansion and growth,

- RFC821 was flexible, you can easily add more command line
  mode commands,

and it was an added bonus the Internet had no "rules" unlike the FTSC restrictions where non-compliancy got you (developer and operators) off the Fidonet NodeList. :)

Why Dialup?

# 1, its one way to win a fast entry contract with the feds as
# the exception to HIPAA secured internet transfer requirements.

That application had not occurred to me.  I find it fascinating
as well as worthwhile.  The other two examples surprise me less.

I only mentioned this one because almost all the insurance companies, providers, subcontractors and clearing houses do this. But would you believe the CIA, FBI, DOD, DOE, State, Local law enforcement, many Fire Departments, payroll, banks, many with end of day activities, inventories (i.e. hand scanners), etc, that continue to use dialup to avoid any security issues and/or cost?

But for many, its the demand of their clients. So even if network security isn't the reason and secured internet portals are available, many of their clients (any size) simply won't tolerate or budge on having to increase their communication cost or, a biggy, have to develop software or pay for an administrator, especially if its not a 24x7 need. Not many service providers will do this unless they have special client software or offset the cost some how, so they just say "Here are phone numbers, secured ftp, smtp, http addresses and you choose how you want send/pickup stuff."

Anyway, I will note, and maybe that is what I am stuck with John, in my view, the paradigm and of course, with variations, the model has never really changed from:

    CONNECT
      SEND, IF ANYTHING
      PICKUP, IF ANYTHING
    DISCONNECT

What is a large part for us is:

    CONNECT
      PICKUP OUTPUT, if ANY
      SEND   --> BACKEND PROCESS --> OUTPUT
    DISCONNECT

How client do the above was up to them. One Sessions, Two Sessions, etc. FTP keeps that as one. SMTP/POP3 split it that into two. HTTP, I guess from different POVs, one or two sessions. HTTP WebSockets will make that one!


--

HLS

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