--On Saturday, 22 April, 2006 09:25 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
--On Friday, 21 April, 2006 21:44 -0700 Yuri Inglikov
<Yuri(_dot_)Inglikov(_at_)microsoft(_dot_)com> wrote:
There appears to be some disconnect between ABNF syntax and
a prose. I.e. it appears that ABNF requires at least 2
sub-domain parts, while prose discusses "one or more
dot-separated components". Which one is "more correct" and
any scenario when a single-component domain name can be
valid / useful in modern SMTP?
Thanks,
Yuri Inglikov
RFC2821:
Domain = (sub-domain 1*("." sub-domain)) /
address-literal sub-domain = Let-dig [Ldh-str]
Note that this pair of productions have been tentatively
changed to:
Domain = (sub-domain 1*("." sub-domain) ["."] ) /
sub-domain["."]
Two problems here, one minor and one major.
The minor problem is that while this is technically correct,
RFC 2234 recommends use of grouping to make explicit
concatenation groups when alternation is used. So this is
better written as:
Domain = ( sub-domain 1*("." sub-domain) ["."] ) /
( sub-domain ["."] )
Arggh. Fixed. Perhaps the whole business should be taken out
(see below) but, for the time being, it should at least be
consistent with 2234.
The major problem is that this, for the first time, makes
trailing dots legal in email addresses. (This has never been
allowed before: RFCs 821, 822, 2821, and 2822 are quite clear
on the matter.
Now, it is certainly true that some implementations, mine
included, allow trailing dots, due no doubt to the seepage of
this convention from DNS tools into email. Nevertheless, this
represents a major change and a major break with backwards
compatibility.
Hmm. While 821 and 822 were clear on this, I have always
interpreted RFC 1123, section 6.1.4.3 (a), as requiring support
for this convention in email programs, at least for MUA<->user
interfaces that support any sort of abbreviated names. So, when
it was pointed out to me in November 2004 that the DNS spec,
updated by 1123, appeared to require this, I treated it as a bug
in 2821 and made the change. That change (with the syntax that,
as you point out, is also slightly problematic) was in
draft-klensin-rfc2821bis-00; apparently no one noticed.
Obviously the change should have been more widely highlighted
and discussed.
in draft-klensin-rfc2821bis-00.txt, posted July 2005 and now
presumably expired. After some discussion (many months prior
to this posting), the working draft for -01 has been
tentatively modified require the trailing period in the
second case and to explain the situation in the paragraph you
cite.
I'll comment on the whole short form name vs. TLD issue
separately, but I remain to be convinced this issue is of
sufficient gravity to justify a major syntax change in email.
This issue again emphasizes the reasons why it would be
desirable to get out a clean revision/update to RFC2821. But
that target is impossible if any discussion is going to be
overwhelmed by arguments about anti-spam measures and how
email might work better if fundamental principles were
changed.
OK... But I have to note that one of those fundamental
principles is backwards compatibility.
The intention was not to break backward compatibility but to
make what, perhaps naively, seemed to me to be a correction to
bring 2821 into alignment with what I assumed to be the standard
at the time it was written, i.e., in this area, 821 + 1123. As
I now go back and reread 1123, it is easy to make the case that
this syntax change should not be made in 2821bis at all: since
2821 deals only in FQDNs, there is no need to deal with partial
names, or conventions for avoiding searching, in the envelope at
all.
However, this issue does, I think, have some impact on the
submission server text in 2821, on RFC2476 and 2476bis (aka RFC
44098, about to emerge from Last Call): those cases can,
explicitly, deal with name completion, so the RFC 1123
provisions would seem to apply. As to 2822, whether changes are
needed there depends on precisely the contexts in which it
applies (e.g., whether to the user-MUA or MUA-MTA or MSA
interfaces or only in transport)... a problem that we have been
very successful in not explicitly facing.
So I think it is time for some serious discussion on the issue.
There is little chance of 2821bis-01 being posted before it is
resolved :-(
In the interim, Yuri, let me revise my advice: the robustness
principle probably argues that you should accept these trailing
periods if possible, but that putting them on the wire is
probably a poor idea.
john