[Top] [All Lists]

Using RSET with the EHLO/HELO fallback logic

2008-02-24 14:34:22

John et al,

I honestly do not wish this to be a major thread/debate, and certainly not delay any process for 2821bis. I just want to point it out and leave the rest to you. I don't wish to leave out any details, but I don't also want to get too deep. So I will be depending on your experience and foresight to fill in any gaps.

I was going to post this note last month, but knowing how you and Tony have worked hard and wish to complete this 2821bis process, I decide to forgo it.

But I bring it up now primarily for two reasons:

1) I was reminded of it with the MX/CNAME discussion and I am one that prefers to reduce the "blame game" in customer support and production market, and

2) A major brand name SMTP/AVS Appliance (VENDOR) misinterpreted the RFC 2821 specs when it came to the RSET command. If a major brand name had this issue, certainly it can happen with others.

The RSET situation created a sensitive customer support issue with one of their new large accounts. It escalated to "who is more RFC 2821 correct" blame game between four parties with teleconference calls between our customer, their new customer, their customer mail system appliance vendor and us.

So if you think there is amble room/time and deemed reasonable to include some extra text regarding the usage of the RSET command, I leave you to decide that.

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 **************************************************
  S: 500 Syntax error, command unrecognized
  S: 503 Bad sequence of commands
  S: 221 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.

In the final analysis, the VENDOR realized the "error in their ways" and fixed the situation once the specific RSET text in RFC 2821 was shown to them: RESET (RSET)

   A reset command may be issued by the client at any time.  It is
   effectively equivalent to a NOOP (i.e., if has no effect) if issued
   immediately after EHLO, before EHLO is issued in the session, after
   an end-of-data indicator has been sent and acknowledged, or
   immediately before a QUIT.

So here, we can pop up a bottle of champagne and proclaim victory:

    "The system work! The RFC docs showed the errors of
     their ways!"

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, but I can see where that mistake can be made.

One the other hand, if someone reads RFC 821, there is little semantics on when RSET can be issued. So in some defense for the vendor, I can also see how their software offers an option to run in RFC 821 legacy mode and may see the RSET before a HELO as out of sequence.

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.

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

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

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

Personally, I prefer the former (a).

I think section 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.

I am just giving an example, maybe others can write it better.

   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.

   Note: Clients MAY issue the RSET command after the EHLO command
   before issuing the HELO fall back command.  Servers MUST not
   view this as an out of sequence state.

By having a simple text like above, future servers will not fall into this RSET after EHLO error.

Hope this make sense and I hope I provide enough reason, information and how it can be misinterpreted as reflected in a large mail vendor behavior.


Hector Santos, CTO