Re: 2821bis ABNF diff

[Frank Ellermann <[e-mail]>]

Tony Finch wrote:

> I'm aware of the bug in 2822 which forbade the use of TLDs
> as mail domains, but I'm not sure that allowing the DNS's
> terminating dot in a mail domain is a good innovation.

s/bug/feature/ ;-)

> plenty of software checks this strictly. It would probably
> introduce interoperability problems.

Another way to transform a "bug" into a feature is to document
it, a bit more verbose than the old 1*("." sub-domain) syntax,
minimally add a line of prose.

> A better phrasing in ABNF would be
>         Domain = (sub-domain *("." sub-domain))

No, that's a bad idea, existing software might check the old
"at least one dot" rule.

There are several issues with the domain + literal ABNF:

- top priority, crap like "helo xyzzy" or "ehlo oemcomputer"
  is acceptable for an MSA (ater SMTP AUTH or similar), but
  not from unknown strangers.  It's _wrong_ for (2)821(bis).

  "We" (I hope) want to harden both "hellos", among others.

- "TLD is also a host" is a special case, there aren't many
  TLDs.  If you are sure that "optional trailing dot" won't
  work we could still require a trailing dot only for these
  special cases:

### old proposal ###
  Domain         = (sub-domain 1*("." sub-domain) ["."] ) /
                    sub-domain["."]
### new proposal ###
  Domain         = (sub-domain 1*("." sub-domain)) /
                   (sub-domain ".")
#### ########### ###

That's more like John's original idea when I asked him about
"bug or feature" last year.  The -00 draft got this wrong, no
square brackets in the second line.  What he really wanted
was probably...

  Domain         = 1*(sub-domain ".") [sub-domain]

...keeping the "at least one dot" idea.  Now if you say that
a trailing dot breaks existing software we're stuck, my idea
"required for TLDs, nowhere else allowed" is a foul compromise.

Plan B is to stick to the old syntax, adding a note that a
TLD should have no problem to create e.g. mail.TLD  as a host
name if it intends to participate in anything remotely related
to mail.

Also ugly, that's a conflict with 2822 <addr-spec> (or rather
<dot-atom-text>), the 2822 syntax has no "at least one dot",
the semantics (3.4.1 addr-spec specifiation) points to 2821.

Related syntax issues:

IMHO we should adopt the <toplabel> idea in 2821bis.  While
2821 is clear that a <literal-address> always has square
brackets, it's not clear about what is certainly not a FQDN.

Already discussed here some months ago (with Hector, Claus,
John, and others), and IIRC Claus said that the 2821-syntax
forces him to query the DNS for crap like EHLO 123.45.67.89

And _maybe_ that's related to draft-ietf-dnsop-bad-dns-res-04
chapter 2.9 queries for domain names resembling IPv4 addresses.

By adopting a <toplabel> rule found elsewhere (e.g. 3696) we
could silently fix this in 2821bis.

I'd also like to discuss some other syntax issues, especially:

- the use of CTL or rather NO-WS-CTL (IMHO unnecessary) in some
  productions, even NUL e.g. in <ehlo-greet>.

- the import of <dcontent> for <General-Address-Literal> (that
  is where NO-WS-CTL is used - at least no NU, but still bad).

  I prefer <IPvFuture> as specified in STD 66 (3986) for this
  (hypothetical) case.

- the, sorry, weird "IPv6:" tag in 2821.  Maybe it's too late
  to kill it, but we could say that it's deprecated.  AFAIK
  it's possible to remove / replace unused "features" in a DS.

  The "IPv6:" is ugly like hell, the STD 66 syntax is better -
  I'm only talking about <address-literal> here, of course
  STD 66 has its own dark corners.   OTOH that standard is an
  example how they got away with huge differences from PS to
  STD => 2821bis isn't forced to copy all dubious 2821 ideas.

                              Bye, Frank