ietf-smtp
[Top] [All Lists]

Re: RFC2821, section 4.1.1.1 and HELO/EHLO

2004-01-02 15:41:27

Arggh.

First, the ABNF is wrong given the text and, on behalf of myself and the several people who checked it, my/our apologies.

That said, there seems to be an open question on which discussion/ advice would be useful.

The text, as written, implies that the ABNF should have been

      Domain = (sub-domain 1*("." sub-domain)) /
        ( address-literal [ string ] )

and, while my memory is dim, I think that is exactly what was intended. In other words, if you say

      EHLO [1.2.3.4]
then you are strongly encouraged to say

EHLO [1.2.3.4] unnamed host, for questions mail to foobar(_at_)vt(_dot_)edu

But there is no need for any of that qualifying nonsense with a domain name. One might imagine passwords, etc., out there, but the design model says that those are expected to go in a separate command, on MAIL FROM, etc., after the server authorizes (or requires) sending them.

Is that what is wanted, or should the ABNF be

      Domain = ( (sub-domain 1*("." sub-domain)) /
         address-literal ) [ string ]

??

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

I'd say it's section 4.1.1.1 that's b0rked. If you allow free
form "information" after the FQDN/address-literal it makes it
impossible to parse (ESMTP) parameters for EHLO.

Bob, I don't see the issue you are trying to get at. The model is that the server/ SMTP receiver announces itself with a largely information-free sanity-check banner, e.g.,
   220  bogus.domain.name here
the client / SMTP sender opens the actual mail processing by asking for capabilities and indicating that it can accept them with, e.g.,
   EHLO mail-client.example.com
then the server responds with capabilities and, after that, the client starts using/ requesting whatever subset of the capability list makes sense. There has never been any model for the client to announce anything to the server at EHLO time, nor to put any ESMTP parameters there.

   john


--On Friday, 02 January, 2004 13:50 -0500 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

Kari Hurtta pointed this out to me on the Sendmail development
list while we discussed what the Right Thing To Do for
hostname-challenged machines was..

Section 4.1.1.1 says:

   These commands are used to identify the SMTP client to the
SMTP     server.  The argument field contains the
fully-qualified domain name    of the SMTP client if one is
available.  In situations in which the    SMTP client system
does not have a meaningful domain name (e.g., when    its
address is dynamically allocated and no reverse mapping record
is    available), the client SHOULD send an address literal
(see section    4.1.3), optionally followed by information
that will help to identify    the client system.  y The SMTP
server identifies itself to the SMTP    client in the
connection greeting reply and in the response to this
command.

It then goes on:

   Syntax:

      ehlo            = "EHLO" SP Domain CRLF
      helo            = "HELO" SP Domain CRLF

And in 4.1.2 we find this ABNF:

      Domain = (sub-domain 1*("." sub-domain)) /
address-literal       sub-domain = Let-dig [Ldh-str]

      address-literal = "[" IPv4-address-literal /
                            IPv6-address-literal /
                            General-address-literal "]"
            ; See section 4.1.3

By my reading, this allows 'ehlo F.Q.D.N' and 'ehlo
[add.ress.lit.eral]', but there is no way to actually generate
'optionally followed by information' using the ABNF as written.

Am I caffeine-challenged, or is the ABNF actually borked on
this?