Re: STARTTLS & EHLO

[Tony Hansen <[e-mail]>]

I was taking Tony Finch's comments

	But there's plenty of other information that the server has to
	discard - for example any AUTH results, any partial MAIL
	transactions - which isn't explicitly listed in RFC 3207.

to its next step. He was saying that

	S: <start>
	C: 220
	S: MAIL FROM:<...>
	C: 250 OK
	S: RCPT TO:<...>
	C: 250 OK
	S: STARTTLS

that the MAIL_FROM and RCPT_TO information is also discarded. So my
observation was that

	STARTTLS SHOULD only be executed immediately after the initial
	EHLO.

Doing otherwise may cause the server to do extra processing that will
all just get thrown away.

The verbs that I gave examples of were ones that don't affect the state
machine in any way, so would be reasonable to send between <start> and
STARTTLS. That's why I said "SHOULD" instead of "MUST".

I'm going to suggest an Errata in a separate email message.

	Tony

John C Klensin wrote:
> 
> 
> --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
>