Re: STARTTLS & EHLO: Errata text?

[Hector Santos <[e-mail]>]

John C Klensin wrote:
> 
> 
> --On Sunday, February 01, 2009 17:14 +0000 Tony Finch
> <[e-mail]> wrote:
> 
>> On Sat, 31 Jan 2009, Hector Santos wrote:
>>> 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?
>> Not in 3207 - this requirement is inherited from 5321.
> 
> IMO, that requirement, and the use of the codes, is perfectly
> clear in 5321 (at least to anyone who bothers to read it).  If
> someone disagrees, please send text.

Tony, SM, John,

Ok, let me try it this way:

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.

Why?

Our server, and probably others, based on the original relaxed 
semantics "Client SHOULD resent EHLO/HELO" guideline, does not enforce 
it simply because it didn't say MUST.

In other words, the secured client can continue with a MAIL FROM and 
the normal reply codes associates with it apply, but not 503 because 
it wasn't deem necessary at this stage.

On the other hand, if 3207 is altered to enforce a MUST, then we need 
to change our server and in that vain, I reject this 3207 change to a 
MUST.  However, since most secured clients do resend EHLO, I don't see 
that as having an impact on existing installations.  Our secured 
server is not going to fail the secured session if the secured client 
does not resent EHLO.

So at the very least, if 3207 text is changed to MUST, it should 
include some additional text, call it a "reminder" text if you wish to 
the above text. Who knows, if the server in the example did issue the 
503, then maybe the OP's client designer might have seen the necessity 
to add logic to restart with EHLO, and thus, no discussion would be 
necessary.

-- 
Sincerely

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