RE: I-D ACTION:draft-hoffman-smtp-ssl-04.txt

Ned Freed <Ned.Freed@innosoft.com> Wed, 05 November 1997 05:22 UTC

Delivery-Date: Wed, 05 Nov 1997 00:26:11 -0500
Date: Tue, 04 Nov 1997 21:14:15 -0800 (PST)
From: Ned Freed <Ned.Freed@innosoft.com>
Subject: RE: I-D ACTION:draft-hoffman-smtp-ssl-04.txt
In-reply-to: "Your message dated Tue, 04 Nov 1997 23:01:11 -0500 (EST)" <Pine.NEB.3.96.971104225358.8438D-100000@pmw.org>
To: Chris Rapier <rapier@tyranny.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>
Message-id: <01IPMK117LJY9JEXJ2@INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
References: <01BCE955.BE5D2A80@ppp-hg1-29.ftwotx.onramp.net>

> I happen to think that there is a lot of leeway within the SMTP
> architecture that we aren't taking advantage of.
> For example...

> Can we assume that most SMTP handlers will respond with an error on an
> unknown command and then continue? If we can assumee that then we have a
> reasonable way of determining if an MTA can support additional hooks.
> Between compatible MTAs one of thse hooks could be establishment of a
> secure connection prior to the passage of envelope information. If the
> recipient doesn't support SSL or TSL or whatever, the sender will
> fallback to cleartext.

Such assumptions are unnecessary. The standard SMTP protocol now supports an
EHLO command. (See RFC 1869 for details, and note that this is now a full
Internet Standard.) This command list the extensions which are available. If a
given extension like, say, TLS, is listed as available, one can assume that the
commands associated with TLS are also available.

Paul's SSL draft already uses this facility to advantage.

				Ned

RE: I-D ACTION:draft-hoffman-smtp-ssl-04.txt Ned Freed