P85025%BARILAN.BITNET@WISCVM.ARPA (Doron Shikmoni) (10/30/85)
The following is a note I've received from the Postmaster at
Columbia University, in reply to a former discussion. The issue with
relevance to this list, is my pointing (started as a query to the
UCB gateway staff) that Columbia's CCnet nodes (CU20A-CU20B-CU20C-CU20D
and many others) have started to generate "From:" lines like:
"user@CU20A.COLUMBIA.EDU".
The former format was:
"user@CU20A" (that's on Bitnet; internet addressing obvious).
Another piece of fact is that a Bitnet Mailer, wishing to send
Mail to any of these hosts, has to send it to MAILER@CUVMA which is
the CCnet gateway (regardless to the new "problem").
And (most important): "CU20A.COLUMBIA.EDU" is NOT an Internet host.
Neither is it registered in the NIC, Nor is there a domain server for
any of those levels which can point to a direction. The only "real"
internet (registered) host is CU20B.
The principal issue I would like to raise: would this forum agree
that using an internet-like (...) addresses can be seen as only a way
of indicating the "administrative domain" in which a host resides ?
Should we continue to fill up our Mailers with host-specific hacks
like the one suggested ? (Note: the suggested solution is having
a table with all "CU20x.COLUMBIA.EDU"s that will change them into
CU20x only; THEN, go over a table (same ? another ?) to make sure
mail to CU20x goes actually to MAILER@CUVMA --> the gateway).
Aren't we striving towards SIMPLER, domain-driven mailing systems?
Doron
---------------------------- Text of forwarded message -----------------------
Received: (from MAILER@CUVMA for P85025@BARILAN via NJE)
(RSCS6294-6294; 47 LINES); Wed, 30 Oct 85 09:15:42 IST
Received: from CCNET(MAILER) by CUVMA (Mailer X1.21) id 6293;
Wed, 30 Oct 85 02:15:03 EST
Date: Wed 30 Oct 85 02:15:26-EST
From: Ken Rossman <sy.Ken@CU20B>
Subject: Re: Mail bounced from UCB.
To: P85025, netinfo@UCBJADE
cc: P85026, sy.Ken@CU20B
In-Reply-To: Message from "Doron Shikmoni <P85025@BARILAN>" of Wed 30 Oct 85 01:
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <12155172261.17.SY.KEN@CU20B.COLUMBIA.EDU>
While CU20A is not "on BITnet", neither is it on the Internet. It is on
something we call CCnet, though it also does happen to talk TCP/IP, and is
on a local net which is connected to an Internet (ARPAnet) gateway.
Whether it's entirely our problem is a point of debate, I think. Just
because we have started using domain style names does not automatically
mean we should be considered an Internet host, or for that matter a BITnet
host, or CCnet host, or any-net host in particular. The idea behind the
domain naming scheme (or at least perhaps one of the ideas) was to allow
hosts to be given names which gave a fairly clear indication of what
"administrative domain" the machine belonged to. We think that in general
it is a good idea to go with this scheme (particularly since Internet is
switching over to this naming scheme, and someday, all of our 20's, not
just CU20B, may become official Internet hosts).
In any case, CMU hosts have been using this format for some time now. How
do you deal with those hosts (e.g. TE.CC.CMU.EDU)? I would suggest that if
you have any type of host alias lookup table, that the CU20x.COLUMBIA.EDU
machine be entered in the table, and that the official BITnet host name for
these hosts be returned as CU20x (CU20A, CU20B, CU20C, CU20D). The mail
should go back through the (stupid, losing, bogus) HASP mail gateway here
if addressed using the shorter names.
If I can do anything here that will help fix things more (short of changing
our host names back to the short forms), please let me know.
By the way, as for truncated lines (particularly header lines), the
(stupid, losing, bogus) HASP mail gateway currently in use here knows how
to wrap lines around so instead of being truncated, they are wrapped and
indented (though not neatly on a word boundary -- sorry), for outbound mail
anyway. Inbound, I don't know what happens.
Ken Rossman, Postmaster
Columbia Computer Center
-------Rudy.Nedved@cmu-cs-a.ARPA (10/30/85)
Some significant points: 1) Yep, domain names are administrative and have nothing to do with networking. A name like CU20A.COLUMBAI.EDU does NOT mean it is on the ARPA Internet. 2) The BITNET RSCS mail files are nice but they are glorified fancy host tables. In the long run, some type of general gateway hack will have to be added or better yet an distributed database mechanism will be added since BITNET+Internet+UUCP+CSNET+MAILNET+etc. will be too much to keep updating and storing on every single BITNET site. 4) There is a domain transition going on so things are going to be rocky for a while. Some domains do not have sites listed in the old table, domain servers are inconsitent, confused and unreliable. Resolvers evaluate a name wrong and so forth. The problem with CU20A at the moment is that given you can not access it from the ARPA Internet, it should have an MF record for some host that will accept mail for CU20A. Also CCNet which is based on DECNet should probably have a CLASS of DN (DecNet) or something. Things are fuzzy. Hopefully when CHAOSNet and CSNET gets into the domain system, CCNet and BITNET will follow... -Rudy
Vshank%Weizmann.BITNET@WISCVM.ARPA (Henry Nussbacher) (10/31/85)
> 2) The BITNET RSCS mail files are nice but they are glorified fancy > host tables. In the long run, some type of general gateway hack > will have to be added or better yet an distributed database > mechanism will be added since BITNET+Internet+UUCP+CSNET+MAILNET+etc. > will be too much to keep updating and storing on every single > BITNET site. VM sites that run with a mailer do *not* keep all network tables. They keep the Bitnet tables and when sending to a site the mailer scans the address following the last '.' for a domain name like: ARPA, EDU, GOV, MAILNET, etc. Bitnet sites need to keep a list of all CCnet sites since the gateway did not accept an upper level domain like: user@cwr20b.CCNET Now with CCnet accepting upper level domains, the mailer will need to scan backwards to a second level '.' to see if the mail shouldn't be routed to the normal '.EDU' gateway (currently UCBJADE - soon to become WISCVM) but rather to the CUVMA CCNET gateway. Henry Nussbacher