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