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 reason for this is simple: Limits used in controlling spam and
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. 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.
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.
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
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.
While this clarification exercise is all well and good, if we're
to issue a revision to RFC 3207 we should consider fixing its most
(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
This has been discussed previously. It could be done by advertising
a separate extension as you suggested.