Standard for interchange of USENET messages

RFC 850 June 1983

Standard for Interchange of USENET Messages

                      Mark R. Horton

[ This memo is distributed as an RFC  only  to  make  this
information  easily  accessible to researchers in the ARPA
community.  It does not specify  an  Internet  standard. ]

1. Introduction

This document defines the standard format for  interchange
of Network News articles among USENET sites.  It describes
the format for  articles  themselves,  and  gives  partial
standards for transmission of news.  The news transmission
is not entirely standardized in order to give a good  deal
of   flexibility   to   the  individual  hosts  to  choose
transmission hardware and software, whether to batch news,
and so on.

There are five sections to  this  document.   Section  two
section  defines  the  format.   Section three defines the
valid control messages.  Section four specifies some valid
transmission  methods.  Section five describes the overall
news propagation algorithm.

2. Article Format

The primary consideration in choosing an article format is
that  it  fit  in with existing tools as well as possible.
Existing tools include both implementations  of  mail  and
news.   (The  notesfiles  system  from  the  University of
Illinois is considered a news implementation.) A  standard
format for mail messages has existed for many years on the
ARPANET, and this  format  meets  most  of  the  needs  of
USENET.    Since   the   ARPANET   format  is  extensible,
extensions to meet the  additional  needs  of  USENET  are
easily  made  within the ARPANET standard.  Therefore, the
rule is adopted that all  USENET  news  articles  must  be
formatted as valid ARPANET mail messages, according to the
ARPANET  standard  RFC  822.   This   standard   is   more
restrictive  than the ARPANET standard, placing additional
requirements on each article and forbidding use of certain
ARPANET  features.   However, it should always be possible
to use a tool expecting an ARPANET message  to  process  a
news  article.   In  any  situation  where  this  standard
conflicts with the ARPANET standard,  RFC  822  should  be
considered correct and this standard in error.

An example message is included to illustrate the fields.

     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: jerry@eagle.uucp (Jerry Schwarz)
     Newsgroups: net.general
     Subject: Usenet Etiquette -- Please Read
     Message-ID: <642@eagle.UUCP>
     Date: Friday, 19-Nov-82 16:14:55 EST
     Followup-To: net.news
     Expires: Saturday, 1-Jan-83 00:00:00 EST
     Date-Received: Friday, 19-Nov-82 16:59:30 EST
     Organization: Bell Labs, Murray Hill

The body of the article comes here, after a blank line.

Here is an example of a message in the old format  (before
the  existence  of this standard).  It is recommended that
implementations also accept articles  in  this  format  to
ease upward conversion.

     From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
     Newsgroups: net.general
     Title: Usenet Etiquette -- Please Read
     Article-I.D.: eagle.642
     Posted: Fri Nov 19 16:14:55 1982
     Received: Fri Nov 19 16:59:30 1982
     Expires: Mon Jan  1 00:00:00 1990

The body of the article comes here, after a blank line.

Some news systems transmit news in the "A" format, which

looks like this:

Aeagle.642
net.general
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
The body of the article comes here, with no blank line.

An article consists of several header lines, followed by a
blank  line,  followed  by  the  body of the message.  The
header lines consist of a keyword, a colon, a  blank,  and
some  additional  information.   This  is  a subset of the
ARPANET standard, simplified to allow simpler software  to
handle  it.   The   "from"   line may optionally include a
full name, in the format above, or use the  ARPANET  angle
bracket syntax.  To keep the implementations simple, other
formats (for example, with part  of  the  machine  address
after the close parenthesis) are not allowed.  The ARPANET
convention of continuation header lines (beginning with  a
blank or tab) is allowed.

Certain  headers  are  required,   certain   headers   are
optional.   Any unrecognized headers are allowed, and will
be passed through unchanged.   The  required  headers  are
Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
Subject,  Message-ID,  Path.   The  optional  headers  are
Followup-To,  Date-Received,  Expires,  Reply-To,  Sender,
References, Control, Distribution, Organization.

2.1 Required Headers

