This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:
Received: from rutgers.edu (-:RUTGERS.EDU:-) by yonge.csri.toronto.edu via TCP
with SMTP id AA02916; Mon, 15 Jul 91 12:54:13 EDT
Received: from dimacs.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA07280; Mon, 15 Jul 91 12:52:38 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA14388; Mon, 15 Jul 91 12:11:21 EDT
Received: from transarc.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA14384; Mon, 15 Jul 91 12:11:18 EDT
Received: by transarc.com (5.54/3.15) id <AA02273> for
ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu; Mon, 15 Jul 91 12:11:09 EDT
Received: via switchmail; Mon, 15 Jul 1991 12:11:08 -0400 (EDT)
Received: from apollo.transarc.com via qmail
ID </afs/transarc.com/service/mailqs/q1/QF.kcUQWaP0BwwO80Ml41>;
Mon, 15 Jul 1991 12:09:13 -0400 (EDT)
Received: from apollo.transarc.com via qmail
ID </afs/transarc.com/usr/cfe/.Outgoing/QF.YcUQWP70BwwO45Zg4R>;
Mon, 15 Jul 1991 12:08:59 -0400 (EDT)
Received: from
Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.apollo.transarc.com.pmax.3
via MS.5.6.apollo.transarc.com.pmax_3;
Mon, 15 Jul 1991 12:08:47 -0400 (EDT)
Message-Id: <0cUQWDX0BwwO05Zfsi(_at_)transarc(_dot_)com>
Date: Mon, 15 Jul 1991 12:08:47 -0400 (EDT)
From: Craig_Everhart(_at_)transarc(_dot_)com
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu,
rayan(_at_)cs(_dot_)toronto(_dot_)edu (Rayan Zachariassen)
Subject: Re: 7/8-bit conversion vs. bouncing
In-Reply-To:
<91Jul8(_dot_)210905edt(_dot_)306(_at_)jarvis(_dot_)csri(_dot_)toronto(_dot_)edu>
References:
<91Jul3(_dot_)203008edt(_dot_)61(_at_)jarvis(_dot_)csri(_dot_)toronto(_dot_)edu>
<678590815(_dot_)380608(_dot_)KLENSIN(_at_)INFOODS(_dot_)MIT(_dot_)EDU>
<91Jul8(_dot_)210905edt(_dot_)306(_at_)jarvis(_dot_)csri(_dot_)toronto(_dot_)edu>
Excerpts from transarc.system.ietf-822: 8-Jul-91 Re: 7/8-bit conversion
vs. .. Rayan Zachariassen(_at_)cs(_dot_)to (2937)
a-priori way to tell if the remote is supposed to handle "new protocol"
But there really isn't other than trying.
Trying it does not need to involve setting up and tearing down a TCP
connection, as well as an SMTP handshake or two. It could be as cheap
as (equivalent to) asking a remote nameserver a question. For example,
a UDP ping on a well-known port. This could be done at routing time.
Once the transition is deemed sufficiently completed, the test would be
removed from code and SMTP would die off.
I don't think such a scheme would run into the problems traditionally
brought up as counterarguments.
Any mechanism for trying (UDP ping or not) has to allow a
transient-failure result, unless there are no costs to guessing wrong.
(In such a situation, though, you'd be just as well off to guess wrong
all the time, without doing a UDP ping or anything else.)
Given that a sender sees a transient failure, what does it do?
Fundamentally, it has to hold on to the mail for a time T waiting for
the transient-failure situation to clear up. T could be chosen as zero
or very large, but any choice will be wrong, possibly badly wrong, for
some cases.
Craig