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 yyyyyyy.com
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
ago....
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com