Hi Ned,
At 12:46 29-01-2009, Ned Freed wrote:
>While I have no objection to making this change, I note in passing
>that quite a
>few servers, ours included, violate the "the server MUST discard any knowledge
>obtained from the client" part of this and will continue to do so no matter
>what is written in any standard.
I read that as the proposed text does not affect your implementation.
The proposed change does not; both the original and revised text do.
>The reason for this is simple: Limits used in controlling spam and
>DOS attacks.
>Servers impose limits on all sorts of things, including but not limited to the
>number of transactions in a session, the total number of recipients, the total
>time a session has taken, and so on. If a server follows this MUST it turns
>STARTTLS into a one time "reset all my rate limits" pass. That's simply not
>acceptable in today's email climate.
The reason we are having this discussion and the proposed errata is
because of SHOULD and MUST.
Yes, I'm aware of that.
The above lists some of the
considerations when deciding about the requirement to be
specified. My understand of a SHOULD is "unless I have a good
reason not to do it and I fully understand the implication". That
leaves room for local policy decisions as you explained above.
Yes, but the text currently says MUST, not SHOULD:
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.
I'm arguing that this MUST should be a SHOULD.
One of the questions was about the "The client SHOULD send an EHLO
command as the first command after a successful TLS negotiation." As
with everything SMTP, there are two sides, the sender and the
receiver. Instead of thinking in terms of whether the sender should
send the command, we could look at this in terms of whether the
receiver must accept a mail transaction without being sent an EHLO
command. I don't see anything in the specifications that say that.
Actually, the specification is quite clear that the session state is
reset to that of where the banner line has just been returned:
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting).
So if the client sends a MAIL FROM without first sending a EHLO/HELO it is
doing so to a server that's supposed to be in the "initial banner sent, no
EHLO/HELO seen" state. IMO a server is perfectly entitled to refuse the MAIL
FROM in this case.
But I fail to see how this has any bearing on the point I've raised, which has
to do with the server retaining session history after STARTTLS - something the
specification currently forbids.
>The simplest fix to bring this text in line with reality is to change the MUST
>into a SHOULD. Beyond that lies a slippery slope where we attempt to
>categorize
>what sorts of information a server can or cannot retain. I really don't think
>we want to go there.
Agreed. Such a change cannot be done in an errata. I would like a
SHOULD instead of a MUST or else we end up with a situation where we
have to go against an absolute requirement. Unfortunately, it causes
the type of confusion we have seen in this thread. If we attempt to
categorize what knowledge is discard or can be retained, we'll end up
with a lengthy specification with the problem it entails.
Frankly, while I have no problem with clarifying the specification, I don't buy
the argument that the nonissuance of a EHLO/HELO after STARTTLS and before MAIL
FROM is in compliance with the SHOULD. Again, the specification is very clear
about the required session state and a predictable consequence of that is that
a HELO/EHLO is now required. IMO this is failing to understand the likely
consequences of omitting the EHLO/HELO.
>While this clarification exercise is all well and good, if we're
>actually going
>to issue a revision to RFC 3207 we should consider fixing its most
>serious flaw
>(IMO) - the lack of a domain parameter on the STARTTLS command, in order to
>allow a single SMTP server to provide "virtual hosting" support for multiple
>domains.
This has been discussed previously. It could be done by advertising
a separate extension as you suggested.
Right, but since we're now bumping up against a possible revision, now's
tthe time to revisit the idea.
Ned