[Top] [All Lists]

Re: Using RSET with the EHLO/HELO fallback logic

2008-02-26 01:43:46

John C Klensin wrote:

Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Sun, 24 Feb 2008 16:16:02 EST, Hector Santos said:

   S: 220 **************************************************
   C: EHLO
   S: 500 Syntax error, command unrecognized
Am I the only one who thinks that if the remote end doesn't
understand EHLO, it's highly unlikely that any revision of
2821 is going to improve matters?  RFC1425 was a *long* time

Yep.  And, of course, that is also why the second paragraph of
2.2.1 ("Contemporary SMTP implementations MUST support...") says
what it does.  The theory, going back to early discussions in
DRUMS, is that support for EHLO is now mandatory and so the
fallback cases should not arise.  One's alternative is to
conform to 821 only, in which cas, as you suggest, anything
2821bis says is likely to be irrelevant.

It continues to be reasonable to have some instructions in
2821bis about interoperation between 2821/2821bis
implementations and 821 ones, but we shouldn't expect the latter
to change their behavior without also becoming 2821-conforming.

John, I know you and tony made a decision, which is fine, so none of this is to change your mind, but just as extra comments on the subject.

I agree, but I think the matter is with active, contemporary SMTP clients who will read the specs and might come across those legacy systems who will not, can not change or can take MONTHS for an update.

Lets consider what might be a BCP for a client initiation and fall back logic. To do it right based on what we all know today, to have automation, support cost reduction logic, the code would be close to the following:

 // Client Initiation and Fall back Logic

 nReplyCode = SendReceive("EHLO "+sClientHostName, sResponse);

 if (nReplyCode >= 500 && nReplyCode < 503) {

    // Fallback to HELO
    // Some servers might need a RSET in the fallback logic

    nReplyCode = SendReceive("RSET", sResponse);

    // According to RFC 1869, some servers might issue a
    // "503 out of sequence" response. RFC 1869 recommends to
    // ignore the 503 response and continue with the HELO
    // fallback.

    if (nReplyCode != 250 && nReplyCode !=503) {
       nReplyCode = SendReceive("QUIT", sResponse);
       return sFalse;

    nReplyCode = SendReceive("HELO "+sHostName, sResponse);

    if (nReplyCode != 250) {
        nReplyCode = SendReceive("QUIT", sResponse);
        return sFalse;
 return sTrue; // continue with next command

But this logic an only be extracted from 2821bis if the insights existed in the specs.

So you have 3 scenarios for a BCP:

  1) EHLO/HELO sequence (run into potential fallback issues per 1869),

  2) EHLO/RSET/HELO sequence honor all response codes (like
     we have in our code currently),

  3) EHLO/RSET/HELO sequence honoring all response codes except
     any RSET 503 possible response per 1869.

All are correct (or allowed) per specs, but which one offers the better success across the board?

I think that would be #3.


Hector Santos, CTO