Message-Id: <3.0.1.32.19970930113518.008cd410@lacroix.wildbear.on.ca>
Date: Tue, 30 Sep 1997 11:35:18 -0400
To: "Jeff Stephenson" <jeffstep@microsoft.com>, <drums@cs.utk.edu>
From: "Jack De Winter" <jack@wildbear.on.ca>
Subject: Re: TURN and disconnected SMTP with dynamic IP addresses
In-Reply-To: <01bcc83e$6a183470$abe8379d@cassatt.cassatt.dns.microsoft.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:33 AM 9/23/97 -0700, you wrote:
>I'll try to persuade you, then ;-).  I agree that TURN should not be honored
>without some form of the client host's identity.  I would _love_ to have a
>mechanism within SMTP for assuring that, but until SASL or some other
>mechanism is approved there just isn't such a beast.  The lack of
>authentication also affects other SMTP commands - MAIL FROM and DATA being
>prime examples, allowing spoofing/forgery of email.  Also, as I pointed out
>in my reply to Perry, ETRN itself is insecure in a dynamic IP address
>environment.

two strong objections I have for TURN being reimplemented are as follows:

1) TURN has been discredited and depricated.  calling it something else
   would be acceptible, but please let us not try and convince people
   that red lettuce and green lettuce are not the same lettuce.

2) TURN implies that the infrastructure that you are building its support
   into can get the necessary messages that it needs to send at that
   point.  since TURN has been depricated for a while, lots of
   implementations simply start other SMTP sessions when they need to send
   the data.  This is why ETRN was so easy to get deployed... it did not
   change the delivery mechanism, simply accelerated the retry times.

The first point is one that should not be taken lightly.  If you show me
a package that has "SMTP supports TURN", I will say it is a bad package.
I will even show you RFC 1123 to back it up.  The second point is one of
usability.  Being able to do this extra TURN may sound nice, but why not
work within the frameworks of ETRN to produce something that meets your
needs without causing implementors to possibly rewrite their engines.

When I came out with ETRN, I was able to get a friend to implement it
quickly.  He was able to put it in their mail server within an hour,
according to his report.  He said it was trivial.  The security about
whether or not to force is a different matter, but the base "kick the
retry for a given node" code, the code of ETRN, is trivial, hence easy
for people to adapt to.  TURN would not be.

just my 2 cents,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)