ietf-smtp
[Top] [All Lists]

Re: Using RSET with the EHLO/HELO fallback logic

2008-02-25 00:09:56

Hi Hector,
At 13:16 24-02-2008, Hector Santos wrote:
Here is the overall transaction that was in question. This is our customer using our WCSMTP software to send mail to their new customer who is using large brand name server appliance as an SMTP host.

  S: 220 **************************************************
  C: EHLO yyyyyyy.com
  S: 500 Syntax error, command unrecognized
  C: RSET
  S: 503 Bad sequence of commands
  C: QUIT
  S: 221 xxxxxxxx.com Service closing connection

Overall, the issue is that the remote server did not honor the RSET command and issued a BAD sequence of commands. So our software abandoned the transaction and QUIT.

Quoting Section 4.7 of RFC 1869 (obsoleted by RFC 2821):

   Other improperly-implemented servers will not accept a HELO command
   after EHLO has been sent and rejected.  In some cases, this problem
   can be worked around by sending a RSET after the failure response to
   EHLO, then sending the HELO.  Clients that do this should be aware
   that many implementations will return a failure code (e.g., 503 Bad
   sequence of commands) in response to the RSET.  This code can be
   safely ignored.

That's the historical context.
But after the situation was resolved, we made a decision here to put in a change request in our SMTP client software to make the RSET command optional in the EHLO/HELO fall back to reduce future support cost issues.

I looked at RFC 2821 section 3.2

   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.

If someone reads RFC 2821, I guess, in reading the last sentence, one can reasonably argue how one may get the idea that a RSET is not expected after an EHLO command, hence issuing a "503 Bad sequence of commands" response as this large appliance SMTP server did. I don't think that argument jives 4.1.1.5, but I can see where that mistake can be made.

It's not an EHLO command there; it's an unrecognized command. The client SMTP did not fall back and send HELO.

Who is at truly at fault? Who knows? I really don't care. Our software has the RSET in its EHLO/HELO fallback for a engineering reason, I'm sure. But because of the above possibilities, we are going to make the change too.

Please don't read what I am saying as "who is truly at fault".

Section 4.1.4 of the RFC 2821bis mentions:

  "The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
   during a session, or without previously initializing a session.  SMTP
   servers SHOULD process these normally (that is, not return a 503
   code) even if no EHLO command has yet been received; clients SHOULD
   open a session with EHLO before sending these commands."

Summary and recommendation:

I am not sure which way you may to do this.

 a) Add Text to 3.2 to make servers aware a RSET after EHLO is
    possible?

The text is already there (see above).

 b) Do not allow RSET after EHLO for possible 821 historical reasons?

That means turning this into an issue.

The latter may be a problem with existing software designed around 2821 which may already have logic to issue RSET after EHLO.

That's what the client SMTP did in this case.

Personally, I prefer the former (a).

I think section 4.1.1.5 is fine. I think maybe the last sentence in 3.2 first paragraph can be slightly changed, augmented with additional clauses, sentence or some note.

Before we get into that, you mentioned that the vendor misinterpreted the RFC 2821 specifications. Section 2.2.1 of RFC 2821 says:

  "Contemporary SMTP implementations MUST support the basic extension
   mechanisms.  For instance, servers MUST support the EHLO command even
   if they do not implement any specific extensions and clients SHOULD
   preferentially utilize EHLO rather than HELO."

It's not an issue about EHLO/HELO fallback logic or RSET then as the server does not support the EHLO command.

Regards,
-sm