Re: STARTTLS & EHLO

[John C Klensin <[e-mail]>]

--On Thursday, January 29, 2009 10:09 -0500 Tony Hansen
<[e-mail]> wrote:

> If this is the interpretation that we gain consensus on, that
> it means "start over from scratch", it might as well also say
> that it
> 
> 	SHOULD only be executed immediately after the initial EHLO.
> 
> The only possible exceptions to this rule would be for verbs
> that don't affect the state machine, such as VRFY, EXPN, HELP,
> NOOP.

RSET is also harmless immediately after EHLO.  Changing the
state from "session open (EHLO issued), no mail transaction
state" to "session open (EHLO issued), no mail transaction
state" is a no-op.  And the first paragraph of 4.1.1.5 of 5321
says that.

Out of context, I'm not sure exactly what you are suggesting
above, but I believe that it would mean:

    S: 220 ...
    C: EHLO ...
    S: 250-...
    S: 250-STARTTLS
    S: 250-...
    S: 250 OK
    C: STARTTLS  ...
    (TLS session starts)
    and the next command must be either EHLO
    or as many instances of any of VRFY, 
      EXPN, HELP, NOOP, RSET as desired, followed by EHLO

Also, the "what the server MUST (or SHOULD) discard and the
client MUST (or SHOULD) not depend on" sentences and example
might reasonably be modified to explicitly include any
information gained from VRFY or EXPN issued between the 220
greeting and the initial EHLO.  While one might not trust VRFY
or EXPN queries or results issued under TLS either, it would be
pointless and silly to send them before the initial EHLO if one
knew that one was going to issue STARTTLS if the server
permitted it.   Indeed the only reason for doing so would be if
one intended to make a decision about whether to continue with a
mail transaction at all based on the results of VRFY or EXPN...
and that would be very rare today except in special
circumstances.

      john