Re: STARTTLS & EHLO: Errata text?

Hector Santos <hsantos@santronics.com> Sun, 01 February 2009 05:35 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 n115ZoL9072785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 22:35:50 -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 n115Zo2g072784; Sat, 31 Jan 2009 22:35:50 -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 winserver.com (mail.catinthebox.net [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n115ZcCu072774 for <ietf-smtp@imc.org>; Sat, 31 Jan 2009 22:35:48 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Sat, 31 Jan 2009 16:38:24 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 2923726781; Sat, 31 Jan 2009 16:38:23 -0500
Message-ID: <4984C49C.5030401@santronics.com>
Date: Sat, 31 Jan 2009 16:37:32 -0500
From: Hector Santos <hsantos@santronics.com>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
CC: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
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>
In-Reply-To: <alpine.LSU.2.00.0901312021190.14750@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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>

Tony Finch wrote:

>> To me, that is enough to give the client the incentive and understanding
>> that it needs to re-issue EHLO.
> 
> Remember this thread was started by someone who wrote code that did not.

+1.

This is why I think that it should be stated that the client MUST be 
prepared to issue an EHLO/HELO in a SHOULD currently stated 
specification.  So even if it did not send the EHLO/HELO and got a 
negative response from the server, it should then proceed with an 
EHLO/HELO.

So the one question I did have was the response code from the server. 
  As shown, the server issued 550. It was something:

    [TLS established]
    C: MAIL FROM <xxxx>
    S: 550 EHLO/HELO required.

Shouldn't the server response be 503 (Bad Sequence of commands)?

If so, should this be stated in the revised text?


-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com