chris@umcp-cs.UUCP (11/13/83)
here is a problem that you may run into if you start optimizing
UUCP addresses. Here's a real-life example:
Mail from here to "seismo!inhp4!sun!gnu" will go to John Gilmore
(assuming he's still at Sun). Now, we talk directly to "sun", but
mail to "sun!gnu" will say that "gnu" isn't a user of (our) Sun*!
Admittedly "sun" is a poor name for our Sun, but we haven't changed
it (yet), and even after we do change it, I'll bet there are at
least a few sites out there with the same name (some not necessarily
on Usenet) (and by "same name" I don't mean necessarily "sun", I
mean "xyzzy" and "xyzzy" or "alpo" and "alpo" or some such).
In other words, unless you *know* that "foo!bar" is the same as
"foo!baz!bar", you *cannot* send mail to "foo!bar" -- the two "bar"s
may be entirely different machines.
A central database of UUCP paths will help, since all machines
registered therein will be required to have unique names; those
paths can then be optimized. For now, I suppose that optimizing
all known Usenet machines will have to do. (And we'd better change
the name of our Sun!)
* Sun is a trademark of Sun Microsystems Inc.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relayekb@machaids.UUCP (Eric Bustad) (11/14/83)
-- I thought EVERYONE picked a unique name for their machine's name? It really doesn't seem reasonable to use a name someone has already chosen. And where is a new system adminsitrator to go to find out what names are in use?? -- = Eric Bustad (BTL-HO) ihnp4!machaids!ekb
smb@ulysses.UUCP (11/14/83)
We've already had problems with some uucp names. There are two different iuvax systems, one at Indiana and one at SRI. Several different sites have suggested using the Seven Dwarves for machine names, not knowing that UNC-Chapel Hill is using them. 'Shasta' has an upper-case letter in its name, which many hosts can't handle. Etc.
laura@utcsstat.UUCP (Laura Creighton) (11/15/83)
Here is another problem which I have run into. I think that site foo talks to site bar, but I am wrong. I mail to decvax!foo!bar!somebody. This should bomb out. But decvax optimises its paths (thanks decvax) and decvax talks to site bar, so the mail gets sent to decvax!bar!somebody which works just great. Then somebody tries to send mail back to me. He tries foo!decvax!utcsstat!laura.Boom. It fails, because his site does not know anything about foo. Unless he knows that my mail only got to him courtesy of decvax magic, he may be at a loss to find out how to get to me. The problem is worse if he is mailing to: whiffle!griffle!mumble!umble!decvax!utcsstat!laura, because the magic updating could have taken place at any of those sites. Laura Creighton utcsstat!laura
dw@rocksvax.UUCP (Don Wegeng) (11/15/83)
"Where is a new site suppose to get the list of currently used uucp site names?" Well, I would hope that whatever site gives them a connection to the net would make sure that their name was not already in use. I can't imagion an auto-routing scheme which does NOT require that site names be unique. By auto-routing, I refer to a system which will allow me to send mail to a site several hops away without having to specify the exact path that the message travels. Maybe I'm narrow minded, but I don't see how we can ever adopt any form of internet addressing without having the mailer make the assumption that site names are unique. I'm not aware that this is a problem at present, at least with UUCP sites which are on Usenet. Don Wegeng rochester!rocksvax!dw Wegeng.Henr@Parc-Maxc.ARPA
jreuter@cincy.UUCP (Jim Reuter) (11/16/83)
Everyone SHOULD have a unique uucp name, but I can think of at least one example where this might not have happened. I was using a Plexus machine just after they came out, and it was running v7. In v7 the system name is compiled into all the programs and since we had only binaries, either an expert (me) could patch in a new name with adb or just use whatever name Plexus shipped in the binaries (I think the name was 'plexus'). A naive user trying to bring up a net connection (if this is even possible) may have missed this! Fortunately, they now run system III with some fancy auto-configure stuff that lets you specify a system name and the uname() system call digs it up. Also, how likely is it that a new site may choose a name that already exist by chance. There are a lot of sites out there, and my lists are never completely up to date, so... Has anyone ever done this? Jim Reuter (decvax!cincy!jreuter)
sanders@menlo70.UUCP (Rex Sanders) (11/17/83)
The following is the most ridiculous uucp/mail address I've seen
in a long time - and the audit trail shows that the message went through
all these sites. I would like to see some form of mail routing
optimiser on all these machines.
> To: sdcsvax!decvax!ucbvax!menlo70!sri-unix!hplabs!hao!menlo70!sanders,
-- Rex ucbvax!menlo70!sanderssmh@mit-eddie.UUCP (Steven M. Haflich) (11/17/83)
Indeed, name conflicts have already happened -- sort of. The machine from which this reply originates is "mit-eddie" and belongs to a suite of machines named after characters [sic?] in A Hithchhiker's Guide to the Galaxy. A machine at the University of Washington is called "uw-eddie" and belongs to a suite of machines named after characters in Leave it to Beaver. The problem does not occur with uucp, but both machines are on local networks (Ethernet) and also directly or indirectly accessable from the Arpanet. Unlike uucp, these other networks support host-name aliases, in this case, "eddie". The net result is that from different locations in this non-Cartesian universe, the unqualified name "eddie" can get you to very different places. Another example: Independently, in the exact same week, a site at Berkeley and a site at MIT both decided to name suites of machines after composers, and both have a "bach": mit-bach and ucbbach. The same problem exists for abbreviated names... The probability of naming conflicts can be reduced if sites would try to keep their organization name apparent in host names. Problems will still occur, however, if local abbreviations can be "seen" from outside. Steve Haflich, MIT Experimental Music Studio
rcj@burl.UUCP (R. Curtis Jackson) (11/17/83)
True, Laura -- but if decvax optimizes your path, why would somebody receiving your mail ever see anything about foo? Thus, your original mail is going to: floyd!burl!clyde!ihnp4!allegra!rlgvax!guy floyd mails this on to burl, but burl's mail optimizer sends this out: ihnp4!rlgvax!guy Why should guy try to reply To: allegra!ihnp4!clyde!burl!floyd!utcsstat!laura when the mail that he received was: From: ihnp4!burl!floyd!utcsstat!laura ? A bit confused on this one, -- The MAD Programmer -- 919-228-3814 (Cornet 291) alias: Curtis Jackson ...![ floyd clyde ihnp4 mhuxv ]!burl!rcj
fair@dual.UUCP (Erik E. Fair) (11/18/83)
Well, you can always consult the USENET compact directory, published
monthly in net.news.map
Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair
Dual Systems Corporation, Berkeley, Californiatjt@kobold.UUCP (T.J.Teixeira) (11/18/83)
I think this problem only arises if you have a mailer that inserts an
Arpa-style From: line in addition to the From lines generated by uucp
mail. MH does this as does (I think) the Berkeley Mail command. In
this case the letter will get received with a uucp from line that
reflects the actual path the letter took (like a chain of
Received-From: lines) (i.e. From ihnp4!burl!floyd!utcsstat!laura) while
the From: line may have allegra!ihnp4!clyde!burl!floyd!utcsstat!laura.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200laura@utcsstat.UUCP (Laura Creighton) (11/19/83)
Curtis (and everyone else that is sending mail) the reason that the problem exists is that not everybody has the same mailer. More explicitly -- NOT EVERYONE HAS SENDMAIL. And it is at the discretion of the mailer that is rading the mail to decide where it came from. Some mailers do not understand that it has been optimised, and go for the old version. Other mailers believe explicity any line beginning "From:" or "FROM:" -- not good because other mailers generate thngs like "FROM: the tty of Geoffrey S. Goodfellow" and stuff them into the mail header. It makes it hard to get from here to there! There are also at least 5 sites out there which I have tracked down who are optimising badly. they optimise: good_site!still_good!THEM!useless!more_useless!real_destination!user into a From line that reads: THEM!good_site!still_good!sender Notice that good_site and still_good, which should have been reversed, aren't. This is not cool when THEM doe snot talk to good_site. I have sent mail to the administrators involved. laura creighton (see what you discover when people send you hate mail?) utzoo!utcsstat!laura
cunningh@noscvax.UUCP (11/19/83)
An extension of the idea of having tables in the ARPANET bridges would
be to have path tables, and appropriate software to generate the full
uucp address within the uucp (actually usenet) 'backbone' sites.
>From the point of view of someone not at a backbone site, he or she
would then only have to address messages as follows:
<path to a backbone site>!<a backbone>!<final site>!<user>
It would then be up to the backbone site to determine a (hopefully
reasonably optimized) route to the final site, fill in that portion
of the address, and then forward.
This would require some reliable software, and routing tables within
(only) the backbone sites. It might put too much of an extra
computational burdon on the backbone sites, also.
At non-backbone sites, I presume that 'preferred' backbone sites would
be normally used. A backbone site handling too much traffic could
complain to sending sites, and suggest an alternative backgone site to
route to. This is similar, but certainly more informal, than the way
ARPANET 'internet gateways' work.
Unfortunately, if it becoms more convenient to routinely route all
non-local uucp through backbone sites, those sites will certainly
experience an increase in traffic. But, hopefully, there will be a
measureable decrease in error messages.
--
Bob Cunningham ..sdcsvax!noscvax!cunningh
21 17' 35" N 157 49' 38" W MILNET: cunningh@nosc-ccdave@utcsrgv.UUCP (Dave Sherman) (11/20/83)
One thing which you can probably count on when optimizing paths:
the only paths which are a problem are ones which result from people
typing 'r' to readnews and trying to mail back a news path. *Nobody*
is going to type in 20-site paths by hand - they'll find something
shorter.
It follows that if routing software can refer to the official
news configuration database in some sensible way, it can optimize
correctly. (Don't ask me for details; I don't know any. But surely it's
an idea which can be worked on.)
Dave Sherman
--
{allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!davephil@amd70.UUCP (Phil Ngai) (11/20/83)
I thought EVERYONE picked a unique name for their machine's name?
It really doesn't seem reasonable to use a name someone has already
chosen.
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!philwls@astrovax.UUCP (11/22/83)
I was about to post this anyway but it is convenient to be able to post
it as a followup to something.
I have made some modifications to readnews and vnews at our site to use a
routing data base rather than the news arrival path to constuct a path
for the r(eply) command. The diffs to the files readr.c, visual.c, and
Makefile which are needed to implement this change follow this introduction.
As implemented here, this requires the dbm (data base management) subroutines
and a pairs of files /usr/lib/uucp/alpath.dir and /usr/lib/uucp/alpath.pag ,
such as that constructed by these dbm routines. The format of the data
stored in these files is: using the name of a site as a key, stored under
the key is a string of the form site1!site2!...!keysite!%s , where the %s
could be replaced by an account name located at that site. Another possible
string is site1!site2!...!siten!%s@keysite. The dbm pair of files of this
form is output by the version of pathalias that we have.
In use, these patches look along the arrival path and substitute a
replacement path for the first site that they find in the data base. Thus
a new site that has not yet made it into the data base will be handled
properly. The original arrival path is still placed in the mail header for
reference in a line headed by "News-path: " (sorry Mark, I wasn't able to
check if this is a legal thing to do Arpa-wise. It can be changed to some
other name if it matters). The "To: " line can still be edited if one
notices some obvious goof, i.e. some hop which one knows is bad. (Suggestion:
if this occurs, tell your site manager so he can update the data base. If
you are site manager, update your data base.)
Hopefully, this change can reduce a lot of silly paths. Even though I was
aware of the need to edit my paths I would sometimes forget and let loose a
reply bouncing all over the net.
Note: there are many bug fixes and such in the "original" versions of
the files "diff" below. Therefore the "original" line numbers have only
vaguely the values they might have in your own versions of these files.
indicative. If it is desired to place the routing information is some other
location than /usr/lib/uucp/alpath* , redefine the variable NETPATHS in the
Makefile (sorry, I gave up on localize.sh a fair while ago).
--
Bill Sebok Princeton Univ. Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton}!astrovax!wls
------------------------------------------------------------------------
Diff for readr.c
*** readr.c.BAK Mon Nov 14 16:39:04 1983
--- readr.c Mon Nov 14 22:04:47 1983
***************
*** 5,12
static char *SccsId = "@(#)readr.c 2.26 6/24/83";
#include "rparams.h"
#define FAST
static char lbuf[BUFLEN*2];
#define saveart oobit = bit;strcpy(ofilename1, filename);strcpy(ogroupdir, groupdir);hbufcp(&hbuf1, &h);ongsize = pngsize
--- 5,15 -----
static char *SccsId = "@(#)readr.c 2.26 6/24/83";
#include "rparams.h"
#define FAST
+ #ifdef NETPATHS
+ #include <dbm.h>
+ #endif NETPATHS
static char lbuf[BUFLEN*2];
#define saveart oobit = bit;strcpy(ofilename1, filename);strcpy(ogroupdir, groupdir);hbufcp(&hbuf1, &h);ongsize = pngsize
***************
*** 613,620
char *replyname();
char subj[100];
char folbuf[BUFLEN];
extern char MAILPARSER[];
hptr = &h;
while (*bptr && index("d-", *bptr)) {
switch (*bptr) {
--- 616,632 -----
char *replyname();
char subj[100];
char folbuf[BUFLEN];
extern char MAILPARSER[];
+ #ifdef NETPATHS
+ /* Stuff for finding path in data base */
+ static int dbmopen = 0;
+ static char newspaths[] = NETPATHS;
+ datum key, result;
+ register char *p1, *p2;
+ char sitename[100];
+ /* End Stuff for finding path in data base */
+ #endif NETPATHS
hptr = &h;
while (*bptr && index("d-", *bptr)) {
switch (*bptr) {
***************
*** 641,649
}
*rcbuf = '\0';
*curberk = '\0';
! pathptr = replyname(hptr);;
ptr = pathptr - 1;
i = 0;
for (ptr1 = address, ptr2 = pathptr; *ptr2; ptr1++, ptr2++) {
if (index("\"\\$", *ptr2))
--- 653,688 -----
}
*rcbuf = '\0';
*curberk = '\0';
! pathptr = replyname(hptr);
! #ifdef NETPATHS
! /* Use data Base to Find a reply a Path to a site */
! /* Nov 13, 1983 W. Sebok */
! if (dbmopen==0)
! dbmopen = (dbminit(newspaths)==0) ? 1 : -1 ;
!
! result.dptr = NULL;
! if (dbmopen>0) {
! for(p1=pathptr; (p2 = index(p1,'!'))!=NULL; p1=p2+1);
! if (pathptr!=p1) {
! key.dptr = sitename;
! p1--;
! do {
! for (p2=p1; (p1!=pathptr) && (*--p1!='!'); );
! key.dsize = p2 - p1 ;
! strncpy(sitename, p1+1, key.dsize);
! sitename[key.dsize-1] = '\0';
! result = fetch(key);
! } while ( (p1!=pathptr) && result.dptr==NULL);
! }
! }
! if (result.dptr != NULL) {
! sprintf(sitename, result.dptr, p2+1);
! p1 = pathptr;
! pathptr = sitename;
! }
! #endif NETPATHS
ptr = pathptr - 1;
i = 0;
for (ptr1 = address, ptr2 = pathptr; *ptr2; ptr1++, ptr2++) {
if (index("\"\\$", *ptr2))
***************
*** 687,694
tfp = fopen(tf, "w");
fprintf(tfp, "To: %s\n", pathptr);
fprintf(tfp, "Subject: %s\n", subj);
fprintf(tfp, "References: %s\n\n", folbuf);
fclose(tfp);
sprintf(edcmdbuf, "%s %s", ed, tf);
--- 726,737 -----
tfp = fopen(tf, "w");
fprintf(tfp, "To: %s\n", pathptr);
fprintf(tfp, "Subject: %s\n", subj);
+ #ifdef NETPATHS
+ if (result.dptr != NULL)
+ fprintf(tfp, "News-path: %s\n", p1);
+ #endif NETPATHS
fprintf(tfp, "References: %s\n\n", folbuf);
fclose(tfp);
sprintf(edcmdbuf, "%s %s", ed, tf);
------------------------------------------------------------
Diffs for visual.c of vnews
*** visual.c.BAK Sun Nov 13 22:43:46 1983
--- visual.c Mon Nov 14 22:05:38 1983
***************
*** 49,56
#include "dir.h"
#ifdef MYDB
#include "db.h"
#endif
#define ARTWLEN (ROWS-2)/* number of lines used to display article */
#ifdef STATTOP
--- 49,59 -----
#include "dir.h"
#ifdef MYDB
#include "db.h"
#endif
+ #ifdef NETPATHS
+ #include <dbm.h> /* WLS Nov 13,1983 */
+ #endif NETPATHS
#define ARTWLEN (ROWS-2)/* number of lines used to display article */
#ifdef STATTOP
***************
*** 866,873
char subj[132];
char *p;
char *replyname();
strcpy(tf, tft);
mktemp(tf);
if ((tfp = fopen(tf, "w")) == NULL) {
msg("Can't create %s", tf) ;
--- 869,886 -----
char subj[132];
char *p;
char *replyname();
+ #ifdef NETPATHS
+ /* Stuff for finding path in data base */
+ static int dbmopen = 0;
+ static char newspaths[] = NETPATHS;
+ datum key, result;
+ register char *p1, *p2;
+ char sitename[100];
+ /* End Stuff for finding path in data base */
+ #endif NETPATHS
+
strcpy(tf, tft);
mktemp(tf);
if ((tfp = fopen(tf, "w")) == NULL) {
msg("Can't create %s", tf) ;
***************
*** 894,905
p = h.sender;
else
#endif
p = replyname(&h);
! fprintf(tfp, "To: %s\n", p);
! fprintf(tfp, "Subject: %s\n", subj);
! if (followup != 2)
! fprintf(tfp, "In-reply-to: your article %s\n", h.ident);
arg[1] = REPLYPROG;
arg[4] = p;
} else {
p = h.nbuf;
--- 907,954 -----
p = h.sender;
else
#endif
p = replyname(&h);
!
! #ifdef NETPATHS
! /* Use data Base to Find a reply a Path to a site */
! /* Nov 13, 1983 W. Sebok */
! if (dbmopen==0)
! dbmopen = (dbminit(newspaths)==0) ? 1 : -1 ;
!
! result.dptr = NULL;
! if (dbmopen>0) {
! for(p1=p; (p2 = index(p1,'!'))!=NULL; p1=p2+1);
! if (p!=p1) {
! key.dptr = sitename;
! p1--;
! do {
! for (p2=p1; (p1!=p) && (*--p1!='!'); );
! key.dsize = p2 - p1 ;
! strncpy(sitename, p1+1, key.dsize);
! sitename[key.dsize-1] = '\0';
! result = fetch(key);
! } while ( (p1!=p) && result.dptr==NULL);
! }
! }
! if (result.dptr != NULL) {
! fprintf(tfp, "To: ");
! fprintf(tfp, result.dptr, p2+1);
! fprintf(tfp, "\nSubject: %s\n", subj);
! if (followup != 2)
! fprintf(tfp, "In-reply-to: your article %s\n",
! h.ident);
! fprintf(tfp, "News-path: %s\n", p);
! } else
! #endif NETPATHS
! {
! fprintf(tfp, "To: %s\n", p);
! fprintf(tfp, "Subject: %s\n", subj);
! if (followup != 2)
! fprintf(tfp, "In-reply-to: your article %s\n",
! h.ident);
! }
! /* End Stuff for finding path in data base */
arg[1] = REPLYPROG;
arg[4] = p;
} else {
p = h.nbuf;
----------------------------------------------
diff for Makefile
*** Makefile.BAK Mon Nov 21 23:48:59 1983
--- Makefile Mon Nov 14 22:30:08 1983
***************
*** 3,10
# definitions
SPOOLDIR = /usr/spool/news
LIBDIR = /usr/lib/news
BINDIR = /usr/bin
DEBUG = # -DDEBUG # -pg
CFLAGS = ${DEBUG} -O -DDBM
LFLAGS = # -pg
NEWSUSR = news
--- 3,11 -----
# definitions
SPOOLDIR = /usr/spool/news
LIBDIR = /usr/lib/news
BINDIR = /usr/bin
+ NETPATHS = /usr/lib/uucp/alpath
DEBUG = # -DDEBUG # -pg
CFLAGS = ${DEBUG} -O -DDBM
LFLAGS = # -pg
NEWSUSR = news
***************
*** 70,78
inews: Makefile $(IOBJECTS)
$(CC) $(LFLAGS) $(IOBJECTS) -o inews -ldbm
readnews: Makefile $(ROBJECTS)
! $(CC) $(LFLAGS) $(ROBJECTS) -o readnews
funcs.o: funcs.c params.h defs.h
$(CC) $(CFLAGS) -c funcs.c
--- 71,79 -----
inews: Makefile $(IOBJECTS)
$(CC) $(LFLAGS) $(IOBJECTS) -o inews -ldbm
readnews: Makefile $(ROBJECTS)
! $(CC) $(LFLAGS) $(ROBJECTS) -o readnews -ldbm
funcs.o: funcs.c params.h defs.h
$(CC) $(CFLAGS) -c funcs.c
***************
*** 107,115
$(CC) $(CFLAGS) -DSPOOLDIR=\"$(SPOOLDIR) -DLIBDIR=\"$(LIBDIR)\
-DNEWSUSR=\"$(NEWSUSR)\" -DNEWSGRP=\"$(NEWSGRP)\" -c rextern.c
readr.o: readr.c rparams.h defs.h params.h Makefile
! $(CC) $(CFLAGS) -c readr.c
checknews.o: checknews.c defs.h Makefile
$(CC) $(CFLAGS) -DSPOOLDIR=\"$(SPOOLDIR) -DLIBDIR=\"$(LIBDIR)\
-DNEWSUSR=\"$(NEWSUSR)\" -DNEWSGRP=\"$(NEWSGRP)\" -c checknews.c
--- 108,116 -----
$(CC) $(CFLAGS) -DSPOOLDIR=\"$(SPOOLDIR) -DLIBDIR=\"$(LIBDIR)\
-DNEWSUSR=\"$(NEWSUSR)\" -DNEWSGRP=\"$(NEWSGRP)\" -c rextern.c
readr.o: readr.c rparams.h defs.h params.h Makefile
! $(CC) $(CFLAGS) -DNETPATHS=\"$(NETPATHS)\" -c readr.c
checknews.o: checknews.c defs.h Makefile
$(CC) $(CFLAGS) -DSPOOLDIR=\"$(SPOOLDIR) -DLIBDIR=\"$(LIBDIR)\
-DNEWSUSR=\"$(NEWSUSR)\" -DNEWSGRP=\"$(NEWSGRP)\" -c checknews.c
***************
*** 201,206
# Vnews section of makefile
VOBJECTS = readnews.o rfuncs.o rfuncs2.o rextern.o process.o rpathinit.o $(OBJECTS) visual.o virtterm.o dir.o
vnews: $(VOBJECTS)
! $(CC) $(LFLAGS) $(VOBJECTS) -ltermcap -ljobs -o $@
--- 201,209 -----
# Vnews section of makefile
VOBJECTS = readnews.o rfuncs.o rfuncs2.o rextern.o process.o rpathinit.o $(OBJECTS) visual.o virtterm.o dir.o
+ visual.o: visual.c rparams.h Makefile
+ $(CC) $(CFLAGS) -DNETPATHS=\"$(NETPATHS)\" -c visual.c
+
vnews: $(VOBJECTS)
! $(CC) $(LFLAGS) $(VOBJECTS) -ltermcap -ljobs -ldbm -o $@
***************
--
Bill Sebok Princeton Univ. Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton}!astrovax!wlsajs@hpfcla.UUCP (11/22/83)
#R:menlo70:-18800:hpfcla:17200002:000:936 hpfcla!ajs Nov 15 17:46:00 1983 Considering the general anarchy of nodename selection, the only safe rule is this: Before you pick one, check to make sure someone else hasn't already got it. How do you do that? For starters, you can search the data posted to net.news.map. It's good for over a thousand nodenames. They are easier to see if you run mkpath on the data and look at its output. That way you see "hidden" systems too -- those which only appear as connections in other systems' entries. By the way... There are at least 50 systems in the world, most not yet announced publicly, which belong to HP (Hewlett Packard) and whose nodenames start with "hp". As far as I can tell, we are the only organization using that prefix, and we are consistent in the use of it. Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado ucbvax!hplabs!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"
phil@amd70.UUCP (11/23/83)
Well, Laura, you say everyone doesn't run sendmail, so we can't
talk about using it as a solution.
What's your solution?
And why is it better than getting people to use sendmail?
Phil "I don't run sendmail yet but I will" Ngai
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!philhenryb@microsoft.UUCP (Henry Burgess) (11/24/83)
All this talk, perhaps it is not the addresses but uucp (in all it's glory)
that needs changing. What would be better? Is there a fundimental change
that needs to be made? What is the ideal way to interconnect large
numbers of systems?
Henry Burgess
Microsoft
{decvax, uw-beaver}!microsoft!henrybspaf@gatech.UUCP (11/24/83)
Not every site has access to "mkpath" or copies of the net.news.map
files. Indeed, there are many sites which aren't listed in the news
maps because they don't get news.
I currently have 3 or 4 different databases with routing and site name
information in them. Let me make the following offer: If you are
starting a new site, or if you are asked to offer a contact to a news
site, let me know what the site name is and I will tell you if the name
is currently in any of the databases to which I have access. Note that
I cannot make the claim that the name is unique, because there is
simply no way of determining that fact. However, I will be able to
claim that the name isn't used in any of the major lists currently
circulating about the network. Too bad I can't get copies of ihnp4's
list too....
Also, unless you indicate otherwise, I'll make pass your site name
and such along to Rob Kolstad at parsec for inclusion in his master
database there. I realise that there are some sites whose names
are not to be made public knowledge due to internal security
reasons, so be sure to specify if you fall into that category.
So, send your name and two boxtops to:
--
Off the Wall of Gene Spafford
School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf.GATech @ CSNet-Relay
uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!spaflaura@utcsstat.UUCP (Laura Creighton) (11/25/83)
What we need is an UNAMBIGUOUS STANDARD on how to generate mail adresses. You cannot expect everyone to run sendmail. Would you like to write the TOPS-10 version? The VMS version? The CP/M version? The Apple Dos version? The Ahmdahl UTS version? (We tried to get sendmail up there. It won't.) But machines running these operating systems *already* are hooked into usenet in such a way that they are trying to send me mail. Or is this going to be a unix-only (specifically Berkeley unix no less!) network? If you think so, then you get to get rid of the non-unix sites... I'm not doing that one either. However, I can explain why some people's mail isn't getting there. Laura Creighton utzoo!utcsstat!laura
leff@smu.UUCP (11/26/83)
#R:menlo70:-18800:smu:14000001:000:679
smu!leff Nov 24 17:54:00 1983
Re: Unique Names
It seems the problem of having two bars talked to by different things
is in some way equivalent to the PL/1 problem of having two lower
level elements of structures that have the same name, i. e.
dcl 1 thing1,
2 a,
3 c;
dcl 1 thing2,
2 b,
3 d,
4 c;
one can refer to the first c by typing thing1.c or thing1.a.c or a.c;
one can refer to the second c by typinging thing2.c or d.c or b.c;
Not quite sure how this would work in a network, particularly a constantly
changing network but if there is no reference to it should make an
interesting problem for a parallel algorithms class or a thesis project
or something.martin@vax135.UUCP (mh3510) (11/28/83)
Alan Silverstein writes in an article about uucp machine names:- ...... By the way... There are at least 50 systems in the world, most not yet announced publicly, which belong to HP (Hewlett Packard) and whose nodenames start with "hp". As far as I can tell, we are the only organization using that prefix, and we are consistent in the use of it. ...... Well i'm sorry to say that "Bell Labs, South Plainfield" have the internal (to AT&T) two letter code of HP, and they have a unix systems located there. the machine name is hpuxa!!, so there goes your theory. martin levy.
gjm@ihnp4.UUCP (Gary J. Murakami) (11/29/83)
Note that what we have been calling "UUCP syntax" should really be called "old UNIX(TM) mail addressing" or "UNIX System V mail addressing". The standard old /bin/mail implements the host1!host2!host3!...!user syntax, not UUCP! Case in point: path!user or host!user is useless to uucp (and uux), host!~user and host!~/user (and host!/file) is useful with uucp (host!command for uux). The mail path forwarding is achieved by successive remote executions of /bin/rmail as the address is reduced for each single hop forwarding. So modifying uucp (and uux) syntax only buys you confusion. Instead focus yourr ideas on mail addressing new mailer implementation, and easing the difficulty and pain of the unavoidable transition period. Gary Murakami Bell Labs - IH ihnp4!gjm
laura@utcsstat.UUCP (Laura Creighton) (12/03/83)
The problem with this scheme is that the theoretical site (decvax) must tack on a full address that also includes where it is going in the From line. Otherwise, let us suppose that somebody decides to mail me through decvax like this: foo!bar!baz!decvax!utzoo!utcsstat!mumble!laura where mumble is a local machine that i have which does not talk to decvax. Decvax gets this note, and optimises out the utzoo, and generates a from line that is: From: decvax!baz!bar!foo!person And sends it to utcsstat. Utcsstat sends it to mumble. I log into mumble and get my mail just fine, but when I try to reply, my mailer believes the From line -- and tries to send to decvax!baz!bar!foo!person. This isn't going to work, because mumble and decvax don't talk. Thus if you are generating a From line, and you are not mailing to the site that is the final destination, you should put in the full optimised path into your From line, right? So decvax should be putting in a from line that reads: From utcsstat!decvax!baz!bar!foo!person in the example. Laura Creighton utzoo!utcsstat!laura
fair@dual.UUCP (Erik E. Fair) (12/05/83)
Well, any magic spell that Armando the Wizard has cast over decvax's sendmail should reflect itself in the return address. If this is not the case, then he is doing it `wrong' (where `wrong' is an opinion on my part, of course). The thing is, I think that scheme would work out just fine given the way that uucp return addresses are generated: adding the names of the machines that a letter passes through, as it passes through. Letter from Laura to decvax!mumble!frotz!remote!person gets there through decvax!frotz!remote!person omitting `mumble', and the header would look something like this: From frotz!decvax!utcsstat!laura Mon Jan 1 00:00:01 1970 Date: Mon, 1 Jan 1983 00:00 EST From: Laura Creighton <utcsstat!laura> Subject: Flame! To: decvax!mumble!frotz!remote!person or for those of you still stuck with the v7 bell mailer: From uucp Mon Jan 1 00:00:01 1970 remote from frotz >From uucp Mon Jan 1 00:00:01 1970 remote from decvax >From laura Mon Jan 1 00:00:01 1970 remote from utcsstat Date: Mon, 1 Jan 1983 00:00 EST From: Laura Creighton <utcsstat!laura> Subject: Flame! To: decvax!mumble!frotz!remote!person The point is that although the To: line would not reflect reality, the From line (which most mailers I've ever seen depend on) would be correct. OK Armando, am I right? Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair Dual Systems Corporation, Berkeley, California P.S. Laura, I apologize if you (or anyone else) misconstrues that hypothetical header as a criticism of your usual mail to me or anyone else. \I/ know that you never flame.