2.1.1  Relay-Version  This header line shows  the  version
of  the  program  responsible for the transmission of this
article over the immediate link, that is, the program that
is  relaying the article from the next site.  For example,
suppose site A sends an article to  site  B,  and  site  B
forwards  the  article  to  site  C.   The  message  being
transmitted from A to B would have a Relay-Version  header
identifying  the  program  running  on  A, and the message
transmitted from B to C would identify the program running
on  B.  This header can be used to interpret older headers
in an upward compatible way.  Relay-Version must always be
the  first  in  a message; thus, all articles meeting this
standard will begin with an upper case   "R".    No  other
restrictions are placed on the order of header lines.

The line contains two  fields,  separated  by  semicolons.
The fields are the version and the full domain name of the
site.  The version should identify the system program used
(e.g.,   "B")   as  well  as  a version number and version
date.  For example, the header line might contain

   Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

This header should not be passed on to  additional  sites.
A  relay  program,  when  passing  an  article  on, should
include only its own Relay-Version, not the  Relay-Version
of  some other site.  (For upward compatibility with older
software, if a Relay-Version is found in a header which is
not the first line, it should be assumed to be moved by an
older version of news and deleted.)

2.1.2  Posting-Version    This   header   identifies   the
software  responsible  for  entering this message into the
network.  It has the same  format  as  Relay-Version.   It
will  normally  identify  the same site as the Message-ID,
unless the posting site is serving  as  a  gateway  for  a
message  that  already  contains a message ID generated by
mail.  (While it is permissible for a gateway  to  use  an
externally  generated message ID, the message ID should be
checked to ensure it conforms to this standard and to  RFC
822.)
2.1.3  From  The From line contains the electronic mailing
address  of  the  person who sent the message, in the ARPA
internet syntax.  It may optionally also contain the  full
name  of  the person, in parentheses, after the electronic
address.  The electronic address is the same as the entity
responsible for originating the article, unless the Sender
header is present, in which case the From header might not
be  verified.   Note  that  in  all site and domain names,
upper  and  lower  case  are  considered  the  same,  thus
mark@cbosgd.UUCP,  mark@cbosgd.uucp,  and mark@CBosgD.UUcp
are all equivalent.  User names may or  may  not  be  case
sensitive,   for   example,   Billy@cbosgd.UUCP  might  be
different from BillY@cbosgd.UUCP.  Programs  should  avoid
changing  the case of electronic addresses when forwarding
news or mail.

RFC 822 specifies that all text in parentheses  is  to  be
interpreted as a comment.  It is common in ARPANET mail to
place the full name of the user in a comment at the end of
the  From  line.   This  standard  specifies  a more rigid
syntax.  The full name is not considered a comment, but an
optional part of the header line.  Either the full name is
omitted, or it appears in parentheses after the electronic
address  of  the person posting the article, or it appears
before an electronic address enclosed in  angle  brackets.
Thus, the three permissible forms are:

     From: mark@cbosgd.UUCP
     From: mark@cbosgd.UUCP (Mark Horton)
     From: Mark Horton <mark@cbosgd.UUCP>

Full names may contain any printing ASCII characters  from
space through tilde, with the exceptions that they may not
contain parentheses  "("   or   ")",   or  angle  brackets
"<"   or  ">".    Additional restrictions may be placed on
full names  by  the  mail  standard,  in  particular,  the
characters  comma   ",",  colon  ":",  and semicolon   ";" 
are inadvisable in full names.

2.1.4  Date  The Date line (formerly   "Posted")   is  the
date,  in  a  format  that  must be acceptable both to the
ARPANET and to the getdate routine, that the  article  was
originally  posted  to  the  network.   This  date remains
unchanged as the  article  is  propagated  throughout  the
network.  One format that is acceptable to both is

     Weekday, DD-Mon-YY HH:MM:SS TIMEZONE

Several examples of valid dates appear in the sample

article above. Note in particular that ctime format:

     Wdy Mon DD HH:MM:SS YYYY

is not acceptable because it is not a valid ARPANET  date.
However, since older software still generates this format,
news implementations are encouraged to accept this  format
and translate it into an acceptable format.

The contents of the TIMEZONE field is currently subject to
worldwide time zone  abbreviations,  including  the  usual
American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
the   other   North   American   zones   (Bering   through
Newfoundland),  European  zones,  Australian zones, and so
on.  Lacking a complete list at present (and unsure if  an
unambiguous   list   exists),   authors  of  software  are
encouraged to keep this code flexible, and  in  particular
not  to  assume  that  time  zone  names are exactly three
letters long.   Implementations  are  free  to  edit  this
field,  keeping  the  time the same, but changing the time
zone (with an appropriate adjustment  to  the  local  time
shown) to a known time zone.

