[comp.mail.misc] PLEASE NOTE: CS is an official top level domain now!!!

piet@NIC.EU.net (Piet Beertema) (12/19/90)

All mail/systems managers please take note that CS is
now an official top level domain. I've already seen
several mails pass by on mcsun.EU.net, which is where
the MX records for .cs point to. All those mails are
doomed to fail, since they weren't really meant for a
host in Czecho-Slovakia, but for an internal host and
resulted from the use of abbreviated addressing of the
form user@host.cs within a domain like cs.foo.bar.
Note that according to RFC822 par. 6.2.2, abbreviated
addressing is bound to restrictions. Hosts that allow
abbreviated addresses that end on a domain name that
is - or may sooner or later be - a top level domain
violate these restrictions. Officially only 2-letter
codes that are listed in ISO-3166 can become top level
domains, but given political reality ISO-3166 won't
last forever and it's safer to *never* use a 2-letter
code for a subdomain.


-- 
	Piet Beertema, EUnet-NIC, Amsterdam   (hostmaster@NIC.EU.net)

brendan@cs.widener.edu (Brendan Kehoe) (12/19/90)

In <2058@mcsun.eu.net>, piet@NIC.EU.net writes:
>All mail/systems managers please take note that CS is now an official
>top level domain.  ... and it's safer to *never* use a 2-letter code
>for a subdomain.

 I may be in a minority here, but don't you think this is going to
really wreak havoc? Irregardless that my subdomain is cs (what else
would it be? compsci.widener.edu?), the number of sites that have this
as a subdomain (or other two-letter combinations) is pretty vast. Why
wasn't the top-level domain named .CZ? Something tells me this will
really make life exciting. At least for me.

>	Piet Beertema, EUnet-NIC, Amsterdam   (hostmaster@NIC.EU.net)


-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu

 Get ``Red Hot & Blue'', songs by Cole Porter sung by U2, Sinead O'Connor,
The Neville Brothers, Tom Waits, & many more. Proceeds benefit AIDS research.

jbaltz@cunixf.cc.columbia.edu (Jerry B. Altzman) (12/21/90)

In article <1990Dec19.145937.3094@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes:

> I may be in a minority here, but don't you think this is going to
>really wreak havoc? Irregardless that my subdomain is cs (what else
>would it be? compsci.widener.edu?), 

So, don't send mail to user@host.cs, but now user@host.cs.widener.edu, or
just make 'host' unique under cs.

>                                     the number of sites that have this
>as a subdomain (or other two-letter combinations) is pretty vast. Why
>wasn't the top-level domain named .CZ? Something tells me this will
>really make life exciting. At least for me.

Given that CS is the ISO country code for Czecholslovakia (I believe) it
really is appropriate.

>     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu

DISCLAIMER: This isn't Columbia. This is me. Columbia is them.

//jbaltz
--
jerry b. altzman  "I didn't do it, and when I did I wasn't"      212 854 8058
jbaltz@columbia.edu   "there, and you deserved it."      jauus@cuvmb (bitnet)
NEVIS::jbaltz (HEPNET)                    ...!rutgers!columbia!jbaltz (bang!)

rickert@mp.cs.niu.edu (Neil Rickert) (12/21/90)

In article <1990Dec20.212439.4507@cunixf.cc.columbia.edu> jbaltz@cunixf.cc.columbia.edu (Jerry B. Altzman) writes:
>In article <1990Dec19.145937.3094@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes:
>
>> I may be in a minority here, but don't you think this is going to
>>really wreak havoc? Irregardless that my subdomain is cs (what else
>>would it be? compsci.widener.edu?), 
>
>So, don't send mail to user@host.cs, but now user@host.cs.widener.edu, or
>just make 'host' unique under cs.
>
 I think the problem is the reverse of what has been stated.  With most
mail setups, mail addressed to 'host.cs' where 'host.cs.widener.edu' will
not go to Czechoslovakia by mistake.  Rather, mail intended for 'host.cs'
in Czechoslovakia will go to 'host.cs.widener.edu' by mistake.  This is
because of the design of many mail system to attempt to qualify in the
local domain first.

 The only reliable approach is to qualify in the local domain only if the
domain name is completely unqualified (no periods).  Otherwise treat the
name as already fully qualified.  In other words, don't use RES_DNSRCH
in domain lookups.

 Note that this is primarily a mail problem.  Spurious qualification is not
much of a problem with telnet/ftp/rlogin etc, because the connections are
interactive, and there are ways of correcting the problem.  But with
email the connection occurs in the background where you don't see the
problems until it is too late.


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

ckd@cs.bu.edu (Christopher Davis) (12/21/90)

Neil> rickert@mp.cs.niu.edu (Neil Rickert) writes:

Neil>  The only reliable approach is to qualify in the local domain only if the
Neil> domain name is completely unqualified (no periods).  Otherwise treat the
Neil> name as already fully qualified.  In other words, don't use RES_DNSRCH
Neil> in domain lookups.

Assuming that your mailer is broken in this manner, you can always
"anchor" the root domain in such a way as to keep it from completing to
the local domain.

(For example, one of the local machines is named "bu.edu"; this
sometimes tries to resolve to "bu.edu.bu.edu" instead.  I just use
"bu.edu." (note the extra period to anchor the root)--and all is well.

So mail to user@foo.cs. if you really have to.

--Chris
--
   [ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
    A message destined for delivery in *your* domain is fair game for
  anything you may want to do, up to and including translating the entire
 message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)

rickert@mp.cs.niu.edu (Neil Rickert) (12/21/90)

In article <CKD.90Dec20220406@bucsd.bu.edu> ckd@cs.bu.edu (Christopher Davis) writes:
>Neil> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>
>Neil>  The only reliable approach is to qualify in the local domain only if the
>Neil> domain name is completely unqualified (no periods).  Otherwise treat the
>Neil> name as already fully qualified.  In other words, don't use RES_DNSRCH
>Neil> in domain lookups.
>
>Assuming that your mailer is broken in this manner, you can always
>"anchor" the root domain in such a way as to keep it from completing to
>the local domain.
>
>(For example, one of the local machines is named "bu.edu"; this
>sometimes tries to resolve to "bu.edu.bu.edu" instead.  I just use
>"bu.edu." (note the extra period to anchor the root)--and all is well.
>

Please note the following excerpt from RFC1123, which specifically complains
about adding a trailing period as an error.

 Moreover it is not reliable, as it may seriously intefere with address
parsing, depending on the exact algorithms used.

      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1

         Errors in formatting or parsing 822 addresses are unfortunately
         common.  This section mentions only the most common errors.  A
         User Agent MUST accept all valid RFC-822 address formats, and
         MUST NOT generate illegal address syntax.

.....

         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.


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940