On Thu November 18 2004 10:06, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
Yes. The whole *point* is that nowhere in 2.2 does it *say* that (for
example)
the client is in the wrong if it sends a BDAT verb (rfc3030) if the
BDAT extension wasn't listed in the EHLO response.
Recall that RFC 2119 restricts use of imperatives to situations where
they are necessary to ensure interoperability. "MUST"/"MUST NOT"
would be inappropriate because such a requirement/prohibition is
not necessary (in general) to ensure interoperability -- an SMTP
server can issue a 5yz response to any command, whether it's
"BLURFL" or "VRFY" or "X-FOOBAR". A recommendation
("SHOULD"/"SHOULD NOT") might be appropriate, but even a
casual reading of 2.2 should be sufficient to inform client
software authors that sending an unsupported extension
command (i.e. one not corresponding to an extension listed in an
EHLO response) or a command parameter in the absence of an
extension which is required to use that parameter is likely to result
in failure.
We all *know* sending that sending a BDAT un-negotiated is wrong
BDAT is an unusual case, where its use w/o negotiation (via the CHUN-
KING EHLO keyword (a.k.a. the "rice-a-roni" extension)) could
conceivably cause some bizarre consequences (depending on the
data sent after the command being interpreted as a series of SMTP
commands). In other cases (where there is a server response
before the client sends further data), the server has the option of
sending a negative (5yz) response.
- what
brought this up was a thread on a local mailing list where somebody asked
if the EHLO list was authoritative, and I went to reply with the
chapter-and-verse
and came up empty-handed... ;)
A positive response to EHLO contains by definition a list of supported
extensions. So, yes, it is authoritative as described in RFC 2821
section 2.2.2. Note that the EHLO keywords are not necessarily the
same as the names of extension commands (e.g. "CHUNKING" vs.
"BDAT").
(As an aside, rfc3030 *does* contain language in section 3 that prohibits
sending a BDAT to a server that didn't advertise the extension. However,
consider an X-FOOBAR extension that adds verbs/parameters, but whose
documentation, if any, doesn't contain similar language....)
Keywords beginning with (case-insensitive) "X-" are a special case;
they require bilateral agreement and cannot be registered. Therefore
both client and server have to agree on syntax and semantics in
some unspecified manner. As in many other cases where the "x-"
prefix is used, its value lies primarily in providing a mechanism for
testing interoperation of proposed features prior to publication of
a standard; it avoids a chicken-and-egg situation during protocol
development.