--On Monday, January 26, 2009 12:04 PM -0500 Tony Hansen
<tony(_at_)att(_dot_)com> 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