rfc850.txt

RFC 的详细文档！



     Responding-System: cbosgd.UUCP
     cbosgd:osg,cb,btl,bell,net,fa,to,test
     ucbvax:net,fa,to.ucbvax:L:
     cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
     cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
     sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
     npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
     mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi

3.6  Senduuname

     senduuname      (no arguments)

The  "uuname"  program is run, and the output is mailed to
the  author  of the control message (Reply-to, if present,
otherwise From).  This program lists all uucp neighbors of
the  local site.  This information is used to make maps of
the UUCP network.  The sys file is not  the  same  as  the
UUCP   L.sys   file.   The  L.sys  file  should  never  be
transmitted to another party without the  consent  of  the
sites whose passwords are listed therein.

It is optional for a site  to  provide  this  information.
Some  reply  should  be  made to the author of the control
message, so that a transmission error won't be blamed.  It
is  also  permissible for a site to run the uuname program
(or in some other way determine the  uucp  neighbors)  and
edit  the output, either automatically or manually, before
mailing the reply back to the  author.   The  file  should
contain  one  site  per line, beginning with the uucp site
name.  Additional information may be  included,  separated
from the site name by a blank or tab.  The phone number or
password for the site should NOT be included, as the reply
is  considered  to  be  in the public domain.  (The uuname
program will send only the site name and  not  the  entire
contents  of  the  L.sys  file,  thus,  phone  numbers and
passwords are not transmitted.)

The purpose of this message is to  generate  and  maintain
UUCP mail routing maps.  Thus, connections over which mail
can be sent using the site!user syntax should be included,
regardless  of whether the link is actually a UUCP link at
the physical level.  If a mail router should  use  it,  it
should   be  included.   Since  all  information  sent  in
response to this message is optional, sites  are  free  to
edit  the  list,  deleting secret or private links they do
not wish to publicise.

3.7  Version

     version (no arguments)

The name and version of the software running on the  local
system  is  to be mailed back to the author of the article
(Reply-to if present, otherwise From).

                          - 13 -



4.  Transmission Methods

USENET is not a physical network,  but  rather  a  logical
network  resting  on  top  of  several  existing  physical
networks.  These networks include, but are not limited to,
UUCP,  the ARPANET, an Ethernet, the BLICN network, an NSC
Hyperchannel, and a Berknet.  What is  important  is  that
two  neighboring systems on USENET have some method to get
a new article, in the format listed here, from one  system
to  the other, and once on the receiving system, processed
by the netnews software on that system.  (On UNIX systems,
this  usually  means  the  "rnews"  program being run with
the article on the standard input.)

It is not  a  requirement  that  USENET  sites  have  mail
systems  capable  of  understanding the ARPA Internet mail
syntax, but  it  is  strongly  recommended.   Since  From,
Reply-To,  and  Sender  lines  use  the  Internet  syntax,
replies  will  be  difficult  or  impossible  without   an
internet  mailer.   A  site without an internet mailer can
attempt to use the Path header line for replies, but  this
field  is not guaranteed to be a working path for replies.
In any event,  any  site  generating  or  forwarding  news
messages must have an internet address that allows them to
receive mail from sites with internet  mailers,  and  they
must include their internet address on their From line.

4.1  Remote Execution

Some networks permit direct remote command execution.   On
these  networks,  news  may  be  forwarded by spooling the
rnews command with the article on the standard input.  For
example,  if  the remote system is called  "remote",  news
would be sent over a UUCP link with the  command   "uux  -
remote!rnews",   and on a Berknet,   "net -mremote rnews".
It is important that the article be sent  via  a  reliable
mechansim, normally involving the possibility of spooling,
rather than direct real-time remote  execution.   This  is
because,  if the remote system is down, a direct execution
command  will  fail,  and  the  article  will   never   be
delivered.   If the article is spooled, it will eventually
be delivered when both systems are up.

4.2  Transfer by Mail

On some systems, direct remote spooled  execution  is  not
possible.   However, most systems support electronic mail,
and a news article can be sent as mail.  One  approach  is
to  send  a  mail  message  which is identical to the news
message: the mail headers are the news  headers,  and  the
mail  body  is the news body.  By convention, this mail is
sent to the user  "newsmail"  on the remote machine.



                          - 14 -



One problem with  this  method  is  that  it  may  not  be
possible to convince the mail system that the From line of
the message is valid, since the mail message was generated
by  a program on a system different from the source of the
news article.  Another  problem  is  that  error  messages
caused  by  the  mail  transmission  would  be sent to the
originator of the news article, who has  no  control  over
news  transmission  between two cooperating hosts and does
not know who  to  contact.   Transmission  error  messages
should  be directed to a responsible contact person on the
sending machine.

A solution to this problem  is  to  encapsulate  the  news
article  into a mail message, such that the entire article
(headers and body) are  part  of  the  body  of  the  mail
message.  The convention here is that such mail is sent to
user  "rnews"  on the remote system.  A mail message  body
is  generated  by prepending the letter  "N"  to each line
of the news article,  and  then  attaching  whatever  mail
headers  are convenient to generate.  The N's are attached
to prevent any special lines  in  the  news  article  from
interfering  with  mail  transmission,  and to prevent any
extra lines inserted by the mailer (headers, blank  lines,
etc.)  from  becoming part of the news article.  A program
on the  receiving  machine  receives  mail  to    "rnews",
extracting  the  article itself and invoking the   "rnews" 
program.  An example in this format might look like this:

     Date: Monday, 3-Jan-83 08:33:47 MST
     From: [e-mail]
     Subject: network news article
     To: [e-mail]

     NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
     NPosting-Version: B 2.9 6/21/82 sask.UUCP
     NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
     NFrom: [e-mail] (Derek Andrew)
     NNewsgroups: net.test
     NSubject: necessary test
     NMessage-ID: <[e-mail]>
     NDate: Monday, 3-Jan-83 00:59:15 MST
     N
     NThis really is a test.  If anyone out there more than 6
     Nhops away would kindly confirm this note I would
     Nappreciate it.  We suspect that our news postings
     Nare not getting out into the world.
     N

