RFC relevance of internet

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

Network Working Group M.
Request for Comments: 1036 AT&T Bell
Obsoletes: RFC-850 R.
Center for Seismic
December 1987

Standard for Interchange of USENET

STATUS OF THIS

This document defines the standard format for the interchange
network News messages among USENET hosts. It updates and
RFC-850, reflecting version B2.11 of the News program. This memo
disributed as an RFC to make this information easily accessible
the Internet community. It does not specify an Internet standard
Distribution of this memo is unlimited

1.

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

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

2. Message

The primary consideration in choosing a message format is that
fit in with existing tools as well as possible. Existing
include implementations of both mail and news. (The
system from the University of Illinois is considered a
implementation.) A standard format for mail messages has
for many years on the Internet, and this format meets most of
needs of USENET. Since the Internet format is extensible
extensions to meet the additional needs of USENET are easily
within the Internet standard. Therefore, the rule is adopted
all USENET news messages must be formatted as valid Internet
messages, according to the Internet standard RFC-822. The
News standard is more restrictive than the Internet standard

Horton & Adams [Page 1]

RFC 1036 Standard for USENET Messages December 1987

placing additional requirements on each message and forbidding
of certain Internet features. However, it should always be
to use a tool expecting an Internet message to process a
message. In any situation where this standard conflicts with
Internet standard, RFC-822 should be considered correct and
standard in error

Here is an example USENET message to illustrate the fields

