Courier SMTPd has a bug in it that I ran into yesterday.

It returns an EHLO-style response to the HELO command, which is expressly forbidden in the RFC 2821, section 3.2, reproduced here (highlighting mine):

3.2. Client Initiation

Once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server, indicating the client's identity. In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports. Older SMTP systems which are unable to support service extensions and contemporary clients which do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO.

*** Servers MUST NOT return the extended EHLO-style response to a HELO command. ***

For a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO.

Here is the evidence:

jnelson@localmachine jnelson $ socat - tcp4:localhost:25,crlf 220 myhost.net ESMTP HELO testhost 250-myhost.net Ok. 250-STARTTLS 250-XCOURIEREXTENSIONS 250-XVERP=Courier 250-XEXDATA 250-XSECURITY=NONE,STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 250 DSN QUIT 221 Bye. jnelson@localmachine jnelson $

This bug prevents several older clients from working properly.