Re: STARTTLS & EHLO: Errata text?

[SM <[e-mail]>]

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

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

Regards,
-sm