--On Tuesday, 10 April, 2007 17:46 -0400 "Robert A. Rosenberg"
<hal9001(_at_)panix(_dot_)com> wrote:
At 13:23 +0100 on 04/10/2007, Tony Finch wrote about Re:
rfc2821bis-01 Issue 14 Continuation of 222 greeting and:
> Note: Unextended SMTP does not have any
commands that allow this type of reply, and so does
not have continue or abort commands.
I "believe" the last note had the intention to NOTE that
150 would be used as
> a response that the client will REACT too. The "Unextended
SMTP" implies they will be ignorant on how to react. i.e,
an ESMTP spec might
define this.
However, it is still in play for normal 2821 operations.
Absolutely not. The sentence you quoted means that 1xy
replies can only occur if an extension is specified to use
them. Without the server offering an explicit extension and
without the client explicitly activating that extension, they
cannot be used.
This is a question of semantics and definitions. Does
"Unextended SMTP" mean a command that is capable of being
issued due to occurring in the 220 reply to a EHLO connection
or does it mean a session started with EHLO as opposed to HELO?
I think that we can agree that using HELO is the original SMTP
Protocol. Using a EHLO EXTENDS this protocol so that you get a
220 list of EXTRA supported capabilities (most of which list
commands that can be issued to extend the protocol but some of
which by-themself provide the information needed for the
extension [I think SIZE is such a 220 reply that tells the MUA
the maximum acceptable message size]).
Thus the ability to accept EHLO can in-and-of-itself make an
SMTP Server capable of being defined as using the/an
"Unextended SMTP" Protocol (even if it does not return ANY
command extensions in its 220 reply).
Except that, other than imposing a few new (really clarified),
requirements, an extended server (one that accepts an EHLO
command sent by the client) is required to behave _exactly_ like
an unextended (RFC 821-compliant) server except for (i) the
return of a list of supported extensions as the multiline reply
(with a 250 code, not 220) to the EHLO command and (ii) altering
that base (again, 821-compliant) behavior precisely as specified
by the specifications of the particular extensions that are
offered by the server and, where required, requested by the
client.
I'm not positive that I understand what you are suggesting here,
but:
(1) The prohibition on the use of 1yz codes appears in RFC 821,
which is the definition for SMTP with no extensions at all
(including no EHLO command).
(2) There is nothing in RFC 1425 or its successors RFC 1651 or
RFC
1869 that authorizes the use of 1yz codes in the presence of
EHLO without specific extensions that might authorize it.
(3) There is nothing in any of those documents, or in 2821, that
standardizes or permits the use of extensions or options listed
in the 220 Greeting to which clients are expected to pay
attention.
(4) The prohibition on the use of 1yz codes is copied exactly
into 2821 from 821.
(5) To the best of my knowledge, there is no standards-track
extension defined and registered that authorizes specifies, or
requires the use of 1yz codes. Of course there may be private
extensions of which I'm not aware.
I think that means they are prohibited in SMTP unless an
extension is defined that specifies their use, context, and
semantics. And what I, at least, mean when I say "not available
in unextended SMTP" is that these codes should not be sent by
the server unless it has an agreement with the client --
expressed in a specific extension -- about how they are used,
what they mean, and how they are going to be interpreted. The
only standard way to arrange and validate that agreement
involves a specific extension being offered by the server and, I
believe in this case, being requested by the client in some
specific way (extra command or parameter on an existing mail
command).
I don't know how to say it any more clearly than that and, if
the text in 2821bis needs clarification, I would welcome
suggested text.
Or did I misunderstand what you were suggesting?
john