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: [EMAIL PROTECTED] 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. [EMAIL PROTECTED] jnelson $ This bug prevents several older clients from working properly. -- Feast your Vulcan squinties on that! Jon Nelson <[EMAIL PROTECTED]> C and Python Code Gardener ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
