woods@hao.UUCP (03/12/87)
Since we are a government research (NSF funded) facility, and all employees
have to sign a contract saying that anything they develop while working here
is public domain, we can hardly be excessively concerned with security.
However: I frequently see mail messages coming from sites that recently
issued a senduuname request to us getting queued for sites that we do not
really talk to. We have a number of sites that have "Never" in the "when-to-
call" field in the L.sys file. They are there for a variety of reasons;
typically, when we have a need to contact that site for a particular reason
(for example, "isi", the main machine at Integrated Solutions, Inc., the
maker of this machine, where we can file bug reports via uucp), we change
the call time field, mail a message to the appropriate alias on the remote
host, execute a uucico to them, and change it back to Never. We do NOT maintain
regular mail links to these hosts, but they are in our L.sys file (and hence
get reported by senduuname). This results in INCORRECT mapping information which
people attempt to use. These messages do not "bounce"; they just sit on our
disk taking up space and causing the person who sent it to wonder what the hell
happened (and resend it, compounding the problem). I for one am glad senduuname
is going away.
--Greg
--
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edudsp@ptsfa.UUCP (03/12/87)
In article <575@hao.UCAR.EDU> woods@hao.UUCP (Greg Woods) writes: > > However: I frequently see mail messages coming from sites that recently >issued a senduuname request to us getting queued for sites that we do not >really talk to. We have a number of sites that have "Never" in the "when-to- >call" field in the L.sys file. They are there for a variety of reasons; You missed Gordon's point. Make senduuname mail your current pathalias map entry. What you choose to have in your L.sys/Systems file can be your own business. Having a way of automatically collecting pathalias data can only make the paths your neighbors choose more correct. With the problems we've been experiencing getting a reasonable facsimile of accurate data out of mod.map in the Bay Area, I wish everyone converted senduuname to do what Gordon has suggested. -- David St. Pierre 415/823-6800 {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!dsp The early bird will find his can of worms.
rick@seismo.UUCP (03/13/87)
The correct thing to do would be to add a new control message to do a new task, Not mutate an old one to do what you want. ---rick
ggere@csi.UUCP (03/13/87)
In article <43150@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >The correct thing to do would be to add a new control message to >do a new task, Not mutate an old one to do what you want. > > >---rick Fine. Then I vote we add such a new control message. I modified our 2.10 news a long time ago to return the latest UUCP map entry in response to the senduuname control message, and did the same when we upgraded to 2.11 news. This facility does provide the means to gather uucp site connection information and I believe it is useful now and could be much more so in cases such as gathering uucp site information for sites with out of date maps. I too have had difficulty getting our map update into Map Central. A little automation might allow for the automagic collection of maps at appropriate times and remove some burden from the map maintainer volunteers. -- =============================================================================== Communications Solutions 992 S. Saratoga-Sunnyvale Road San Jose, Calif 95129 Gary M. Gere {bnrmtv,nsc,dual}!csi!ggere 4087251568
heiby@mcdchg.UUCP (03/13/87)
In article <43150@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >The correct thing to do would be to add a new control message to >do a new task, Not mutate an old one to do what you want. I agree with the principle, but didn't believe this to be an instance. Then, I looked up what standard.mn says about the senduuname control message. (Does standard.mn get edited when the software stops supporting part of it?) The standard says that the list of hostnames is to be returned one per line. This means that the script that I've been using as UUPROG is "non-standard". -------------------- echo "Here is our public UUCP map entry.\n-----" cat /usr/mot/heiby/mcdchg.map -------------------- I would favor the creation of a "sendmapentry" control message, which would do essentially what the above script does. In many areas, a large number of the map files could be collected semi-automatically by the map maintainer, just by specifying the appropriate "Distribution", like "nj", "ca", or "att". I know that I keep my "mcdchg.map" file completely up-to-date as connection information changes, but only send it off when there has been what I consider to be a significant change and I think it will be kinda stable for a while. Having the control message automatically grab the current version when it was time for an update, would be real nice. I have been procrastinating on installing patch #5, as I liked the senduuname stuff, but since re-reading the standard, I've found that I was not conforming in the first place. I'll be upgrading to the new patch level right away. -- Ron Heiby, mcdchg!heiby Moderator: mod.newprod & mod.os.unix Motorola Microcomputer Division (MCD), Schaumburg, IL "Save your energy. Save yourselves. Avoid the planet 'cuae2' at all costs!"