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 **************************************************
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.
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:
4.1.1.5 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 4.1.1.5, 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
possible?
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 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.
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com