Re: RFC2821, section 188.8.131.52 and HELO/EHLO
My apologies to all -- I was distracted yesterday evening and
should not try to write ABNF in that state. Trying to put this
optional string into "Domain" would, indeed, mess up all sorts
of things and was not intended. Instead, the correct syntax
changes should, I think, be (in 184.108.40.206)
ehlo = "EHLO" SP ( Domain / Explained-literal ) CRLF
helo = "HELO" SP Domain CRLF
and then in 220.127.116.11 or 4.1.2, add
Explained-literal = address-literal [string]
i.e., for backward compatibility (and some stupidity and spam
resistance) HELO does not change at all, no embedded spaces are
permitted after "HELO ". EHLO either gets a strict domain name
string, or a literal, either with or without explanatory text.
Of course, if the better solution were to permit the explanatory
text with the domain name as well (I'm convinced this morning,
after skimming the thread, that it is not desirable), then the
transformation above to "Explained-domain" is obvious. And HELO
(and other commands) still don't change.
--On Friday, 02 January, 2004 23:41 +0000 "B. Johannessen"
some reason I had the idea that (SMTP) extensions where allowed
to define parameters for EHLO as well. Must have been the 3rd
item in the requirements that got me confused:
- the syntax and possible values of parameters associated with
the EHLO keyword value;
Better phrasing would be welcomed, but that really refers to the
use of the permitted extensions in other commands.
But on the other hand (and probably part of the reason I got it
wrong in the first place) wouldn't it have been useful, in some
cases, to allow parameters for EHLO? Or to put it another way,
was there any good reasons *not* to allow parameters for EHLO?
If I remember the reasoning at the time, it was largely that
unnecessary flexibility just leads to problems and
incompatibilities and no one could come up with a good reason
for such parameters. More generally, one really doesn't want to
have multiple negotiation models floating around. The current
one is "client tells server it is willing to accept capabilities
for negotiation, server tells client what capabilities it
supports, client asks for whatever options with that range that
it wants". The only value for an EHLO parameter that I can see
would be to introduce a "client tells server which options it
wants to negotiate, server indicates what it is willing to
accept from that range, client asks for a subset of the agreed
list". Mostly just different; the only major advantage of the
current model is that it doesn't get tied up with requiring a
longer line length on EHLO (commands or parameters authorized in
the EHLO response can expand the required minimum command
length, and continuation lines bypass the limit for responses,
but there is no way to do it for the EHLO command line).