2.1.5  Newsgroups  The  Newsgroups  line  specifies  which
newsgroup  or newsgroups the article belongs in.  Multiple
newsgroups  may  be  specified,  separated  by  a   comma.
Newsgroups  specified  must  all  be the names of existing
newsgroups, as no new newsgroups will be created by simply
posting to them.

Wildcards (e.g., the word  "all")  are never allowed in  a
Newsgroups  line.  For example, a newsgroup  "net.all"  is
illegal, although a newsgroup name    "net.sport.football" 
is permitted.

If an article is received with a Newsgroups  line  listing
some  valid newsgroups and some invalid newsgroups, a site
should  not  remove  invalid  newsgroups  from  the  list.
Instead,  the  invalid  newsgroups should be ignored.  For
example,  suppose  site  A  subscribes  to   the   classes
"btl.all"   and   "net.all",   and exchanges news articles
with site B,  which  subscribes  to   "net.all"   but  not
"btl.all".      Suppose   A   receives   an  article  with
"Newsgroups: net.micro,btl.general".     This  article  is
passed  on  to  B because B receives net.micro, but B does
not receive btl.general.  A must leave the Newsgroup  line
unchanged.   If  it  were  to  remove  "btl.general",  the
edited header could  eventually  reenter  the    "btl.all" 
class,  resulting in an article that is not shown to users
subscribing  to   "btl.general".    Also,  followups  from
outside  "btl.all"  would not be shown to such users.
2.1.6  Subject   The  Subject  line  (formerly    "Title")
tells  what the article is about.  It should be suggestive
enough of the contents of the article to enable  a  reader
to  make  a  decision whether to read the article based on
the  subject  alone.   If  the  article  is  submitted  in
response  to another article (e.g., is a  "followup")  the
default subject should  begin  with  the  four  characters
"Re: "   and the References line is required.    (The user
might wish to edit the subject of the  followup,  but  the
default should begin with  "Re: ".)

2.1.7  Message-ID  The Message-ID line gives the article a
unique  identifier.  The same message ID may not be reused
during the lifetime of any article with the  same  message
ID.   (It  is recommended that no message ID be reused for
at least two years.) Message ID's have the syntax

"<" "string not containing blank or >" ">"

In order to conform to RFC 822, the Message-ID must have

the format

"<" "unique" "@" "full domain name" ">"

where  "full domain name"  is the full name of the host at
which  the article entered the network, including a domain
that host is in, and unique  is  any  string  of  printing
ASCII  characters,  not  including  "<", ">", or "@".  For
example,  the  "unique"   part   could   be   an   integer
representing  a  sequence number for articles submitted to
the network, or a short string derived from the  date  and
time  the article was created.  For example, valid message
ID for an article submitted from  site  ucbvax  in  domain
Berkeley.ARPA   would   be  "<4123@ucbvax.Berkeley.ARPA>".
Programmers are urged not to make  assumptions  about  the
content  of  message  ID  fields  from other hosts, but to
treat them as unknown character strings.  It is not  safe,
for  example, to assume that a message ID will be under 14
characters,  nor  that  it  is  unique  in  the  first  14
characters.

The angle brackets are considered part of the message  ID.
Thus,  in  references  to  the  message  ID,  such  as the
ihave/sendme  and  cancel  control  messages,  the   angle
brackets  are  included.   White  space  characters (e.g.,
blank and tab) are not  allowed  in  a  message  ID.   All
characters  between  the  angle  brackets must be printing
ASCII characters.

2.1.8  Path  This line shows the path the article took  to
reach  the  current  system.   When  a system forwards the
message, it should add its own name to the list of systems
in  the  Path  line.   The  names  may be separated by any
punctuation     character     or     characters,      thus
"cbosgd!mhuxj!mhuxt",    "cbosgd,  mhuxj,  mhuxt",     and
"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp"      and       even
"teklabs,   zehntel,   sri-unix@cca!decvax"    are   valid
entries.  (The latter path indicates a message that passed
through  decvax,  cca,  sri-unix, zehntel, and teklabs, in
that order.) Additional names should  be  added  from  the
left,  for  example,  the  most recently added name in the
third example was  "teklabs".   Letters,  digits,  periods
and  hyphens  are  considered  part  of  site names; other
punctuation, including blanks, are considered separators.

