Tony Hansen wrote:
If we were to write an Errata against RFC 3207, I'd suggest text such as
the following (in Errata format):
Section:
4.2 Result of the STARTTLS Command
Old text:
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.
New text:
The server MUST discard any knowledge obtained from the client that
was not obtained from the TLS negotiation itself. The server state
is otherwise as if the connection had just been opened.
But it isn't because its in an higher secured state. I took a look at
our server and we have this:
BOOL TSMTPServer::STARTTLS(char *args)
{
// possible replies from RFC 3207
// 220 Ready to start TLS
// 501 Syntax error (no parameters allowed)
// 454 TLS not available due to temporary reason
if (TLSStarted) {
Send("501 TLS already negotiated!\r\n");
return TRUE;
}
...
...
}
I can only suggest that our engineers added it for a reason. Not
having an explicit "already in TLS state" reply code, 501 was used.
My suggestion is to add a new reply code tells the client if its
already in a secured state or not.
Reason:
The example is misleading and has lead some people to think that
knowledge of an EHLO having been sent previously should be
remembered.
I always thought the key reason is that server features may change
depending on the secured or non-secured SMTP state.
Our own server does not enforce the EHLO/HELO reissuing. If you think
about it, it doesn't make sense to resend it given the fact that the
CLIENT DOMAIN information can not change. It might want to use a
different client domain but it MUST still be reflected of the sender
machine regardless.
Our client does send it thought, mainly because that is what most
servers expect.
Section:
4.2 Result of the STARTTLS Command
Old text:
The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
New text:
The client MUST send either an EHLO command or a HELO command as the
first command after a successful TLS negotiation.
I would not encourage a downgrade from EHLO to HELO potential. The
client started in EHLO, it should probably remain in an extended state.
> Section:
4. The STARTTLS Command
Old text:
The format for the STARTTLS command is:
STARTTLS
with no parameters.
New text:
The format for the STARTTLS command is:
STARTTLS
with no parameters.
Because the server state machine is reset to an initial connection
state after negotiating TLS, and any modifications to the server
state will be lost, the client SHOULD NOT issue any MAIL
FROM or RCPT TO commands prior to using the STARTTLS command.
This text is confusing (to me). I think the common usage of "server
state will be lost" is not quite right simply because the secured
state of the SMTP session is not lost.
Now for the $64k questions:
1) Is there consensus behind this viewpoint?
I don't agree with the proposes errata text as is.
2) If so, does the text above cover the ground?
I don't think so.
3) If so, who wants to file the Errata?
Paul should <g> He's the one using a client that doesn't send the
EHLO. :-)
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com