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