Normally, the rightmost name  will  be  the  name  of  the
originating  system.   However,  it is also permissible to
include an extra entry on the right, which is the name  of
the  sender.   This is for upward compatibility with older
system.

The Path line is not used for replies, and should  not  be
taken  as  a  mailing address.  It is intended to show the
route the message  travelled  to  reach  the  local  site.
There  are  several  uses for this information.  One is to
monitor USENET routing for performance  reasons.   Another
is  to  establish  a path to reach new sites.  Perhaps the
most important is to cut down on redundant USENET  traffic
by failing to forward a message to a site that is known to
have already received it.   In  particular,  when  site  A
sends  an article to site B, the Path line includes   "A",
so that site B will not immediately send the article  back
to  site  A.   The  site  name  each site uses to identify
itself should be  the  same  as  the  name  by  which  its
neighbors  know  it,  in  order  to make this optimization
possible.

A site adds its own name to the front of a  path  when  it
receives  a message from another site.  Thus, if a message
with path A!X!Y!Z is passed from site A to site B, B  will
add  its own name to the path when it receives the message
from A, e.g., B!A!X!Y!Z.  If B then passes the message  on
to  C,  the  message  sent  to  C  will  contain  the path
B!A!X!Y!Z, and when C receives it, C  will  change  it  to
C!B!A!X!Y!Z.

Special upward compatibility note: Since the From, Sender,
and  Reply-To lines are in internet format, and since many
USENET  sites  do  not  yet  have   mailers   capable   of
understanding  internet  format,  it would break the reply
capability to completely sever the connection between  the
Path  header  and  the  reply  function.   Thus, sites are
required to continue to keep the Path line  in  a  working
reply  format  as much as possible, until January 1, 1984.
It is recognized that the path is not always a valid reply
string in older implementations, and no requirement to fix
this problem is placed on implementations.   However,  the
existing  convention of placing the site name and an   "!" 
at the front of the path, and of starting  the  path  with
the  site  name,  an   "!",   and the user name, should be
maintained at least until 1984.

2.2 Optional Headers

2.2.1  Reply-To  This line has the same  format  as  From.
If present, mailed replies to the author should be sent to
the name given here.  Otherwise, replies are mailed to the
name  on the From line.  (This does not prevent additional
copies from being sent to recipients named by the replier,
or  on  To  or  Cc lines.) The full name may be optionally
given, in parentheses, as in the From line.

2.2.2  Sender  This field is present only if the submitter
manually enters a From line.  It is intended to record the
entity responsible  for  submitting  the  article  to  the
network,  and  should  be  verified by the software at the
submitting site.

For example, if John Smith is visiting CCA and  wishes  to
post  an  article to the network, using friend Sarah Jones
account, the message might read

     From: smith@ucbvax.uucp (John Smith)
     Sender: jones@cca.arpa (Sarah Jones)

If a gateway program enters a mail message into the

network at site sri-unix, the lines might read

     From: John.Doe@CMU-CS-A.ARPA
     Sender: network@sri-unix.ARPA

The primary purpose of this field is to be able  to  track
down  articles to determine how they were entered into the
network.  The  full  name  may  be  optionally  given,  in
parentheses, as in the From line.

2.2.3  Followup-To  This  line  has  the  same  format  as
Newsgroups.   If  present,  follow-up  articles  are to be
posted to the newsgroup(s) listed here.  If this  line  is
not  present,  followups  are  posted  to the newsgroup(s)
listed in the Newsgroups line, except  that  followups  to
"net.general"  should instead go to  "net.followup".

2.2.4  Date-Received  This line (formerly  "Received")  is
in  a  legal  USENET date format.  It records the date and
time that the article was  first  received  on  the  local
system.   If  this  line  is  present  in an article being
transmitted from one host to another, the  receiving  host
should  ignore  it  and  replace it with the current date.
Since this field is intended for local use only,  no  site
is  required  to support it.  However, no site should pass
this field on to another site unchanged.
2.2.5  Expires  This line,  if  present,  is  in  a  legal
USENET  date  format.  It specifies a suggested expiration
date for the article.  If not present, the  local  default
expiration date is used.

