ietf-smtp
[Top] [All Lists]

Re: Recipient is offline

2011-09-03 06:35:21



--On Saturday, September 03, 2011 03:23 -0400 Hector
<sant9442(_at_)gmail(_dot_)com> wrote:


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

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.  Unless the machine and encoding
architectures were identical, comparing the two approaches on
transfer speed alone was just silly (whether Frank understood
how to run a speed test or not -- I agree with Chuck that he did
not, but do not go so far in assuming malice).  To make a fair
test, one would have had to assign some measure to the costs of
transferring protocol information out of band (pretty arbitrary
and hence unlikely to be meaningful) and then to measure the
time and costs of post-transfer conversions.  Otherwise, while
the costs of simply keeping the line up (or transferring a few
extra packets) were a significant consideration, comparing
ZMODEM and Kermit was a bit like comparing TCP and FTP -- raw
data stream versus a fairly sophisticated processor.   (Of
course, Kermit's common data model and conversions echoed FTP
and TYPE A, on which it was modeled, and which Columbia needed
to have, initially in order to deal with transfers between
EBCDIC and ASCII machines.)

Disclaimer: FWIW, I did most of the development for the CP/M-86
(aka DR-DOS) and Concurrent CP/M versions of Kermit and made
some contributions to the OS/2 version.

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.

I might argue that wasn't true.  It just shifted parts of that
work outside the protocol and into recommendations that involved
a lot of handwaving.   Certainly its queuing-retry and relay
models were much more complex than FTP-based email,which had
neither.

- 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,

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)

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.

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. :)

Depends on when you start counting and what you count.  During
the ARPANET period, hosts could get removed from the network for
egregious behavior and sometimes were.  One might argue that
those decisions were a little less political (in terms of whose
aberrations were tolerated) than the FidoNet ones, but that is a
separate issue.  What the Internet had instead was Postel's
robustness principle and its aggressive (perhaps excessive)
application to making email work.
 
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?

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.  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.
 
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.

Or, I assume, having seen it in too many other places, simply
consider any change to what they are doing because it would
disrupt operations, require retraining people, etc.   But these
are the same organizations who, for similar reasons, were still
running 650 and 7070 emulators on their computers until not long
ago (I have no reason to believe that all of them have stopped).
That may sound negative, but really isn't -- I've done enough
analysis of the costs of retraining people, reviewing and
changing procedures, certifying new systems and proving their
equivalent to older ones, and so that I suspect they may be
behaving rationally.

 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."

Right.

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.

From a more traditional Internet point of view, one could make
"one or two" arguments about SMTP with and without TURN, but
POP3 was irrelevant (and not invented) until client-server
models with clients a lot less capable than servers became
popular.  For the first 15 years or so of my email history, MUAs
read directly from mailstores or, more commonly, MUAs read from
mailboxes to which delivery had been made directly from an MTA
with no distinct mailstore.  Remote and very dumb terminals
connected to much bigger iron, 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.


 HTTP, I guess from different POVs, one or two
sessions.  HTTP WebSockets will make that one!

While, I'm sure, causing their own set of problems :-(

best,
   john


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