Re: STARTTLS & EHLO

[Tony Hansen <[e-mail]>]

At the heart of this question is whether a client is free to use an
extension supported by the server if they haven't issued an EHLO? This
question holds true for any extension, not just for STARTTLS. Is issuing
an EHLO an enabler for the extension as well as a query to determine
which extensions are supported by the server?

To answer these questions, I note this text in RFC 5321 highlighted with
>>><<<:

   3.2.  Client Initiation

   Once the server has sent the greeting (welcoming) message and the
   client has received it, the client normally sends the EHLO command to
   the server, indicating the client's identity.  In addition to
   opening the session, use of EHLO >>>indicates that the client is able
   to process service extensions<<< and requests that the server provide
   a list of the extensions it supports.

So this indicates to me that EHLO does indeed act as a gateway and
enabler to the use of extensions. So I'd argue that a server is free to
reject the use of any extensions unless a client has used EHLO prior to
that.

By extension, if you expect to use any further SMTP extensions after
negotiating TLS, I think you MUST resend an EHLO.

However, if you're *not* using any further extensions after STARTTLS was
sent, I don't see a requirement. So consequently, since you say you're
not using any other extensions, I don't see the case for them refusing
the message at that point without the EHLO.

	Tony Hansen
	[e-mail]

Paul Smith wrote:
> We've just had a small issue come up wrt STARTTLS and I was wondering if
> it was a mistake in RFC 3207, or just me :)
> 
> We did a quick patch for someone and added STARTTLS into a new part of
> our software in a special build. For speed of releasing the patch, we
> didn't make it issue a new EHLO afterwards, based on section 4.2 of RFC 3207
> 
> "  The client SHOULD send an EHLO command as the
>    first command after a successful TLS negotiation."
> 
> 
> (SHOULD, not MUST). We were planning to add the extra EHLO in before
> this went to a general release (we don't need to know about any
> extensions other than that STARTTLS, so it's not necessary from our PoV)
> . Anyway, 99.9% of the time, it's OK, but they have encountered one
> recipient which refuses to accept the message in this case. So, they
> seem to be treating the 'SHOULD' as 'MUST'.
> 
> Now, earlier in section 4.2, it says "
> 
> "  The server MUST discard any knowledge
>    obtained from the client, such as the argument to the EHLO command,
>    which was not obtained from the TLS negotiation itself"
> 
> 
> which I guess is why they are rejecting the message, because (since they
> have discarded the fact that we have previously sent EHLO) they are
> complaining that we haven't sent EHLO yet.
> 
> So, should the 'SHOULD' be a 'MUST' in this RFC, or is the other server
> incorrect?
>