Re: STARTTLS & EHLO: Errata text?

[SM <[e-mail]>]

Hi Hector,
At 11:49 01-02-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.
>
>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.

If you say MUST in that part of the text in RFC 3207, you'll have to 
explain about when EHLO is not required.  If the HELO/EHLO guidelines 
were different from RFC 2821, it should have been mentioned in RFC 
3207.  But they are not.  For those who might point out that we are 
sending two EHLOs, I'll mention that it is clearly stated that the 
SMTP protocol is reset.

>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.

There is no need for a requirement to issue a 503 reply as we already 
know that the reply is applicable if we send out of sequence commands.

>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.

Errata text should not create a situation where existing 
implementations which were fully compliant with RFC 3207 have to be 
modified unless it is to fix a mistake.  We have two possibilities 
for a mail transaction, the client sends MAIL FROM: after the TLS 
handshake without doing an EHLO first:

   1. The server rejects the command.

   2. The server accepts the command.

For point 1, the client has a problem then as it cannot proceed with 
the mail transaction.  That is the question we have been trying to 
clarify with the proposed text.

There is nothing wrong with point 2.  Be careful about service 
extensions though as the client cannot trust the list it received previously.

>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.

I doubt that putting in "reminder" text would change anything.

Regards,
-sm