Re: TURN and disconnected SMTP with dynamic IP addresses

[Randall Gellens <Randy@xxxxxxxxxxxx>]

At 10:53 AM -0700 9/30/97, Paul Hoffman / IMC wrote:


>First off, I think this discussion should be on ietf-disconn-smtp@xxxxxxx
>only, not on DRUMS, since it doesn't have anything to do with 821 or 822:
>it has to do with an extension.

Makes sense to me.  I would have removed drums from the cc list of this
message, but I haven't received any messages on ietf-disconn-smtp for
days, so I'm not sure where the problem is.



>Assume that we come out with an extra parameter for the ETRN command
>so that:
>
>C: ETRN <node> <key1> <key2>
>S: 250 OK
>
>causes a connection to be forced to the given node.  When the connection
>is established, we add an extra part of the EHLO parameters so that we
>would receive:
>
>...
>250-ETRN
>250-ETRNID
>...
>
>when we establish the connection.  The new client (the old server) would
>then give the command:
>
>C: ETRNID key1
>
>The new server (the old client) replies with:
>
>S: 250 key2
>
>That way, if there are many pending key1's, the now-server would know which
>to respond to.
>
>Further, I think that the keys should be optional, so that current systems
>that don't need them (those with believable fixed IP addresses) can
>interoperate with this new system.

First, I think it might help to have a way to tell a normal ETRN (which
should use the DNS) from a dynamic ETRN (which would normally use the
IP address that the client is presently on).  I was thinking of either
a new command (DTRN) or an optional parameter to ETRN:

C: ETRN [192.168.15.2:8025] foobar.net

The presence of an IP address in square brackets would server to
indicate that this is an ETRN for use with an intermittently-connected
host, and also allow the host to request use of a port other than 25.
It would also clue the server that it should reject the command unless
the client was authenticated.

(Because the result of ETRN is a new connection in the reverse
direction, with client and server roles reversed, I'm going to use the
terms ISP and Customer in an effort to reduce confusion).

To close the timing hole for the new connection, I see two ways to go:
(1) have the ISP respond to ETRN with a key (a random number) that the
customer returns in the EHLO response or the greeting when the new
connection is opened:

C: ETRN domain
I: 250 [9876foo] OK
...
I: EHLO ISP.COM
C: 250- ETRNID [9876foo]

Or (2), require a new authentication for the new connection:

C:  AUTH CRAM-MD5
I: <1896.697170952@xxxxxxx>
C:  foobar.net b913a602c7eda7a495b4e6e7334d3890
I:  250 OK now authenticated as foobar.net
C: ETRN [192.168.15.2] foobar.net
I: 250 OK
...
I: AUTH CRAM-MD5
C: <1896.697170683@xxxxxxxxxx>
I: ISP.COM a872b304a4bcd3b587a2bcd938473849
C: 250 OK ISP.COM now verified, please send me my mail

The second authentication could use the same shared secret as the
first, to make things simpler.

Someone earlier suggested a third way (having the ISP wait until it
opened the new connection before responding to the ETRN) which I'm
still mulling over.


--
Randall Gellens       ||    Opinions are personal; facts are suspect;
randy@xxxxxxxxxxxx    ||    I speak for myself alone
--

Succumb to natural tendencies.  Be hateful and boring.