ietf-smtp
[Top] [All Lists]

Re: RFC2821, section 4.1.1.1 and HELO/EHLO

2004-01-03 08:25:43

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 4.1.1.1)

     ehlo   = "EHLO" SP ( Domain / Explained-literal ) CRLF
     helo   = "HELO" SP Domain CRLF

and then in 4.1.1.1 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.

Also...

--On Friday, 02 January, 2004 23:41 +0000 "B. Johannessen" <bob(_at_)db(_dot_)org> wrote:

For
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).

   john