This field is intended to be used  to  clean  up  articles
with  a  limited usefulness, or to keep important articles
around for longer than  usual.   For  example,  a  message
announcing  an  upcoming  seminar could have an expiration
date the day after the seminar, since the message  is  not
useful  after the seminar is over.  Since local sites have
local  policies  for  expiration  of  news  (depending  on
available disk space, for instance), users are discouraged
from providing expiration dates for articles unless  there
is  a  natural  expiration date associated with the topic.
System software should  almost  never  provide  a  default
Expires line.  Leave it out and allow local policies to be
used unless there is a good reason not to.

2.2.6  References  This field lists the  message  ID's  of
any articles prompting the submission of this article.  It
is required for all follow-up articles, and forbidden when
a new subject is raised.  Implementations should provide a
follow-up command, which allows a user to post a follow-up
article.   This  command  should  generate  a Subject line
which is the same as the original article, except that  if
the original subject does not begin with "Re: " or "re: ",
the  four  characters   "Re: "  are  inserted  before  the
subject.   If  there is no References line on the original
header, the References line should contain the message  ID
of  the  original  article (including the angle brackets).
If the original article does have a References  line,  the
followup  article should have a References line containing
the text of the original References line, a blank, and the
message ID of the original article.

The purpose of the References header is to allow  articles
to  be  grouped  into  conversations by the user interface
program.  This allows conversations within a newsgroup  to
be  kept  together,  and  potentially users might shut off
entire conversations without unsubscribing to a newsgroup.
User  interfaces  may not make use of this header, but all
automatically  generated  followups  should  generate  the
References line for the benefit of systems that do use it,
and manually generated followups (e.g. typed in well after
the  original  article  has  been  printed by the machine)
should be encouraged to include them as well.

2.2.7  Control  If an article contains a Control line, the
article  is  a control message.  Control messages are used
for communication among USENET host machines,  not  to  be
read  by  users.   Control messages are distributed by the
same newsgroup mechanism as ordinary messages.   The  body
of the Control header line is the message to the host.
For  upward  compatibility,  messages   that   match   the
newsgroup   pattern    "all.all.ctl"    should   also   be
interpreted as control messages.  If no Control: header is
present  on  such  messages,  the  subject  is used as the
control message.  However, messages on newsgroups matching
this pattern do not conform to this standard.

2.2.8  Distribution   This  line  is  used  to  alter  the
distribution scope of the message.  It has the same format
as the Newsgroups  line.   User  subscriptions  are  still
controlled  by  Newsgroups, but the message is sent to all
systems subscribing to the newsgroups on the  Distribution
line instead of the Newsgroups line.  Thus, a car for sale
in New Jersey might have headers including

     Newsgroups: net.auto,net.wanted
     Distribution: nj.all

so that  it  would  only  go  to  persons  subscribing  to
net.auto  or  net.wanted within New Jersey.  The intent of
this header is to further restrict the distribution  of  a
newsgroup, not to increase it.  A local newsgroup, such as
nj.crazy-eddie, will probably not be propagated  by  sites
outside  New  Jersey  that do not show such a newsgroup as
valid.  Wildcards in newsgroup names in  the  Distribution
line are allowed.  Followup articles should default to the
same Distribution line as the original  article,  but  the
user  can change it to a more limited one, or escalate the
distribution if it was originally restricted  and  a  more
widely distributed reply is appropriate.

2.2.9  Organization  The text of  this  line  is  a  short
phrase  describing  the  organization  to which the sender
belongs, or to which the machine belongs.  The  intent  of
this  line  is  to  help  identify  the person posting the
message, since site names are often cryptic enough to make
it  hard  to  recognize the organization by the electronic
address.

3. Control Messages

This section lists the control messages currently defined.
The  body  of  the  Control header is the control message.
Messages are a sequence of zero or more  words,  separated
by  white  space  (blanks or tabs).  The first word is the
name  of  the  control  message,   remaining   words   are
parameters  to  the  message.  The remainder of the header
and the body of the message are also potential parameters;
for  example,  the  From  line might suggest an address to
which a response is to be mailed.
Implementors  and  administrators  may  choose  to   allow
control  messages  to  be automatically carried out, or to
queue  them  for  manual  processing.   However,  manually
processed messages should be dealt with promptly.