From: jerry@eagle.ATT.COM (Jerry Schwarz
Path: cbosgd!mhuxj!mhuxt!eagle!
Newsgroups: news.
Subject: Usenet Etiquette -- Please
Message-ID: <642@eagle.ATT.COM
Date: Fri, 19 Nov 82 16:14:55
Followup-To: news.
Expires: Sat, 1 Jan 83 00:00:00 -0500
Organization: AT&T Bell Laboratories, Murray

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

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

From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz
Newsgroups: news.
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 message comes here, after a blank line

Some news systems transmit news in the A format, which looks
this

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

A standard USENET message consists of several header lines,
by a blank line, followed by the body of the message. Each

Horton & Adams [Page 2]

RFC 1036 Standard for USENET Messages December 1987

line consist of a keyword, a colon, a blank, and some
information. This is a subset of the Internet standard,
to allow simpler software to handle it. The "From" line
optionally include a full name, in the format above, or use
Internet angle bracket syntax. To keep the implementations simple
other formats (for example, with part of the machine address
the close parenthesis) are not allowed. The Internet convention
continuation header lines (beginning with a blank or tab)
allowed

Certain headers are required, and certain other headers
optional. Any unrecognized headers are allowed, and will be
through unchanged. The required header lines are "From", "Date",
"Newsgroups", "Subject", "Message-ID", and "Path". The
header lines are "Followup-To", "Expires", "Reply-To", "Sender",
"References", "Control", "Distribution", "Keywords", "Summary",
"Approved", "Lines", "Xref", and "Organization". Each of
header lines will be described below

2.1. Required Header

2.1.1.

The "From" line contains the electronic mailing address of
person who sent the message, in the Internet syntax. It
optionally also contain the full name of the person, in parentheses
after the electronic address. The electronic address is the same
the entity responsible for originating the message, unless
"Sender" header is present, in which case the "From" header
not be verified. Note that in all host and domain names, upper
lower case are considered the same, thus "mark@cbosgd.ATT.COM",
"mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent
User names may or may not be case sensitive, for example
"Billy@cbosgd.ATT.COM" might be different
"BillY@cbosgd.ATT.COM". Programs should avoid changing the case
electronic addresses when forwarding news or mail

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

Horton & Adams [Page 3]

RFC 1036 Standard for USENET Messages December 1987

From: mark@cbosgd.ATT.
From: mark@cbosgd.ATT.COM (Mark Horton
From: Mark Horton
Full names may contain any printing ASCII characters from
through tilde, except that they may not contain "(" (
parenthesis), ")" (right parenthesis), "<" (left angle bracket),
">" (right angle bracket). Additional restrictions may be placed
full names by the mail standard, in particular, the characters ","
(comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
(equal), and ";" (semicolon) are inadvisable in full names

2.1.2.

The "Date" line (formerly "Posted") is the date that the message
originally posted to the network. Its format must be
both in RFC-822 and to the getdate(3) routine that is provided
the Usenet software. This date remains unchanged as the message
propagated throughout the network. One format that is acceptable
both is

Wdy, DD Mon YY HH:MM:SS

Several examples of valid dates appear in the sample message above
Note in particular that ctime(3) format

Wdy Mon DD HH:MM:SS

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

There is no hope of having a complete list of timezones.
Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST
CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should
supported. It is recommended that times in message headers
transmitted in GMT and displayed in the local time zone

2.1.3.

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

Horton & Adams [Page 4]

RFC 1036 Standard for USENET Messages December 1987

Wildcards (e.g., the word "all") are never allowed in a "News
groups" line. For example, a newsgroup comp.all is illegal
although a newsgroup rec.sport.football is permitted

If a message is received with a "Newsgroups" line listing some
newsgroups and some invalid newsgroups, a host should not
invalid newsgroups from the list. Instead, the invalid
should be ignored. For example, suppose host A subscribes to
classes btl.all and comp.all, and exchanges news messages with
B, which subscribes to comp.all but not btl.all. Suppose A
a message with Newsgroups: comp.unix,btl.general

This message is passed on to B because B receives comp.unix, but
does not receive btl.general. A must leave the "Newsgroups"
unchanged. If it were to remove btl.general, the edited
could eventually re-enter the btl.all class, resulting in a
that is not shown to users subscribing to btl.general. Also
follow-ups from outside btl.all would not be shown to such users

2.1.4.

The "Subject" line (formerly "Title") tells what the message
about. It should be suggestive enough of the contents of
message to enable a reader to make a decision whether to read
message based on the subject alone. If the message is submitted
response to another message (e.g., is a follow-up) the
subject should begin with the four characters "Re:", and
"References" line is required. For follow-ups, the use of
"Summary" line is encouraged

2.1.5. Message-

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

containing blank or ">">

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

where full_domain_name is the full name of the host at which
message entered the network, including a domain that host is in,
unique is any string of printing ASCII characters, not including "<"
(left angle bracket), ">" (right angle bracket), or "@" (at sign).

Horton & Adams [Page 5]

RFC 1036 Standard for USENET Messages December 1987

For example, the unique part could be an integer representing
sequence number for messages submitted to the network, or a
string derived from the date and time the message was created.
example, a valid Message-ID for a message submitted from host
in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
Programmers are urged not to make assumptions about the content
Message-ID fields from other hosts, but to treat them as
character strings. It is not safe, for example, to assume that
Message-ID will be under 14 characters, that it is unique in
first 14 characters, nor that is does not contain a "/".

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

2.1.6.

This line shows the path the message took to reach the
system. When a system forwards the message, it should add its
name to the list of systems in the "Path" line. The names may
separated by any punctuation character or characters (except "."
which is considered part of the hostname). Thus, the following
valid entries

cbosgd!mhuxj!
cbosgd, mhuxj,
@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.
teklabs, zehntel, sri-unix@cca!

(The latter path indicates a message that passed through decvax
cca, sri-unix, zehntel, and teklabs, in that order.)
names should be added from the left. For example, the most
added name in the fourth example was teklabs. Letters, digits
periods and hyphens are considered part of host names;
punctuation, including blanks, are considered separators

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

The "Path" line is not used for replies, and should not be taken
a mailing address. It is intended to show the route the
traveled to reach the local host. There are several uses for
information. One is to monitor USENET routing for

Horton & Adams [Page 6]

RFC 1036 Standard for USENET Messages December 1987

reasons. Another is to establish a path to reach new hosts
Perhaps the most important use is to cut down on redundant
traffic by failing to forward a message to a host that is known
have already received it. In particular, when host A sends
message to host B, the "Path" line includes A, so that host B
not immediately send the message back to host A. The name each
uses to identify itself should be the same as the name by which
neighbors know it, in order to make this optimization possible

A host adds its own name to the front of a path when it receives
message from another host. Thus, if a message with path "A!X!Y!Z
is passed from host A to host B, B will add its own name to the
when it receives the message from A, e.g., "B!A!X!Y!Z". If B
passes the message on to C, the message sent to C will contain
path "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",
"Reply-To" lines are in Internet format, and since many USENET
do not yet have mailers capable of understanding Internet format,
would break the reply capability to completely sever the
between the "Path" header and the reply function. It is
that the path is not always a valid reply string in
implementations, and no requirement to fix this problem is placed
implementations. However, the existing convention of placing
host name and an "!" at the front of the path, and of starting
path with the host name, an "!", and the user name, should
maintained when possible

2.2. Optional

2.2.1. Reply-

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

2.2.2.

This field is present only if the submitter manually enters a "From
line. It is intended to record the entity responsible
submitting the message to the network. It should be verified by
software at the submitting host

Horton & Adams [Page 7]

RFC 1036 Standard for USENET Messages December 1987

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

From: smith@ucbvax.Berkeley.EDU (John Smith
Sender: jones@cca.COM (Sarah Jones

If a gateway program enters a mail message into the network at
unix.SRI.COM, the lines might read

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

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

2.2.3. Followup-

This line has the same format as "Newsgroups". If present, follow
up messages are to be posted to the newsgroup or newsgroups
here. If this line is not present, follow-ups are posted to
newsgroup or newsgroups listed in the "Newsgroups" line

If the keyword poster is present, follow-up messages are
permitted. The message should be mailed to the submitter of
message via mail

2.2.4.

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

Horton & Adams [Page 8]

RFC 1036 Standard for USENET Messages December 1987

2.2.5.

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

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

It is permissible to not include the entire previous "References
line if it is too long. An attempt should be made to include
reasonable number of backwards references

2.2.6.

If a message contains a "Control" line, the message is a
message. Control messages are used for communication among
host machines, not to be read by users. Control messages
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
"all.all.ctl" should also be interpreted as control messages. If
"Control" header is present on such messages, the subject is used
the control message. However, messages on newsgroups matching
pattern do not conform to this standard

Horton & Adams [Page 9]

RFC 1036 Standard for USENET Messages December 1987

Also for upward compatibility, if the first 4 characters of
"Subject:" line are "cmsg", the rest of the "Subject:" line
be interpreted as a control message

2.2.7.

This line is used to alter the distribution scope of the message
It is a comma separated list similar to the "Newsgroups" line.
subscriptions are still controlled by "Newsgroups", but the
is sent to all systems subscribing to the newsgroups on
"Distribution" line in addition to the "Newsgroups" line. For
message to be transmitted, the receiving site must normally
one of the specified newsgroups AND must receive one of
specified distributions. Thus, a message concerning a car for
in New Jersey might have headers including

Newsgroups: rec.auto,misc.
Distribution: nj,

so that it would only go to persons subscribing to rec.auto or misc
for sale within New Jersey or New York. The intent of this
is to restrict the distribution of a newsgroup further, not
increase it. A local newsgroup, such as nj.crazy-eddie,
probably not be propagated by hosts outside New Jersey that do
show such a newsgroup as valid. A follow-up message should
to the same "Distribution" line as the original message, but
user can change it to a more limited one, or escalate
distribution if it was originally restricted and a more
distributed reply is appropriate

2.2.8.

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

2.2.9.

A few well-selected keywords identifying the message should be
this line. This is used as an aid in determining if this message
interesting to the reader

2.2.10.

This line should contain a brief summary of the message. It
usually used as part of a follow-up to another message. Again,

Horton & Adams [Page 10]

RFC 1036 Standard for USENET Messages December 1987

is very useful to the reader in determining whether to read
message

2.2.11.

This line is required for any message posted to a
newsgroup. It should be added by the moderator and consist of
mail address. It is also required with certain control messages

2.2.12.

This contains a count of the number of lines in the body of
message

2.2.13.

This line contains the name of the host (with domains omitted) and
white space separated list of colon-separated pairs of
names and message numbers. These are the newsgroups listed in
"Newsgroups" line and the corresponding message numbers from
spool directory

This is only of value to the local system, so it should not
transmitted. For example, in

Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!
From: reid@decwrl.DEC.COM (Brian Reid
Newsgroups: news.lists,news.
Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
Message-ID: <5658@decwrl.DEC.COM
Date: 1 Oct 86 11:26:15
Organization: DEC Western Research
Lines: 441
Approved: reid@decwrl.
Xref: seismo news.lists:461 news.groups:6378

the "Xref" line shows that the message is message number 461 in
newsgroup news.lists, and message number 6378 in the
news.groups, on host seismo. This information may be used
certain user interfaces

3. Control

This section lists the control messages currently defined. The
of the "Control" header line is the control message. Messages are
sequence of zero or more words, separated by white space (blanks
tabs). The first word is the name of the control message,
words are parameters to the message. The remainder of the

Horton & Adams [Page 11]

RFC 1036 Standard for USENET Messages December 1987

and the body of the message are also potential parameters;
example, the "From" line might suggest an address to which
response is to be mailed

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

Failed control messages should NOT be mailed to the originator
the message, but to the local "usenet" account

3.1.

cancel

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

If the system is unable to cancel the message as requested,
should not forward the cancellation request to its neighbor systems

Only the author of the message or the local news administrator
allowed to send this message. The verified sender of a message
the "Sender" line, or if no "Sender" line is present, the "From
line. The verified sender of the cancel message must be the same
either the "Sender" or "From" field of the original message.
verified sender in the cancel message is allowed to match
unverified "From" in the original message

3.2. Ihave/

ihave []
sendme []

This message is part of the ihave/sendme protocol, which allows
host (say A) to tell another host (B) that a particular message
been received on A. Suppose that host A receives
"<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message
host B

A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A"
host B (by posting it to newsgroup to.B). B responds with
control message "sendme <1234@ucbvax.Berkeley.edu> B" (on
to.A), if it has not already received the message. Upon

Horton & Adams [Page 12]

RFC 1036 Standard for USENET Messages December 1987

the sendme message, A sends the message to B

This protocol can be used to cut down on redundant traffic
hosts. It is optional and should be used only if the
situation makes it worthwhile. Frequently, the outcome is that
since most original messages are short, and since there is a
overhead to start sending a new message with UUCP, it costs as
to send the ihave as it would cost to send the message 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
the message should be scanned for Message-ID's, one per line

3.3.

newgroup [moderated

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

If the second argument is present and it is the keyword moderated
the group should be created moderated instead of the default
unmoderated. The newgroup message should be ignored unless there
an "Approved" line in the same message header

3.4.

rmgroup
This message removes a newsgroup with the given name. Since
newsgroup is removed from every host on the network, this
should be used carefully by a responsible administrator.
rmgroup message should be ignored unless there is an "Approved:"
line in the same message header

Horton & Adams [Page 13]

RFC 1036 Standard for USENET Messages December 1987

3.5.
sendsys (no arguments

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

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

From: cbosgd!mark (Mark Horton
Date: Sun, 27 Mar 83 20:39:37 -0500
Subject: response to your sendsys
To: mark@cbosgd.ATT.

Responding-System: cbosgd.ATT.
cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to

ucbvax:world,comp,to.ucbvax:L
cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/
/
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/
sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/
/
npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/
mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/

3.6.

version (no arguments

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

3.7.

Horton & Adams [Page 14]

RFC 1036 Standard for USENET Messages December 1987

The message body is a list of "official" newsgroups and
description, one group per line. They are compared against the
of active newsgroups on the current host. The names of any
or new newsgroups are mailed to the user "usenet" and
of the new newsgroups are added to the help file used when
news

4. Transmission

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

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

4.1. Remote

Some networks permit direct remote command execution. On
networks, news may be forwarded by spooling the rnews command
the message on the standard input. For example, if the
system is called remote, news would be sent over a UUCP
with the command

uux - remote!

and on a Berknet

net -mremote

Horton & Adams [Page 15]

RFC 1036 Standard for USENET Messages December 1987

It is important that the message be sent via a reliable mechanism
normally involving the possibility of spooling, rather than
real-time remote execution. This is because, if the remote
is down, a direct execution command will fail, and the message
never be delivered. If the message is spooled, it will
be delivered when both systems are up

4.2. Transfer by

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

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

A solution to this problem is to encapsulate the news message into
mail message, such that the entire message (headers and body)
part of the body of the mail message. The convention here is
such mail is sent to user rnews on the remote system. A
message body is generated by prepending the letter N to each line
the news message, and then attaching whatever mail headers
convenient to generate. The N's are attached to prevent any
lines in the news message 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 message.
program on the receiving machine receives mail to rnews,
the message itself and invoking the rnews program. An example
this format might look like this

Horton & Adams [Page 16]

RFC 1036 Standard for USENET Messages December 1987

Date: Mon, 3 Jan 83 08:33:47
From: news@cbosgd.ATT.
Subject: network news
To: rnews@npois.ATT.

NPath: cbosgd!mhuxj!harpo!utah-cs!sask!
NFrom: derek@sask.UUCP (Derek Andrew
NNewsgroups: misc.
NSubject: necessary
NMessage-ID: <176@sask.UUCP
NDate: Mon, 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 must always
spooled if the destination host is down. However, it adds
overhead to the transmission process (to encapsulate and extract
message) and makes it harder for software to give
priorities to news and mail

4.3.

Since news messages are usually short, and since a large number
messages are often sent between two hosts in a day, it may
sense to batch news messages. Several messages can be combined
one large message, using conventions agreed upon in advance by
two hosts. One such batching scheme is described here; its use
highly recommended

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

#! rnews 1234

where 1234 is the length of the message in bytes. Each such line
followed by a message containing the given number of bytes. (
newline at the end of each line of the message is counted as
byte, for purposes of this count, even if it is stored as <
RETURN>.) For example, a batch of message might
like this

Horton & Adams [Page 17]

RFC 1036 Standard for USENET Messages December 1987

#! rnews 239
From: jerry@eagle.ATT.COM (Jerry Schwarz
Path: cbosgd!mhuxj!mhuxt!eagle!
Newsgroups: news.
Subject: Usenet Etiquette -- Please
Message-ID: <642@eagle.ATT.COM
Date: Fri, 19 Nov 82 16:14:55
Approved: mark@cbosgd.ATT.

Here is an important message about USENET Etiquette
#! rnews 234
From: jerry@eagle.ATT.COM (Jerry Schwarz
Path: cbosgd!mhuxj!mhuxt!eagle!
Newsgroups: news.
Subject: Notes on Etiquette
Message-ID: <643@eagle.ATT.COM
Date: Fri, 19 Nov 82 17:24:12
Approved: mark@cbosgd.ATT.

There was something I forgot to mention in the
message

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

The second argument (in this example rnews) determines
batching scheme is being used. Cooperating hosts may use
scheme is appropriate for them

5. The News Propagation

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

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

USENET is made up of many subnetworks. Each subnet has a name,

Horton & Adams [Page 18]

RFC 1036 Standard for USENET Messages December 1987

as comp or btl. Each subnet is a connected graph, that is, a
exists from every node to every other node in the subnet.
addition, the entire graph is (theoretically) connected. (
practice, some political considerations have caused some hosts to
unable to post messages reaching the rest of the network.)

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

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

One optimization is that a message should never be sent to a
listed in the "Path" line of the header. When a machine name
in the "Path" line, the message is known to have passed through
machine. Another optimization is that, if the message
on host A, then host A has already seen the message. Thus, if
message is posted to newsgroup misc.misc, it will match the
misc.all (where all is a metasymbol that matches any string),
will be forwarded to all hosts that subscribe to misc.all (
determined by what their neighbors send them). These hosts make
the misc subnetwork. A message posted to btl.general will reach
hosts receiving btl.all, but will not reach hosts that do not
btl.all. In effect, the messages reaches the btl subnetwork.
messages posted to newsgroups misc.misc,btl.general will reach
hosts subscribing to either of the two classes

<1> UNIX is a registered trademark of AT&T

Horton & Adams [Page 19]

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