EHLO interoperability problem warning

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

This is an early warning, to save others some diagnoqis time.

I've had a number of interoperability problems with EHLO reported to me
that involve mysterious behavior on the part of SMTP servers.  The
servers in question do not give a clue to their identity in the "220"
message with which they open the SMTP connection, making exact
identification difficult.

All of those that have been identified so far are gateway products from
a company called Star*Nine.  They make SMTP gateways for various LAN
mail products, primarily or exclusively Mac-based (MSMail, QuickMail,
etc. (probably all (tm) of their various owners)).  I understand 
Microsoft resells one of those products under its own name.

Detailed tracing of the mail transactions reveals symptoms like the
following.  It is not clear that all of these products, or all
releases, exhibit exactly the same behavior, but there is clearly a
common core.

(1) All of these products will close connections from the server end if
they get adequately confused.  The close occurs after a command is
sent; 221 or 421 replies are not sent first.  Connecting to the same
server multiple times and issuing a problematic sequence of commands
will always get the connection dropped, but one can sometimes issue
more commands before the close than other times.  In other words, the
point at which the connection is closed is either random or depends on
properties I don't yet understand.
  See (5) below.

(2) These products respond to unknown commands (including EHLO) with
502 (command not implemented) codes, not the more usual 500 (syntax
error).  Usually the command sent is used as the text of the reply
message, but sometimes there is no text (some clients don't like that).
Log entries, when they can be obtained, often indicate 'expected helo'.

(3) Few, if any, of these products recognize and support VRFY.

(4) There is some evidence that RSET is not supported properly.

(5) The following sequence, critical to the successful operation of
RFC1425, will usually result in a closed connection after the RSET,
HELO, or MAIL FROM commands are sent.  I've only been able to send MAIL
FROM once, and have observed the connection closing after only EHLO has
been sent.  I have never successfully gotten mail through after sending
EHLO, but may just have been unlucky.  Reply message texts are omitted
from what follows, and sometimes don't appear (see above).
    Sender: EHLO infoods.mit.edu
    Receiver: 502
    Sender: RSET
    Receiver: 502 (some times/versions), 250 (other times/versions)
    Sender: HELO infoods.mit.edu
    Receiver:  ??  (no log of this code, 250 assumed)
    Sender: MAIL FROM:<user@domain>
   (connection is always closed before this reply comes back)
Of course, no attempt was made to stream these transactions.

(6) A sequence of VRFY and EXPN commands will also produce the 502
errors and connection-closing behavior.   So we aren't breaking
anything that wasn't broken already, we are just stimulating the
behavior more often.  However, clients that routinely send EHLO to open
connections are going to have trouble communicating with these servers.

If anyone knows the Star*Nine folks and can get their attention about
getting this straightened out, it would probably be a good idea :-(

   john