Subject: RE: domain name definition in RFC2821
From: [email-masked]
To: Yuri Inglikov <[email-masked]>
Cc: John C Klensin <[email-masked]>, Ned Freed <[email-masked]>, ValdisKletnieksvtedu <[email-masked]>, williamatelannet <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Date: Sat, 22 Apr 2006 16:21:26 -0700 (PDT)
List-Id: <ietf-smtp.imc.org>

> Thank you all for very insightful discussion.

> My conclusion for the initial question is that we need to fully support
> single-component domain names and ABNF production in RFC2821 is an error.

That's the way I see it.

> Supporting single-component domain names should not be a problem as long as it
> is clear from the context that this is indeed FQDN and not an abbreviation.

Of course this is very implementation-specific. In our code, for example,
whether or not a single-component name is treated as a short forn name or 
as a TLD is configurable, if necessary on a per-domain basis.

> For the trailing dot in a domain name, I understand that accepting it can be
> desirable, although it is legal/fine to be stricter and reject such domain
> names as invalid. Of course it must never be produced.

Agreed.

				Ned

Cc: "william(at)elan.net" <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821 
From: [email-masked]
Date: Sun, 23 Apr 2006 04:09:39 -0400
Sender: [email-masked]

--==_Exmh_1145779779_3800P
Content-Type: text/plain; charset=us-ascii

On Sun, 23 Apr 2006 02:36:32 EDT, [email-masked] said:

> That's the first occurrence of (at) that I can see...

I need to quit trying to read e-mail headers at 2:30AM.  John's posting
was a reply to one of Ned's messages which also had the mangling of (at),
but Ned's mail was like 7 messages later in the folder, and I failed to
twig onto the mis-ordering....

(What irritates me is that I checked the msgid's in the References: and
In-Reply-To:'s, and *still* managed to botch it).

And yes, it's now 4AM. The only thing worse than insomnia is a small
herd of bored mischievous insomniac housecats.... ;)

--==_Exmh_1145779779_3800P
Content-Type: application/pgp-signature

--==_Exmh_1145779779_3800P--

To: "william(at)elan.net" <[email-masked]>
Cc: [email-masked]
Subject: Re: domain name definition in RFC2821 
From: [email-masked]
Date: Sun, 23 Apr 2006 02:36:32 -0400
Sender: [email-masked]

--==_Exmh_1145774192_3800P
Content-Type: text/plain; charset=us-ascii

On Sat, 22 Apr 2006 13:12:22 PDT, "william(at)elan.net" said:
> 
> 
> | Cc: Yuri Inglikov <[email-masked]>, [email-masked],
> |    williamatelannet <[email-masked]>, [email-masked]
> 
> I'm curious which of your systems collapsed the "pretty name" part of my 
> email address from "william(at)elan.net" into the above?

Seems to be John Klensin's Mulberry setup:

Date: Sat, 22 Apr 2006 13:22:13 -0400
From: John C Klensin <[email-masked]>
Subject: RE: domain name definition in RFC2821
In-reply-to: <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Yuri Inglikov <[email-masked]>, [email-masked],         williamatelannet
 <[email-masked]>, [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.4 (Win32)

That's the first occurrence of (at) that I can see...

--==_Exmh_1145774192_3800P
Content-Type: application/pgp-signature

--==_Exmh_1145774192_3800P--

Date: Sat, 22 Apr 2006 13:12:22 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

| Cc: Yuri Inglikov <[email-masked]>, [email-masked],
|    williamatelannet <[email-masked]>, [email-masked]

I'm curious which of your systems collapsed the "pretty name" part of my 
email address from "william(at)elan.net" into the above?

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Sat, 22 Apr 2006 20:53:20 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Ned Freed <[email-masked]>, [email-masked]
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

On Sat, 22 Apr 2006, John C Klensin wrote:
>
> Ack.  Unless others disagree with Ned's (IMO extremely coherent)
> analysis, I'll pull the changes out of 2821bis.

Trailing dots are rejected as syntax errors by Exim if not by other MTAs.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH BISCAY: EAST BECOMING VARIABLE 3 OR 4, THEN
NORTHEAST 4 OR 5 LATER IN DOVER AND WIGHT. RAIN LATER. MODERATE.

From: [email-masked]
Cc: Yuri Inglikov <[email-masked]>, [email-masked], williamatelannet <[email-masked]>, [email-masked]
To: John C Klensin <[email-masked]>
Date: Sat, 22 Apr 2006 11:35:29 -0700 (PDT)
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

> > (For instance, on my Fedora Linux box, the default resolv.conf
> > setting of 'options ndots:1' means that 'ws' will be
> > canonalized to a FQDN, while 'ws.' will behave the way Yuri
> > apparently expects 'ws' to work.  Now try to explain to your
> > average end user why 'postmaster@ws' and 'postmaster@ws.' do
> > different things....

> That is, indeed, an issue.

That's an understatement comparable to saying the Pacific Ocean is a little
wet.

The situation here at Sun is a good example. There's a vast infrastructure that
makes heavy use of short form names. Considerable effort has been expended to
switch away from, say, ned.freed@west to FQDN forms like [email-masked]. But
an essential ingredient in making this work is to canonicalize short form names
into FQDNs. And this applies not only to email but also to web services.

It you told the folks in SunIT that, say, postmaster@ws needs to work
"correctly" my guess is they'd just about fall over laughing. And they'd only
laugh harder if you pointed out that the current behavior is a standards
violation.

I've dealt with dozens of other companies with email setups of comparable scale
to Sun's, and I can tell you that plenty of them make extensive use of short
form name canonicalization. And some of them do stuff in this space that makes
what Sun does look _rational_.

Add to this the fact that many systems besides Fedora Linux are set to
canonizalize short form names out of the box, and I'm afraid this particular
genie is not going back in the bottle.

There are lots of standards battles worth fighting. This IMO isn't one of them.

				Ned

From: Yuri Inglikov <[email-masked]>
To: John C Klensin <[email-masked]>, Ned Freed <[email-masked]>
CC: "[email-masked]" <[email-masked]>, williamatelannet <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 22 Apr 2006 11:06:16 -0700
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

Thank you all for very insightful discussion.

My conclusion for the initial question is that we need to fully support single-component domain names and ABNF production in RFC2821 is an error. Supporting single-component domain names should not be a problem as long as it is clear from the context that this is indeed FQDN and not an abbreviation.

For the trailing dot in a domain name, I understand that accepting it can be desirable, although it is legal/fine to be stricter and reject such domain names as invalid. Of course it must never be produced.

Please let me know if my interpretation is incorrect.

Yuri Inglikov

-----Original Message-----
From: John C Klensin [mailto:[email-masked]]

Ack.  Unless others disagree with Ned's (IMO extremely coherent)
analysis, I'll pull the changes out of 2821bis.

    john

Date: Sat, 22 Apr 2006 13:22:13 -0400
From: John C Klensin <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Yuri Inglikov <[email-masked]>, [email-masked], williamatelannet <[email-masked]>, [email-masked]
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

Ack.  Unless others disagree with Ned's (IMO extremely coherent)
analysis, I'll pull the changes out of 2821bis.

    john

--On Saturday, 22 April, 2006 09:37 -0700 Ned Freed
<[email-masked]> wrote:

> 
> 
> 
>> --On Saturday, 22 April, 2006 01:27 -0700 Yuri Inglikov
>> <[email-masked]> wrote:
> 
>> > 
>> > By the way the "ws." syntax appears "invalid" according to
>> > every RFC I read.
> 
>> Except the base DNS specs and RFC 1123, which makes accepting
>> it mandatory everywhere.
> 
> Um, actually, not only does it not say that, it says exactly
> the opposite. Section 5.2.18 describes "common address
> formatting ERRORS" (emphasis mine). The fourth bullet item is:
> 
>          o    Some systems over-qualify domain names by adding
> a               trailing dot to some or all domain names in
> addresses or               message-ids.  This violates RFC-822
> syntax.
> 
> So you can add RFC 1123 to the list of email-related RFCs that
> describe trailing dots as a syntax error.
> 
> I can find no reference in RFC 1123 that says accepting a
> trailing dot is mandatory anywhere. The closest thing to this
> I can find is the statement in section 6.1.4.3 that:
> 
>            If an abbreviation method is provided, then:
> 
>            (a)  There MUST be some convention for denoting
> that a name                  is already complete, so that the
> abbreviation method(s)                  are suppressed.  A
> trailing dot is the usual method.
> 
> But this section is talking about user interfaces, not on-wire
> protocols. And it goes on to say that abbreviations need to be
> expanded - and the exmaple is "a mail program". Couple this
> with the previous assertion that trailing dots are syntax
> errors in email and the clear inference is that the user
> interface should remove the trailing dot if one is present.
> 
>> ...
> 
>> That is, indeed, an issue.  But, again, 1123 is crystal-clear
>> on the subject.  And the 2821bis  working draft is now
>> consistent with it.
> 
> Well, I agree that RFC 1123 is quite clear. But I think it
> pretty much says the opposite of this.
> 
>> Yuri, since you seem to be looking for the bottom line here, I
>> suggest it is:
> 
>> (1) Anywhere that "Domain" is permitted as a piece of syntax,
>> "Domain." is permitted.   Not supporting it is bad news.  If
>> you are working on this at Microsoft, note that IE supports
>> the trailing dot in domain names, so failure to support it in
>> email would presumably violate the law of least astonishment,
>> provide a surprising user experience, etc.
> 
> I have no problem with supporting a trailing dot in a user
> interface. Indeed, I think RFC 1123 can be read as suggesting
> (although not requiring) that this work.
> 
> However, I have a big problem with extending the on-wire
> syntax to include trailing dots. This is a clear break from
> past usage and I do not think the benefits are anywhere near
> commensurate with the costs.
> 
> 				Ned

From: [email-masked]
Cc: Yuri Inglikov <[email-masked]>, [email-masked], williamatelannet <[email-masked]>, [email-masked]
To: John C Klensin <[email-masked]>
Date: Sat, 22 Apr 2006 09:37:54 -0700 (PDT)
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

> --On Saturday, 22 April, 2006 01:27 -0700 Yuri Inglikov
> <[email-masked]> wrote:

> >
> > By the way the "ws." syntax appears "invalid" according to
> > every RFC I read.

> Except the base DNS specs and RFC 1123, which makes accepting it
> mandatory everywhere.

Um, actually, not only does it not say that, it says exactly the opposite.
Section 5.2.18 describes "common address formatting ERRORS" (emphasis mine).
The fourth bullet item is:

         o    Some systems over-qualify domain names by adding a
              trailing dot to some or all domain names in addresses or
              message-ids.  This violates RFC-822 syntax.

So you can add RFC 1123 to the list of email-related RFCs that describe
trailing dots as a syntax error.

I can find no reference in RFC 1123 that says accepting a trailing dot
is mandatory anywhere. The closest thing to this I can find is the statement
in section 6.1.4.3 that:

           If an abbreviation method is provided, then:

           (a)  There MUST be some convention for denoting that a name
                 is already complete, so that the abbreviation method(s)
                 are suppressed.  A trailing dot is the usual method.

But this section is talking about user interfaces, not on-wire protocols. And
it goes on to say that abbreviations need to be expanded - and the exmaple is
"a mail program". Couple this with the previous assertion that trailing dots
are syntax errors in email and the clear inference is that the user interface
should remove the trailing dot if one is present.

> ...

> That is, indeed, an issue.  But, again, 1123 is crystal-clear on
> the subject.  And the 2821bis  working draft is now consistent
> with it.

Well, I agree that RFC 1123 is quite clear. But I think it pretty
much says the opposite of this.

> Yuri, since you seem to be looking for the bottom line here, I
> suggest it is:

> (1) Anywhere that "Domain" is permitted as a piece of syntax,
> "Domain." is permitted.   Not supporting it is bad news.  If you
> are working on this at Microsoft, note that IE supports the
> trailing dot in domain names, so failure to support it in email
> would presumably violate the law of least astonishment, provide
> a surprising user experience, etc.

I have no problem with supporting a trailing dot in a user interface. Indeed,
I think RFC 1123 can be read as suggesting (although not requiring) that this
work.

However, I have a big problem with extending the on-wire syntax to include
trailing dots. This is a clear break from past usage and I do not think the
benefits are anywhere near commensurate with the costs.

				Ned

Date: Sat, 22 Apr 2006 13:11:21 -0400
From: John C Klensin <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Yuri Inglikov <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Saturday, 22 April, 2006 09:25 -0700 Ned Freed
<[email-masked]> wrote:

>> --On Friday, 21 April, 2006 21:44 -0700 Yuri Inglikov
>> <[email-masked]> 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

Date: Sat, 22 Apr 2006 09:51:05 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: domain name definition in RFC2821
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Apr 22, 2006, John C Klensin wrote:

> Note that this pair of productions have been tentatively changed
> to:
> 
>    Domain = (sub-domain 1*("." sub-domain) ["."] ) /
>                      sub-domain["."]

This is breaking existing implementations that perform strict syntax
checks.  Why is it necessary to allow a trailing dot suddenly?

From: [email-masked]
Cc: Yuri Inglikov <[email-masked]>, [email-masked]
To: John C Klensin <[email-masked]>
Date: Sat, 22 Apr 2006 09:25:51 -0700 (PDT)
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

> --On Friday, 21 April, 2006 21:44 -0700 Yuri Inglikov
> <[email-masked]> 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 ["."] )

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.

				Ned

Date: Sat, 22 Apr 2006 05:01:24 -0400
From: John C Klensin <[email-masked]>
To: Yuri Inglikov <[email-masked]>, [email-masked], "william(at)elan.net" <[email-masked]>
cc: [email-masked]
Subject: RE: domain name definition in RFC2821
Sender: [email-masked]

--On Saturday, 22 April, 2006 01:27 -0700 Yuri Inglikov
<[email-masked]> wrote:

> 
> By the way the "ws." syntax appears "invalid" according to
> every RFC I read.

Except the base DNS specs and RFC 1123, which makes accepting it
mandatory everywhere.

See also below.

    john

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, April 22, 2006 1:13 AM
> To: william(at)elan.net
> Cc: Yuri Inglikov; [email-masked]
> Subject: Re: domain name definition in RFC2821
> 
>> postmaster@ws ?
> 
> ws.                     21600   IN      MX      10
> mail.worldsite.ws.
> 
> Gaak.  I hope that's not a wildcard MX. ;)
> 
> A 4AM re-reading of 2821 seems to indicate that's a *legal*
> setup.

It really has been since RFC 1123, although it has also been
considered bad practice.  2821 is obviously not clear enough on
the subject; the working version of 2821bis is now crystal-clear
after a little patching this morning.

>  But I suspect there are *so* many software packages
> that will try to convert '@ws' to a FQDN at message submission
> time as per 2821, section 6.3:
> 
>    The following changes to a message being processed MAY be
> applied    when necessary by an originating SMTP server, or
> one used as the    target of SMTP as an initial posting
> protocol:
> 
>    -  Addition of a message-id field when none appears
> 
>    -  Addition of a date, time or time zone when none appears
> 
>    -  Correction of addresses to proper FQDN format
> 
> (For instance, on my Fedora Linux box, the default resolv.conf
> setting of 'options ndots:1' means that 'ws' will be
> canonalized to a FQDN, while 'ws.' will behave the way Yuri
> apparently expects 'ws' to work.  Now try to explain to your
> average end user why 'postmaster@ws' and 'postmaster@ws.' do
> different things....

That is, indeed, an issue.  But, again, 1123 is crystal-clear on
the subject.  And the 2821bis  working draft is now consistent
with it.

Yuri, since you seem to be looking for the bottom line here, I
suggest it is:

(1) Anywhere that "Domain" is permitted as a piece of syntax,
"Domain." is permitted.   Not supporting it is bad news.  If you
are working on this at Microsoft, note that IE supports the
trailing dot in domain names, so failure to support it in email
would presumably violate the law of least astonishment, provide
a surprising user experience, etc.

(2) Because of the widespread historical support for a single
apparent label as an abbreviation of some sort (most often an
indication that a search rule, alias substitution, or completion
algorithm external to SMTP should be applied)
   user@single-label
should be discouraged.  If someone needs to reference a TLD as a
mail address, or a TLD in any other way than as part of an FQDN
with more labels, it should appear with the trailing period,
i.e., as
  user@single-label.
I believe that advice is consistent with RFC 1123

regards,
     john

Date: Sat, 22 Apr 2006 04:29:27 -0400
From: John C Klensin <[email-masked]>
To: Yuri Inglikov <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Friday, 21 April, 2006 21:44 -0700 Yuri Inglikov
<[email-masked]> 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["."]

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.

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.

     john

From: Yuri Inglikov <[email-masked]>
To: "[email-masked]" <[email-masked]>, "william(at)elan.net" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Sat, 22 Apr 2006 01:27:57 -0700
Subject: RE: domain name definition in RFC2821 
Sender: [email-masked]

By the way the "ws." syntax appears "invalid" according to every RFC I read.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, April 22, 2006 1:13 AM
To: william(at)elan.net
Cc: Yuri Inglikov; [email-masked]
Subject: Re: domain name definition in RFC2821

> postmaster@ws ?

ws.                     21600   IN      MX      10 mail.worldsite.ws.

Gaak.  I hope that's not a wildcard MX. ;)

A 4AM re-reading of 2821 seems to indicate that's a *legal* setup.  But
I suspect there are *so* many software packages that will try to convert
'@ws' to a FQDN at message submission time as per 2821, section 6.3:

   The following changes to a message being processed MAY be applied
   when necessary by an originating SMTP server, or one used as the
   target of SMTP as an initial posting protocol:

   -  Addition of a message-id field when none appears

   -  Addition of a date, time or time zone when none appears

   -  Correction of addresses to proper FQDN format

(For instance, on my Fedora Linux box, the default resolv.conf setting of
'options ndots:1' means that 'ws' will be canonalized to a FQDN, while
'ws.' will behave the way Yuri apparently expects 'ws' to work.  Now
try to explain to your average end user why 'postmaster@ws' and
'postmaster@ws.' do different things....

To: "william(at)elan.net" <[email-masked]>
Cc: Yuri Inglikov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: domain name definition in RFC2821 
From: [email-masked]
Date: Sat, 22 Apr 2006 04:13:01 -0400
Sender: [email-masked]

--==_Exmh_1145693580_14141P
Content-Type: text/plain; charset=us-ascii

On Sat, 22 Apr 2006 00:12:17 PDT, "william(at)elan.net" said:
> On Sat, 22 Apr 2006 [email-masked] wrote:
> > Can you give an example of a "single-component domain name" that would *not*
> > be flagged as a failure to canonalize to a FQDN?
> >
> > Are there any e-mail addresses that *work* (or even could *potentially* work)
> > of the form 'userid@com' or 'userid@net' or 'some.full.name@to' or anything
> > else like that?
> 
> postmaster@ws ?

ws.                     21600   IN      MX      10 mail.worldsite.ws.

Gaak.  I hope that's not a wildcard MX. ;)

A 4AM re-reading of 2821 seems to indicate that's a *legal* setup.  But
I suspect there are *so* many software packages that will try to convert
'@ws' to a FQDN at message submission time as per 2821, section 6.3:

   The following changes to a message being processed MAY be applied
   when necessary by an originating SMTP server, or one used as the
   target of SMTP as an initial posting protocol:
   
   -  Addition of a message-id field when none appears

   -  Addition of a date, time or time zone when none appears

   -  Correction of addresses to proper FQDN format

(For instance, on my Fedora Linux box, the default resolv.conf setting of
'options ndots:1' means that 'ws' will be canonalized to a FQDN, while
'ws.' will behave the way Yuri apparently expects 'ws' to work.  Now
try to explain to your average end user why 'postmaster@ws' and
'postmaster@ws.' do different things....

--==_Exmh_1145693580_14141P
Content-Type: application/pgp-signature

--==_Exmh_1145693580_14141P--

From: Yuri Inglikov <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Sat, 22 Apr 2006 00:02:49 -0700
Subject: RE: domain name definition in RFC2821 
Sender: [email-masked]

Thank you for your reply. I am not trying to argue for or against the validity of such domain names or question RFC in any respect. Just want to get some feeling from people in this list how practically important a support for such domain names can be.

BTW, I can imagine something like god@heaven where 'heaven' is FQDN in a given DNS infrastructure. I.e. there is only one heaven in the universe and it is probably not a subordinate of any other entity. My understanding is that DNS is flexible enough to support this. What about practical examples?

Thanks,
Yuri Inglikov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 21, 2006 11:43 PM
To: Yuri Inglikov
Cc: [email-masked]
Subject: Re: domain name definition in RFC2821

On Fri, 21 Apr 2006 21:44:03 PDT, Yuri Inglikov said:
> There appears to be some disconnect between ABNF syntax and a prose. I.e. i t
> appears that ABNF requires at least 2 sub-domain parts, while prose discu sses
> "one or more dot-separated components". Which one is "more correct" an d any
> scenario when a single-component domain name can be valid / useful in modern
> SMTP?

Can you give an example of a "single-component domain name" that would *not*
be flagged as a failure to canonalize to a FQDN?

Are there any e-mail addresses that *work* (or even could *potentially* work)
of the form 'userid@com' or 'userid@net' or 'some.full.name@to' or anything
else like that?

(And even if you require 2 components, it's traditionally been ugly.  There
were a *lot* of university computing centers and comp-sci departments that were
quite surprised when all the addresses of the form [email-masked]' or
[email-masked]' were no longer recognized as a shorthand for
'server.cs.foo.edu' or 'server.cc.bar.edu'.  And some of us were around for
when British schools leaked reverse-order domain names, and [email-masked]'
went to another country rather than to U of Foo's CS dept...)

Date: Sat, 22 Apr 2006 03:43:37 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Yuri Inglikov <[email-masked]>
cc: [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Saturday, 22 April, 2006 02:42 -0400
[email-masked] wrote:

> On Fri, 21 Apr 2006 21:44:03 PDT, Yuri Inglikov said:
>> There appears to be some disconnect between ABNF syntax and a
>> prose. I.e. i t appears that ABNF requires at least 2
>> sub-domain parts, while prose discu sses "one or more
>> dot-separated components". Which one is "more correct" an d
>> any scenario when a single-component domain name can be valid
>> / useful in modern SMTP?
> 
> Can you give an example of a "single-component domain name"
> that would *not* be flagged as a failure to canonalize to a
> FQDN?
> 
> Are there any e-mail addresses that *work* (or even could
> *potentially* work) of the form 'userid@com' or 'userid@net'
> or 'some.full.name@to' or anything else like that?

While it has not been common practice, nothing in principle
prevents 
    Random-TLD.  NS server-for-Random-TLD.Random-TLD.
                 NS other-server.other-TLD.
                 MX mumble.somehost.some-TLD.
Knowing what I do about SMTP implementations and about the
problems, especially "search rules", you cite below, I'd
strongly recommend the use of 
   poor-sod@Random-TLD.
rather than
   poor-sod@Random-TLD
but...
 
> (And even if you require 2 components, it's traditionally been
> ugly.  There were a *lot* of university computing centers and
> comp-sci departments that were quite surprised when all the
> addresses of the form [email-masked]' or [email-masked]'
> were no longer recognized as a shorthand for
> 'server.cs.foo.edu' or 'server.cc.bar.edu'.  And some of us
> were around for when British schools leaked reverse-order
> domain names, and [email-masked]' went to another country
> rather than to U of Foo's CS dept...)

Yep.
    john

Date: Sat, 22 Apr 2006 00:17:26 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
cc: Yuri Inglikov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: domain name definition in RFC2821 
Sender: [email-masked]

On Sat, 22 Apr 2006, william(at)elan.net wrote:

>> Can you give an example of a "single-component domain name" that would 
>> *not*
>> be flagged as a failure to canonalize to a FQDN?
>> 
>> Are there any e-mail addresses that *work* (or even could *potentially* 
>> work)
>> of the form 'userid@com' or 'userid@net' or 'some.full.name@to' or anything
>> else like that?
>
> postmaster@ws ?

$dig mx ws
  <<>> DiG 9.3.1 <<>> mx ws
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49855
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; QUESTION SECTION:
;ws.                            IN      MX
;; ANSWER SECTION:
ws.                     21600   IN      MX      10 mail.worldsite.ws.

$ telnet mail.worldsite.ws 25
Trying 216.35.187.251...
Connected to mail.worldsite.ws (216.35.187.251).
Escape character is '^]'.
220 
****0**************************************************22*****200**00********0*00
HELO elan.net
250 mail01.worldsite.ws Hello [216.151.195.99], pleased to meet you
MAIL FROM:<>
250 2.1.0 <>... Sender ok
RCPT TO:postmaster@ws
250 2.1.5 postmaster@ws... Recipient ok

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Sat, 22 Apr 2006 00:12:17 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
cc: Yuri Inglikov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: domain name definition in RFC2821 
Sender: [email-masked]

On Sat, 22 Apr 2006 [email-masked] wrote:

> On Fri, 21 Apr 2006 21:44:03 PDT, Yuri Inglikov said:
>> There appears to be some disconnect between ABNF syntax and a prose. I.e. i t
>> appears that ABNF requires at least 2 sub-domain parts, while prose discu sses
>> "one or more dot-separated components". Which one is "more correct" an d any
>> scenario when a single-component domain name can be valid / useful in modern
>> SMTP?
>
> Can you give an example of a "single-component domain name" that would *not*
> be flagged as a failure to canonalize to a FQDN?
>
> Are there any e-mail addresses that *work* (or even could *potentially* work)
> of the form 'userid@com' or 'userid@net' or 'some.full.name@to' or anything
> else like that?

postmaster@ws ?

-- 
William Leibzon
Elan Networks
[email-masked]

To: Yuri Inglikov <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: domain name definition in RFC2821 
From: [email-masked]
Date: Sat, 22 Apr 2006 02:42:42 -0400
Sender: [email-masked]

--==_Exmh_1145688162_14141P
Content-Type: text/plain; charset=us-ascii

On Fri, 21 Apr 2006 21:44:03 PDT, Yuri Inglikov said:
> There appears to be some disconnect between ABNF syntax and a prose. I.e. i t
> appears that ABNF requires at least 2 sub-domain parts, while prose discu sses
> "one or more dot-separated components". Which one is "more correct" an d any
> scenario when a single-component domain name can be valid / useful in modern
> SMTP?

Can you give an example of a "single-component domain name" that would *not*
be flagged as a failure to canonalize to a FQDN?

Are there any e-mail addresses that *work* (or even could *potentially* work)
of the form 'userid@com' or 'userid@net' or 'some.full.name@to' or anything
else like that?

(And even if you require 2 components, it's traditionally been ugly.  There
were a *lot* of university computing centers and comp-sci departments that were
quite surprised when all the addresses of the form [email-masked]' or
[email-masked]' were no longer recognized as a shorthand for
'server.cs.foo.edu' or 'server.cc.bar.edu'.  And some of us were around for
when British schools leaked reverse-order domain names, and [email-masked]'
went to another country rather than to U of Foo's CS dept...)

--==_Exmh_1145688162_14141P
Content-Type: application/pgp-signature

--==_Exmh_1145688162_14141P--

From: Yuri Inglikov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 21 Apr 2006 21:44:03 -0700
Subject: domain name definition in RFC2821
Sender: [email-masked]

--_000_591819DA872DBE4C9BDE53E46EAB479E01365446dffoxhoundmsgex_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There appears to be some disconnect between ABNF syntax and a prose. I.e. i=
t appears that ABNF requires at least 2 sub-domain parts, while prose discu=
sses "one or more dot-separated components". Which one is "more correct" an=
d any scenario when a single-component domain name can be valid / useful in=
 modern SMTP?

Thanks,
Yuri Inglikov

RFC2821:

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

It appears that BNF syntax in RFC2821 requires at least 2 sub-domain parts.=
 On the other hand the prose in the same RFC2821 discusses "one or more" do=
t-separated parts:

2.3.5 Domain

   A domain (or domain name) consists of one or more dot-separated
   components.  These components ("labels" in DNS terminology [22]) are
   restricted for SMTP purposes to consist of a sequence of letters,
   digits, and hyphens drawn from the ASCII character set [1].  Domain
   names are used as names of hosts and of other entities in the domain
   name hierarchy.  For example, a domain may refer to an alias (label
   of a CNAME RR) or the label of Mail eXchanger records to be used to
   deliver mail instead of representing a host name.  See [22] and
   section 5 of this specification.

All other RFC's I checked appear to allow single-component domain names.

--_000_591819DA872DBE4C9BDE53E46EAB479E01365446dffoxhoundmsgex_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>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, wh=
ile
prose discusses &#8220;one or more dot-separated components&#8221;. Which o=
ne
is &#8220;more correct&#8221; and any scenario when a single-component doma=
in
name can be valid / useful in modern SMTP?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Yuri Inglikov<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold'>RF=
C2821:<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
Domain =3D (sub-domain 1*(&quot;.&quot; sub-domain)) / address-literal<o:p>=
</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
sub-domain =3D Let-dig [Ldh-str]<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D2 color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-style:italic'>I=
t
appears that BNF syntax in RFC2821 requires at least 2 sub-domain parts. On=
 the
other hand the prose in the same RFC2821 discusses &#8220;one or more&#8221=
;
dot-separated parts:<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>2.3.5 Domain<o:p=
></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'><o:p>&nbsp;</o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; A d=
omain
(or domain name) consists of <b><span style=3D'font-weight:bold'>one</span>=
</b> <b><span
style=3D'font-weight:bold'>or more</span></b> dot-separated<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp;
components.&nbsp; These components (&quot;labels&quot; in DNS terminology [=
22])
are<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp;
restricted for SMTP purposes to consist of a sequence of letters,<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; dig=
its,
and hyphens drawn from the ASCII character set [1].&nbsp; Domain<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; nam=
es are
used as names of hosts and of other entities in the domain<o:p></o:p></span=
></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; nam=
e
hierarchy.&nbsp; For example, a domain may refer to an alias (label<o:p></o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; of =
a
CNAME RR) or the label of Mail eXchanger records to be used to<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; del=
iver
mail instead of representing a host name.&nbsp; See [22] and<o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#993300" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#993300'>&nbsp;&nbsp; sec=
tion 5
of this specification.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>All other RFC&#8217;s I checked appear to allow single-c=
omponent
domain names.<o:p></o:p></span></font></p>

</div>

</body>

</html>

--_000_591819DA872DBE4C9BDE53E46EAB479E01365446dffoxhoundmsgex_--