re: EHLO interoperability problem warning

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

Mark,
  Thanks.  

  First of all, I must say, having just reread the text in 821, that
construing RSET as a synonym for QUIT must require real creativity (or
trying to think with one's head in a normally-uncomfortable position),
even more so if the text for the two is compared.  Even ignoring any
possible ambiguity (which I can't find), the text for RSET specifies
that "the receiver must send an OK reply" which I certainly can't
translate as "close the connection".  The command-reply sequence for
RSET also doesn't show QUIT's 221 (normal close) code, but only the
universally-available 421 (server dying) one.

As you say, no reasoning with such folks.

Sounds like, if one sends EHLO and gets back a 5yz code, there are two
choices (other than declining to talk to old servers :-) ):
  -- Send RSET and upset all the clowns who think it means "QUIT",
"instant close", or something equally bizarre.
  -- Send HELO without RSET, and upset all the clowns who think that
HELO must be the very first thing they see after sending the
connection-opening 220. (I've seem some of these folks refuse to accept
VRFY or HELP without a HELO first and HELO if it follows either, e.g., 
S: HELP, R: 503, S: HELO, R: 503,....)

Since both types of brokenness seem to exist (and it is possible that
the Star*Nine folks manage to exhibit both simultaneously with their
"random close" algorithm), I guess that we are just going to have to
view the SMTP extensions as a mechanism for shaking a lot of trash out
of the network.   It is probably either that or give it up and let
these folks take over.

    john