RFC relevance of original

As per Relevance of the word original, we have this rfc below:

RFC 850 June 1983

Standard for Interchange of USENET

Mark R.

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

1.

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

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

2. Article

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

- 1 -

An example message is included to illustrate the fields

Relay-Version: version B 2.10 2/13/83; site cbosgd.
Posting-Version: version B 2.10 2/13/83; site eagle.
Path: cbosgd!mhuxj!mhuxt!eagle!
From: jerry@eagle.uucp (Jerry Schwarz
Newsgroups: net.
Subject: Usenet Etiquette -- Please
Message-ID: <642@eagle.UUCP
Date: Friday, 19-Nov-82 16:14:55
Followup-To: net.
Expires: Saturday, 1-Jan-83 00:00:00
Date-Received: Friday, 19-Nov-82 16:59:30
Organization: Bell Labs, Murray

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

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

From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz
Newsgroups: net.
Title: Usenet Etiquette -- Please
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,
looks like this

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

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

- 2 -

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

2.1 Required

2.1.1 Relay-Version This header line shows the
of the program responsible for the transmission of
article over the immediate link, that is, the program
is relaying the article from the next site. For example
suppose site A sends an article to site B, and site
forwards the article to site C. The message
transmitted from A to B would have a Relay-Version
identifying the program running on A, and the
transmitted from B to C would identify the program
on B. This header can be used to interpret older
in an upward compatible way. Relay-Version must always
the first in a message; thus, all articles meeting
standard will begin with an upper case "R". No
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
site. The version should identify the system program
(e.g., "B") as well as a version number and
date. For example, the header line might

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

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

2.1.2 Posting-Version This header identifies
software responsible for entering this message into
network. It has the same format as Relay-Version.
will normally identify the same site as the Message-ID
unless the posting site is serving as a gateway for
message that already contains a message ID generated
mail. (While it is permissible for a gateway to use
externally generated message ID, the message ID should
checked to ensure it conforms to this standard and to
822.)

- 3 -

2.1.3 From The From line contains the electronic
address of the person who sent the message, in the
internet syntax. It may optionally also contain the
name of the person, in parentheses, after the
address. The electronic address is the same as the
responsible for originating the article, unless the
header is present, in which case the From header might
be verified. Note that in all site and domain names
upper and lower case are considered the same,
mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.
are all equivalent. User names may or may not be
sensitive, for example, Billy@cbosgd.UUCP might
different from BillY@cbosgd.UUCP. Programs should
changing the case of electronic addresses when
news or mail

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

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

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

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

Several examples of valid dates appear in the
article above. Note in particular that ctime format

Wdy Mon DD HH:MM:SS

- 4 -

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
and translate it into an acceptable format

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

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

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

If an article is received with a Newsgroups line
some valid newsgroups and some invalid newsgroups, a
should not remove invalid newsgroups from the list
Instead, the invalid newsgroups should be ignored.
example, suppose site A subscribes to the
"btl.all" and "net.all", and exchanges news
with site B, which subscribes to "net.all" but
"btl.all". Suppose A receives an article
"Newsgroups: net.micro,btl.general". This article
passed on to B because B receives net.micro, but B
not receive btl.general. A must leave the Newsgroup
unchanged. If it were to remove "btl.general",
edited header could eventually reenter the "btl.all"
class, resulting in an article that is not shown to
subscribing to "btl.general". Also, followups
outside "btl.all" would not be shown to such users

- 5 -

2.1.6 Subject The Subject line (formerly "Title")
tells what the article is about. It should be
enough of the contents of the article to enable a
to make a decision whether to read the article based
the subject alone. If the article is submitted
response to another article (e.g., is a "followup")
default subject should begin with the four
"Re: " and the References line is required. (The
might wish to edit the subject of the followup, but
default should begin with "Re: ".)

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

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

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

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

where "full domain name" is the full name of the host
which the article entered the network, including a
that host is in, and unique is any string of
ASCII characters, not including "<", ">", or "@".
example, the "unique" part could be an
representing a sequence number for articles submitted
the network, or a short string derived from the date
time the article was created. For example, valid
ID for an article submitted from site ucbvax in
Berkeley.ARPA would be "<4123@ucbvax.Berkeley.ARPA>".
Programmers are urged not to make assumptions about
content of message ID fields from other hosts, but
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
ihave/sendme and cancel control messages, the
brackets are included. White space characters (e.g.,
blank and tab) are not allowed in a message ID.
characters between the angle brackets must be
ASCII characters

2.1.8 Path This line shows the path the article took
reach the current system. When a system forwards
message, it should add its own name to the list of
in the Path line. The names may be separated by
punctuation character or characters,

- 6 -

"cbosgd!mhuxj!mhuxt", "cbosgd, mhuxj, mhuxt",
"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp" and
"teklabs, zehntel, sri-unix@cca!decvax" are
entries. (The latter path indicates a message that
through decvax, cca, sri-unix, zehntel, and teklabs,
that order.) Additional names should be added from
left, for example, the most recently added name in
third example was "teklabs". Letters, digits,
and hyphens are considered part of site names;
punctuation, including blanks, are considered separators

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

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

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

Special upward compatibility note: Since the From, Sender
and Reply-To lines are in internet format, and since
USENET sites do not yet have mailers capable
understanding internet format, it would break the
capability to completely sever the connection between
Path header and the reply function. Thus, sites
required to continue to keep the Path line in a
reply format as much as possible, until January 1, 1984.
It is recognized that the path is not always a valid
string in older implementations, and no requirement to
this problem is placed on implementations. However,

- 7 -

existing convention of placing the site name and an "!"
at the front of the path, and of starting the path
the site name, an "!", and the user name, should
maintained at least until 1984.

2.2 Optional

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

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

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

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

If a gateway program enters a mail message into
network at site sri-unix, the lines might

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

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

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

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

- 8 -

2.2.5 Expires This line, if present, is in a
USENET date format. It specifies a suggested
date for the article. If not present, the local
expiration date is used

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

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

The purpose of the References header is to allow
to be grouped into conversations by the user
program. This allows conversations within a newsgroup
be kept together, and potentially users might shut
entire conversations without unsubscribing to a newsgroup
User interfaces may not make use of this header, but
automatically generated followups should generate
References line for the benefit of systems that do use it
and manually generated followups (e.g. typed in well
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,
article is a control message. Control messages are
for communication among USENET host machines, not to
read by users. Control messages are distributed by
same newsgroup mechanism as ordinary messages. The
of the Control header line is the message to the host

- 9 -

For upward compatibility, messages that match
newsgroup pattern "all.all.ctl" should also
interpreted as control messages. If no Control: header
present on such messages, the subject is used as
control message. However, messages on newsgroups
this pattern do not conform to this standard

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

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

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

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

3. Control

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,
by white space (blanks or tabs). The first word is
name of the control message, remaining words
parameters to the message. The remainder of the
and the body of the message are also potential parameters
for example, the From line might suggest an address
which a response is to be mailed

- 10 -

Implementors and administrators may choose to
control messages to be automatically carried out, or
queue them for manual processing. However,
processed messages should be dealt with promptly

3.1

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

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

3.2 Ihave/

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

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

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

- 11 -

3.3

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

3.4

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

3.5

sendsys (no arguments

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

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

From cbosgd!mark Sun Mar 27 20:39:37 1983
Subject: response to your sendsys
To: mark@cbosgd.

- 12 -

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

3.6

senduuname (no arguments

The "uuname" program is run, and the output is mailed
the author of the control message (Reply-to, if present
otherwise From). This program lists all uucp neighbors
the local site. This information is used to make maps
the UUCP network. The sys file is not the same as
UUCP L.sys file. The L.sys file should never
transmitted to another party without the consent of
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
message, so that a transmission error won't be blamed.
is also permissible for a site to run the uuname
(or in some other way determine the uucp neighbors)
edit the output, either automatically or manually,
mailing the reply back to the author. The file
contain one site per line, beginning with the uucp
name. Additional information may be included,
from the site name by a blank or tab. The phone number
password for the site should NOT be included, as the
is considered to be in the public domain. (The
program will send only the site name and not the
contents of the L.sys file, thus, phone numbers
passwords are not transmitted.)

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

3.7

version (no arguments

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

- 13 -

4. Transmission

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

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

4.1 Remote

Some networks permit direct remote command execution.
these networks, news may be forwarded by spooling
rnews command with the article on the standard input.
example, if the remote system is called "remote",
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
mechansim, normally involving the possibility of spooling
rather than direct real-time remote execution. This
because, if the remote system is down, a direct
command will fail, and the article will never
delivered. If the article is spooled, it will
be delivered when both systems are up

4.2 Transfer by

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

- 14 -

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

A solution to this problem is to encapsulate the
article into a mail message, such that the entire
(headers and body) are part of the body of the
message. The convention here is that such mail is sent
user "rnews" on the remote system. A mail message
is generated by prepending the letter "N" to each
of the news article, and then attaching whatever
headers are convenient to generate. The N's are
to prevent any special lines in the news article
interfering with mail transmission, and to prevent
extra lines inserted by the mailer (headers, blank lines
etc.) from becoming part of the news article. A
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
From: news@cbosgd.
Subject: network news
To: rnews@npois.

NRelay-Version: B 2.10 2/13/83 cbosgd.
NPosting-Version: B 2.9 6/21/82 sask.
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!
NFrom: derek@sask.UUCP (Derek Andrew
NNewsgroups: net.
NSubject: necessary
NMessage-ID: <176@sask.UUCP
NDate: Monday, 3-Jan-83 00:59:15

NThis really is a test. If anyone out there more than 6
Nhops away would kindly confirm this note I
Nappreciate it. We suspect that our news
Nare not getting out into the world

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

- 15 -

4.3

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

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

##! rnews 1234

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

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

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

There was something I forgot to mention in the last message

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

- 16 -

5. The News Propagation

This section describes the overall scheme of USENET
the algorithm followed by sites in propagating news to
entire network. Since all sites are affected
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
host computer, each arc in the graph is a
path from one host to another host. Each arc is
with a newsgroup pattern, specifying which
classes are forwarded along that link. Most arcs
bidirectional, that is, if site A sends a class
newsgroups to site B, then site B usually sends the
class of newsgroups to site A. This bidirectionality
not, however, required

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

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

An important part of the algorithm is the prevention
loops. The above process would cause a message to
along a cycle forever. In particular, when site A
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
this is the history mechanism. Each site keeps track
all articles it has seen (by their message ID)
whenever an article comes in that it has already seen,
incoming article is discarded immediately. This
is sufficient to prevent loops, but
optimizations can be made to avoid sending articles
sites that will simply throw them away

- 17 -

One optimization is that an article should never be
to a machine listed in the Path line of the header.
a machine name is in the Path line, the message is
to have passed through the machine. Another
is that, if the article originated on site A, then site
has already seen the article. (Origination can
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
metasymbol that matches any string), and will be
to all sites that subscribe to net.all (as determined
what their neighbors send them). These sites make up
"net" subnetwork. An article posted to "btl.general"
will reach all sites receiving "btl.all", but will
reach sites that do not get "btl.all". In effect,
articles reaches the "btl" subnetwork. An
posted to newsgroups "net.micro,btl.general" will
all sites subscribing to either of the two classes

- 18 -

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX