Re: STARTTLS & EHLO: Errata text?

John C Klensin <john+smtp@jck.com> Sun, 01 February 2009 20:46 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11KkOPl004975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 13:46:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11KkOL0004974; Sun, 1 Feb 2009 13:46:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11KkMin004968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <ietf-smtp@imc.org>; Sun, 1 Feb 2009 13:46:23 -0700 (MST) (envelope-from john+smtp@jck.com)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LTjCu-0005Zt-D2; Sun, 01 Feb 2009 15:46:20 -0500
Date: Sun, 01 Feb 2009 15:46:19 -0500
From: John C Klensin <john+smtp@jck.com>
To: Tony Finch <dot@dotat.at>, Hector Santos <hsantos@santronics.com>
cc: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
Message-ID: <660F628EB438436EF839BA6A@PST.JCK.COM>
In-Reply-To: <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
References: <497DE492.4080506@pscs.co.uk> <497DED29.70402@att.com> <497ED420.30708@pscs.co.uk> <alpine.LSU.2.00.0901271403220.4546@hermes-2.csi.cam.ac.uk> <497F86CB.60904@att.com> <alpine.LSU.2.00.0901281434440.4546@hermes-2.csi.cam.ac.uk> <498088B8.9040404@pscs.co.uk> <alpine.LSU.2.00.0901291310080.4546@hermes-2.csi.cam.ac.uk> <4981C0D5.1010401@pscs.co.uk> <4981C6BD.2040900@att.com> <37F39FF37390694B69567838@PST.JCK.COM> <4981E1AB.9000002@att.com> <alpine.LSU.2.00.0901301832470.4795@hermes-2.csi.cam.ac.uk> <49835DE2.3030403@santronics.com> <alpine.LSU.2.00.0901312021190.14750@hermes-2.csi.cam.ac.uk> <4984C49C.5030401@santronics.com> <alpine.LSU.2.00.0902011706190.10756@hermes-2.csi.cam.ac.uk> <AE5689449BAC89829F0DD5E7@PST.JCK.COM> <4985FCD8.8040305@santronics.com> <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

--On Sunday, February 01, 2009 20:35 +0000 Tony Finch
<dot@dotat.at> wrote:

> On Sun, 1 Feb 2009, Hector Santos wrote:
>> 
>> I was thinking of 3207 with text similar to:
>> 
>>     The secured SMTP client MUST resend the EHLO command and
>>     the secured SMTP server MUST be prepared to issue an 503
>>     for any out of sequence commands by legacy 3207 clients.
> 
> What's wrong with the text I suggested?
> 
>    Upon completion of the TLS handshake, the SMTP protocol is
> reset to    the initial state (the state in SMTP after a
> server issues a 220    service ready greeting).  The
> requirement in [RFC5321] that "a client    MUST issue HELO or
> EHLO before starting a mail transaction" also    applies to
> this fresh state.

Tony, repeating my disclaimer about not feeling qualified to
have an opinion about whether more text is needed in 3207, I
think you are specifying the client behavior (which I believe to
be necessary) while Hector is trying to specify the server
behavior if the client doesn't do what is expected of it.  We
don't often take that step, precisely to permit servers to be
more permissive if they want to, but maybe it would be useful in
this case.  Or maybe not.

If one did want to say something about the server response to
the client's sending something besides EHLO, another alternative
would be to take either Hector's text or my possible
alternatives to it and preface it with some of the type of "if
the server decides to check, then..." language we've used
elsewhere.  My own instinct is to avoid going down that path,
but Y (or Hector's) MMD and I claim no expertise about 3207 here.

   john