Re: STARTTLS & EHLO

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

--On Monday, January 26, 2009 12:04 PM -0500 Tony Hansen
<[e-mail]> wrote:

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

Indeed.  Also, while I don't have time to find it right now, I'm
quite sure that there is a statement in 5321 that says that the
client MUST NOT try to exercise any extension not explicitly
offered by the server.

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

Yes, that is certainly how I would read the quoted 3207 text.

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

Right. The quoted 3207 text says to me that the server is
required discard the data sent earlier by the client as part of
EHLO.  I don't see any expectation that it be required to
discard the fact that EHLO was sent.    

Indeed, unless there is something else in 3207, the client isn't
even required to discard the response from EHLO with the
server-supported feature list, so one can make a case that it is
not necessary to reissue EHLO at all, although a client that
does not do so should expect "no, bozo, I will accept that
extension from some domains and not others, and you are not one
of the permitted ones" response from the server.    If that is a
plausible reading of 3207, then it could probably do with a bit
of clarification.

    john