Using mail solves the spooling problem,  since  mail  must
always  be  spooled  if  the  destination  host  is  down.
However, it adds more overhead to the transmission process
(to  encapsulate  and  extract  the  article) and makes it
harder for software to give different priorities  to  news
and mail.

                          - 15 -



4.3  Batching

Since news articles are usually short, and since  a  large
number  of  messages are often sent between two sites in a
day, it may make sense to batch  news  articles.   Several
articles  can  be  combined  into one large article, using
conventions agreed upon in advance by the two sites.   One
such  batching  scheme is described here; its use is still
considered experimental.

News articles are combined into a script, separated  by  a
header of the form:

     ##! rnews 1234

where 1234 is the length, in bytes, of the article.   Each
such  line  is followed by an article containing the given
number of bytes.  (The newline at the end of each line  of
the  article  is counted as one byte, for purposes of this
count, even if it is stored as CRLF.) For example, a batch
of articles might look like this:

      #! rnews 374
      Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
      Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
      Path: cbosgd!mhuxj!mhuxt!eagle!jerry
      From: [e-mail] (Jerry Schwarz)
      Newsgroups: net.general
      Subject: Usenet Etiquette -- Please Read
      Message-ID: <[e-mail]>
      Date: Friday, 19-Nov-82 16:14:55 EST

      Here is an important message about USENET Etiquette.
      #! rnews 378
      Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
      Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
      Path: cbosgd!mhuxj!mhuxt!eagle!jerry
      From: [e-mail] (Jerry Schwarz)
      Newsgroups: net.followup
      Subject: Notes on Etiquette article
      Message-ID: <[e-mail]>
      Date: Friday, 19-Nov-82 17:24:12 EST

      There was something I forgot to mention in the last message.

Batched news is recognized because the first character  in
the  message  is  "#".   The message is then passed to the
unbatcher for interpretation.







                          - 16 -


5.  The News Propagation Algorithm

This section describes the overall scheme  of  USENET  and
the algorithm followed by sites in propagating news to the
entire  network.   Since  all  sites   are   affected   by
incorrectly  formatted articles and by propagation errors,
it is important for the method to be standardized.

USENET is a directed graph.  Each node in the graph  is  a
host  computer,  each  arc  in the graph is a transmission
path from one host to another host.  Each arc is  labelled
with  a  newsgroup  pattern,  specifying  which  newsgroup
classes are forwarded along  that  link.   Most  arcs  are
bidirectional,  that  is,  if  site  A  sends  a  class of
newsgroups to site B, then site B usually sends  the  same
class  of  newsgroups to site A.  This bidirectionality is
not, however, required.

USENET is made up of many subnetworks.  Each subnet has  a
name,  such  as   "net"   or   "btl".   The special subnet
"net"   is defined to be USENET, although the union of all
subnets may be a superset of USENET (because of sites that
get local newsgroup classes but do not get net.all).  Each
subnet  is  a connected graph, that is, a path exists from
every  node  to  every  other  node  in  the  subnet.   In
addition,  the  entire graph is (theoretically) connected.
(In practice, some political  considerations  have  caused
some sites to be unable to post articles reaching the rest
of the network.)

An  article  is  posted  on  one  machine  to  a  list  of
newsgroups.    That   machine  accepts  it  locally,  then
forwards it to all its neighbors that are interested in at
least one of the newsgroups of the message.  (Site A deems
site  B  to  be   "interested"   in  a  newsgroup  if  the
newsgroup  matches  the  pattern  on  the arc from A to B.
This pattern is stored in a file on the  A  machine.)  The
sites  receiving  the  incoming article examine it to make
sure they really want the article, accept it locally,  and
then  in  turn forward the article to all their interest
neighbors.   This  process  continues  until  the   entire
network has seen the article.

An important part of the algorithm is  the  prevention  of
loops.   The  above  process would cause a message to loop
along a cycle forever.  In particular, when site  A  sends
an  article to site B, site B will send it back to site A,
which will send it to site B, and so on.  One solution  to
this  is  the history mechanism.  Each site keeps track of
all articles  it  has  seen  (by  their  message  ID)  and
whenever an article comes in that it has already seen, the
incoming article is discarded immediately.  This  solution
is   sufficient   to   prevent   loops,   but   additional
optimizations can be made to  avoid  sending  articles  to
sites that will simply throw them away.

                          - 17 -



One optimization is that an article should never  be  sent
to  a machine listed in the Path line of the header.  When
a machine name is in the Path line, the message  is  known
to  have passed through the machine.  Another optimization
is that, if the article originated on site A, then site  A
has   already  seen  the  article.   (Origination  can  be
determined by the Posting-Version line.)

Thus, if an article is posted to  newsgroup    "net.misc",
it  will match the pattern  "net.all"  (where  "all"  is a
metasymbol that matches any string), and will be forwarded
to  all  sites that subscribe to net.all (as determined by
what their neighbors send them).  These sites make up  the
"net"   subnetwork.   An article posted to   "btl.general" 
will reach all sites receiving  "btl.all",  but  will  not
reach  sites  that do not get  "btl.all".   In effect, the
articles  reaches  the   "btl"   subnetwork.   An  article
posted  to newsgroups  "net.micro,btl.general"  will reach
all sites subscribing to either of the two classes.

































                          - 18 -