[Top] [All Lists]

Re: domain name definition in RFC2821

2006-04-22 09:54:59

--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?

Yuri Inglikov


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

Note that this pair of productions have been tentatively changed

   Domain = (sub-domain 1*("." 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 ["."] )

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.

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.


<Prev in Thread] Current Thread [Next in Thread>