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
tony(_at_)att(_dot_)com
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?