.\" Copyright (c) 1986 The Regents of the University of California.
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" @(#)standard.mn 5.2 (Berkeley) 4/17/91
.ds h0 "Standard for Interchange of USENET Messages
Standard for Interchange of USENET Messages
Revised for 2.10.3 by Rick Adams
This document defines the standard format for the interchange
of network Nnws 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,
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.
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.
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.
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.
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.
From: jerry@eagle.uucp (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19 Nov 82 16:14:55 EST
Expires: Saturday, 1 Jan 83 00:00:00 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)
Title: Usenet Etiquette -- Please Read
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
cbosgd!mhuxj!mhuxt!eagle!jerry
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,
and some additional information.
This is a subset of the ARPANET standard,
simplified to allow simpler software to handle it.
line may optionally include a full name,
or use the ARPANET angle bracket syntax.
To keep the implementations simple,
with part of the machine address after the close parenthesis)
The ARPANET convention of continuation header lines
(beginning with a blank or tab)
Certain headers are required,
and certain other headers are optional.
Any unrecognized headers are allowed,
and will be passed through unchanged.
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,
after the electronic address.
The electronic address is the same as the entity responsible
for originating the article,
header might not be verified.
Note that in all site and domain names,
upper and lower case are considered the same,
User names may or may not be case sensitive, for example,
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
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.
the three permissible forms are:
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
\&\*(lq(\*(rq (left parenthesis),
\&\*(lq)\*(rq (right parenthesis),
\&\*(lq<\*(rq (left angle bracket),
or \*(lq>\*(rq (right angle bracket).
Additional restrictions may be placed on full names by the mail standard,
and \*(lq;\*(rq (semicolon) are inadvisable in full names.
in a format that must be acceptable both to the ARPANET
that the article was originally posted to the network.
This date remains unchanged as the article is propagated
One format that is acceptable to both is
\f2Wdy\fP, \f2DD\fP\ \f2Mon\fP\ \f2YY\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2TIMEZONE\fP
Several examples of valid dates appear in the sample
\f2Wdy\fP \f2Mon\fP \f2DD\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2YYYY\fP
acceptable because it is not a valid ARPANET date.
since older software still generates this format,
news implementations are encouraged to accept this format
and translate it into an acceptable format.
field is currently subject to revision.
we hope to accept all possible worldwide time zone abbreviations,
including the usual American zones
the other North American zones
(Bering through Newfoundland),
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)
It is recommended that times in message headers be transmitted in GMT
and displayed in the local time zone.
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.
although a newsgroup name
If an article is received with a
line listing some valid newsgroups and some invalid newsgroups,
a site should not remove invalid newsgroups from the list.
the invalid newsgroups should be ignored.
subscribes to the classes
and exchanges news articles with site
Newsgroups: net.micro,btl.general
This article is passed on to
the edited header could eventually reenter the
resulting in an article that is not shown to users subscribing to
would not be shown to such users.
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
the default subject should begin with the four characters \*(lqRe: \*(rq
(The user might wish to edit the subject of the followup,
but the default should begin with \*(lqRe: \*(rq.)
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
<\f2string not containing blank or \*(lq>\*(rq\fP>
In order to conform to RFC 822,
the message ID must have the format
<\f2unique\fP@\f2full_domain_name\fP>
is the full name of the host at which the article entered the network,
including a domain that host is in,
is any string of printing ASCII characters,
\*(lq<\*(rq (left angle bracket),
\*(lq>\*(rq (right angle bracket),
or \*(lq@\*(rq (at sign).
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.
a valid message ID for an article submitted from site
.cf <4123@ucbvax.Berkeley.EDU> .
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.
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.
in references to the message ID,
the angle brackets are included.
are not allowed in a message ID.
All characters between the angle brackets must be printing ASCII characters.
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
The names may be separated by any punctuation character or characters,
.cf "cbosgd, mhuxj, mhuxt" ,
.cf "@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp"
.cf "teklabs, zehntel, sri-unix@cca!decvax"
(The latter path indicates a message that passed through
Additional names should be added from the left,
the most recently added name in the third example was
periods and hyphens are considered part of site names;
are considered separators.
the rightmost name will be the name of the originating system.
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.
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.
will not immediately send the article back to site
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
will add its own name to the path when it receives the message from
.cf \*(lqB!A!X!Y!Z\*(rq .
then passes the message on to
Special upward compatibility note:
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
header and the reply function.
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.
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,
should be maintained when possible.
This line has the same format as
mailed replies to the author should be sent to the name given here.
replies are mailed to the name on the
(This does not prevent additional copies from being sent to recipients
The full name may be optionally given,
This field is present only if the submitter manually enters a
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.
if John Smith is visiting CCA and wishes to post an article to the network,
using friend Sarah Jones account,
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
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,
This line has the same format as
follow-up articles are to be posted
to the newsgroup or newsgroups listed here.
If this line is not present,
followups are posted to the newsgroup or newsgroups listed in the
is in a legal USENET date format.
It specifies a suggested expiration date for the article.
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.
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,
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
Leave it out and allow local policies to be used
unless there is a good reason not to.
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
line which is the same as the original article,
except that if the original subject does not begin
with \*(lqRe: \*(rq or \*(lqre: \*(rq,
the four characters \*(lqRe: \*(rq are inserted before the subject.
line on the original header,
line should contain the message ID of the original article
(including the angle brackets).
If the original article does have a
the followup article should have a
line containing the text of the original
and the message ID of the original article.
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
line for the benefit of systems that do use it,
and manually generated followups
typed in well after the original article has been printed by the machine)
should be encouraged to include them as well.
the article is a control message.
Control messages are used for communication among USENET host machines,
Control messages are distributed by the same newsgroup mechanism
header line is the message to the host.
For upward compatibility,
messages that match the newsgroup pattern
should also be interpreted as control messages.
header is present on such messages,
the subject is used as the control message.
messages on newsgroups matching this pattern do not conform to this standard.
This line is used to alter the distribution scope of the message.
It has the same format as the
User subscriptions are still controlled by
but the message is sent to all systems subscribing to the newsgroups
a car for sale in New Jersey might have headers including
Newsgroups: net.auto,net.wanted
so that it would only go to persons subscribing to
The intent of this header is to restrict
the distribution of a newsgroup further,
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
Followup articles should default to the same
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.
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.
A few, well selected keywords identifying this article should be on
this line. This is used as an aid in determining if this article is
interesting to the reader.
This line (lines) should contain a brief summary of the article. It is
usually used as part of a followup to another article. Again, it is
very useful to the reader in determining whether to read the article.
This section lists the control messages currently defined.
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;
line might suggest an address to which a response is to be mailed.
Implementors and administrators may choose to allow control messages
to be carried out automatically,
or to queue them for manual processing.
manually processed messages should be dealt with promptly.
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.
If the system is unable to cancel the article as requested, it should not
forward the cancellation request to its neighbor systems.
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
The verified sender of the cancel message must be the same
field of the original message.
A verified sender in the cancel message is allowed to match an unverified
ihave <message ID list> <remotesys>
sendme <message ID list> <remotesys>
This message is part of the
that a particular message has been received on
and wishes to transmit the article to site
sends the control message
.cf "ihave ucbvax.1234 A"
(by posting it to newsgroup
responds with the control message
.cf "sendme ucbvax.1234 B"
if it has not already received the article.
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.
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
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,
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.
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.
listing all neighbors and which newsgroups are sent to each neighbor,
will be mailed to the author of the control message
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,
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
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.
From cbosgd!mark Sun Mar 27 20:39:37 1983
Subject: response to your sendsys request
Responding-System: cbosgd.UUCP
cbosgd:osg,cb,btl,bell,net,to,test
cbosg:net,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:net,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
npois:net,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:net,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
senduuname (no arguments)
and the output is mailed to the author of the control message
This program lists all UUCP neighbors of the local site.
This information is used to make maps of the UUCP network.
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
(or in some other way determine the UUCP neighbors)
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
as the reply is considered to be in the public domain.
program will send only the site name and not the entire contents of the
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
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,
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 publicize.
The name and version of the software running on the local system
is to be mailed back to the author of the article
USENET is not a physical network,
but rather a logical network
resting on top of several existing physical networks.
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.
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.
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
but this field is not guaranteed to be a working path for replies.
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.
Some networks permit direct remote command execution.
news may be forwarded by spooling the
command with the article on the standard input.
if the remote system is called
news would be sent over a UUCP link with the command
It is important that the article be sent via a reliable mechanism,
normally involving the possibility of spooling,
rather than direct real-time remote execution.
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.
direct remote spooled execution is not possible.
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.
this mail is sent to the user
One problem with this method is that it may not be possible to convince
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
such that the entire article
are part of the body of the mail message.
The convention here is that such mail is sent to user
A mail message body is generated by prepending the letter
to each line of the news article,
and then attaching whatever mail headers are convenient to generate.
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
from becoming part of the news article.
A program on the receiving machine receives mail to
extracting the article itself and invoking the
An example in this format might look like this:
Date: Monday, 3-Jan-83 08:33:47 MST
Subject: network news article
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NMessage-ID: <176@sask.UUCP>
NDate: Monday, 3 Jan 83 00:59:15 MST
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.
Using mail solves the spooling problem,
since mail must always be spooled if the destination host is down.
it adds more overhead to the transmission process
(to encapsulate and extract the article)
and makes it harder for software to give different priorities
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:
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
.qc "CARRIAGE RETURN\s+2><\s-2LINE FEED" \&.)
a batch of articles might look like this:
From: jerry@eagle.uucp (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
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.
From: jerry@eagle.uucp (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
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.
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,
and 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,
sends a class of newsgroups to site
usually sends the same class of newsgroups to site
This bidirectionality is not,
USENET is made up of many subnetworks.
although the union of all subnets may be a superset of USENET
(because of sites that get local newsgroup classes but do not get
Each subnet is a connected graph,
a path exists from every node to every other node in the subnet.
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.
to be \*(lqinterested\*(rq in a newsgroup
if the newsgroup matches the pattern on the arc from
This pattern is stored in a file on the
The sites receiving the incoming article examine it
to make sure they really want the article,
and then in turn forward the article to all
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.
will send it back to site
which will send it to site
One solution to this is the history mechanism.
Each site keeps track of all articles it has seen
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
When a machine name is in the
the message is known to have passed through the machine.
Another optimization is that,
if the article originated on site
has already seen the article.
(Origination can be determined by the
if an article is posted to newsgroup
it will match the pattern
is a metasymbol that matches any string),
and will be forwarded to all sites that subscribe to
(as determined by what their neighbors send them).
will reach all sites receiving
but will not reach sites that do not get
An article posted to newsgroups
.ng net.micro,btl.general
will reach all sites subscribing to either of the two classes.