Errors-to: owner-drums@CS.UTK.EDU
To: michael.derrico@software.com (Michael D'Errico)
Reply-To: drums@CS.UTK.EDU
Cc: Robert Elz <kre@munnari.oz.au>, drums@CS.UTK.EDU
Subject: Re: RFC 821 problem list 
In-Reply-To: Your message of "Wed, 31 May 1995 13:38:23 PDT."
             <19950531203752328.AAA67@rome.software.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <3120.802019592.1@dbc.mtview.ca.us>
Date: Thu, 01 Jun 1995 08:13:13 -0700
Message-Id: <3122.802019593@dbc.mtview.ca.us>
From: Marshall Rose <mrose@dbc.mtview.ca.us>

yes, this probably should be moved to the smtp extensions working group,
but as long as the topic came up...

there seem to be (at least) three different ways that the TURN
functionality is implemented these days.  in most cases, the
functionality is needed by a host with transient access; and in those
cases, it's often desirable for the MX relay to tell the host when it
has finished sweeping the queue so the host can release its connection
to the Internet.

the three are:

1. the provider modifies the finger server on the relay so that a query of

	finger client-domain@relay-domain

   causes the relay's mail-system to sweep the queue for messages
   destinated for client-domain.  when the queue sweep completes, the
   finger server exits.

2. the second aproach is just like the first, but instead a different
   port is used.

   the provider doesn't have to diddle their finger server, but they now
   have to tell their customers how to cobble-up a client. 

3. the third approach is to use the TURN command like this: on EHLO
   include TURN as a supported option; if TURN is issued by the client,
   the relay's mail-system sweeps the queue for messages destined to the
   domain given to the EHLO command; when the sweep completes, the TURN
   command returns a 5xx series code.

   in this case, both the provider and user have to diddle their code,
   but it's probably closest to the way TURN should have been defined to
   begin with...

/mtr