3.1 Cancel

     cancel <message ID>

If an article with the given message ID is present on  the
local  system,  the  article is cancelled.  This mechanism
allows a user to cancel an article after the  article  has
been distributed over the network.

Only the author of the article or the local super user  is
allowed  to  use  this  message.  The verified sender of a
message is the Sender  line,  or  if  no  Sender  line  is
present, the From line.  The verified sender of the cancel
message must be the same as  either  the  Sender  or  From
field  of  the original message.  A verified sender in the
cancel message is allowed to match an unverified  From  in
the original message.

3.2 Ihave/Sendme

ihave <message ID list> <remotesys> sendme <message ID list> <remotesys>

This message is part  of  the   "ihave/sendme"   protocol,
which  allows  one  site  (say  "A")  to tell another site
("B")  that  a particular message has been received on  A.
Suppose  that site A receives article  "ucbvax.1234",  and
wishes to transmit the article to site  B.   A  sends  the
control  message   "ihave  ucbvax.1234  A"   to site B (by
posting it to newsgroup  "to.B").   B  responds  with  the
control  message   "sendme  ucbvax.1234  B"  (on newsgroup
to.A) if it has not already received  the  article.   Upon
receiving the Sendme message, A sends the article to B.

This protocol can be used to cut down on redundant traffic
between  sites.  It is optional and should be used only if
the particular situation makes it worthwhile.  Frequently,
the  outcome  is  that,  since  most original messages are
short, and since there is a high overhead to start sending
a  new  message  with  UUCP,  it costs as much to send the
Ihave as it would cost to send the article itself.

One possible solution to this overhead problem is to batch
requests.   Several  message  ID's  may  be  announced  or
requested in one message.  If no message ID's  are  listed
in  the control message, the body of the message should be
scanned for message ID's, one per line.

3.3 Newgroup

     newgroup <groupname>

This control message creates a new newsgroup with the name
given.  Since no articles may be posted or forwarded until
a newsgroup is created, this message is required before  a
newsgroup  can  be  used.   The  body  of  the  message is
expected to be a short paragraph describing  the  intended
use of the newsgroup.

3.4 Rmgroup

     rmgroup <groupname>

This message removes a  newsgroup  with  the  given  name.
Since  the  newsgroup  is  removed  from every site on the
network, this  command  should  be  used  carefully  by  a
responsible administrator.

3.5 Sendsys

     sendsys (no arguments)

The   "sys"   file,  listing  all  neighbors   and   which
newsgroups  are  sent  to each neighbor, will be mailed to
the author of the control message (Reply-to,  if  present,
otherwise  From).   This  information is considered public
information, and it is  a  requirement  of  membership  in
USENET  that  this  information  be  provided  on request,
either automatically in response to this control  message,
or  manually,  by mailing the requested information to the
author of the message.  This information is used  to  keep
the  map  of  USENET  up  to  date, and to determine where
netnews is sent.

The format of the file mailed back to the author should be
the same as that of the  "sys"  file.  This format has one
line per neighboring site (plus one  line  for  the  local
site),  containing four colon separated fields.  The first
field has the site name of the neighbor, the second  field
has  a newsgroup pattern describing the newsgroups sent to
the neighbor.  The third and fourth fields are not defined
by this standard.  A sample response:

     From cbosgd!mark  Sun Mar 27 20:39:37 1983
     Subject: response to your sendsys request
     To: mark@cbosgd.UUCP
     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).

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.
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: news@cbosgd.UUCP
     Subject: network news article
     To: rnews@npois.UUCP

     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: derek@sask.UUCP (Derek Andrew)
     NNewsgroups: net.test
     NSubject: necessary test
     NMessage-ID: <176@sask.UUCP>
     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.

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: jerry@eagle.uucp (Jerry Schwarz)
      Newsgroups: net.general
      Subject: Usenet Etiquette -- Please Read
      Message-ID: <642@eagle.UUCP>
      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: jerry@eagle.uucp (Jerry Schwarz)
      Newsgroups: net.followup
      Subject: Notes on Etiquette article
      Message-ID: <643@eagle.UUCP>
      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.

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.
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 -