On Thu, 18 Nov 2004 11:54:13 EST, Bruce Lilly said:
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.
You know that, I know that - the internal thread got started due to
some software from vendors that really *should* know better (somebody's
MUA was apparently either sending an AUTH even though the server didn't say
AUTH,
or trying an AUTH type not advertised.. and the server requires AUTH based on
source IP, and the client was a migratory machine... can you see a headache
coming? ;)
To make life *really* interesting, the server software was (near as I can tell)
quite likely just sending back a '250 What evverrrrrrr..' and ignoring
the AUTH, so things Just Kept Sort Of Working (until the phase of the moon
changed.. (Either that, or the server was sending back a '5xx yeah, right'
that the client was ignoring.. ;)
Remember - maybe 10 or 15 years ago, it made sense to assume that the code
writer had at least skimmed the RFC. These days, they often seem to
intentionally disregard that idea (sometimes to create their own
almost-interoperable proprietary version, and sometimes just due to rampant
cluelessness - we *all* know plenty of vendors guilty of both... ;)
Remember - we're in the age where "Caution. Do Not Try This At Home.
Professional stunt idiot on closed course." and "Do not place live animals in
clothes dryer"... ;)
(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.
Right - my point was that requiring each extension to include its own
"thou shalt not send FOO unless..." wasn't a great way to be doing it,
because if an extension *failed* to say it, you could conceivably send
the extension's X-FOO verb because nobody else said it wasn't OK...
pgpgp8JxHjIXn.pgp
Description: PGP signature