[Top] [All Lists]

Re: STARTTLS & EHLO: Errata text?

2009-01-29 18:32:01

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 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. 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 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.

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

This has been discussed previously. It could be done by advertising a separate extension as you suggested.