Amiga-Request@cs.odu.edu (Amiga Sources/Binaries Moderator) (02/04/90)
Submitted-by: overload!dillon (Matt Dillon)
Posting-number: Volume 90, Issue 059
Archive-name: unix/uucp-1.03d/part15
#!/bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 15 (of 16)."
# Contents: man/Standards.aa
# Wrapped by tadguy@xanth on Sat Feb 3 20:51:25 1990
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'man/Standards.aa' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'man/Standards.aa'\"
else
echo shar: Extracting \"'man/Standards.aa'\" \(48305 characters\)
sed "s/^X//" >'man/Standards.aa' <<'END_OF_FILE'
X
X Standard for Interchange of USENET Messages
X
X Mark R. Horton
X
X
X
X
X 1. Introduction
X
X This document defines the standard format for interchange
X of Network News articles among USENET sites. It describes
X the format for articles themselves, and gives partial
X standards for transmission of news. The news transmission
X is not entirely standardized in order to give a good deal
X of flexibility to the individual hosts to choose
X transmission hardware and software, whether to batch news,
X and so on.
X
X There are five sections to this document. Section two
X section defines the format. Section three defines the
X valid control messages. Section four specifies some valid
X transmission methods. Section five describes the overall
X news propagation algorithm.
X
X
X 2. Article Format
X
X The primary consideration in choosing an article format is
X that it fit in with existing tools as well as possible.
X Existing tools include both implementations of mail and
X news. (The notesfiles system from the University of
X Illinois is considered a news implementation.) A standard
X format for mail messages has existed for many years on the
X ARPANET, and this format meets most of the needs of
X USENET. Since the ARPANET format is extensible,
X extensions to meet the additional needs of USENET are
X easily made within the ARPANET standard. Therefore, the
X rule is adopted that all USENET news articles must be
X formatted as valid ARPANET mail messages, according to the
X ARPANET standard RFC 822. This standard is more
X restrictive than the ARPANET standard, placing additional
X requirements on each article and forbidding use of certain
X ARPANET features. However, it should always be possible
X to use a tool expecting an ARPANET message to process a
X news article. In any situation where this standard
X conflicts with the ARPANET standard, RFC 822 should be
X considered correct and this standard in error.
X
X An example message is included to illustrate the fields.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X - 2 -
X
X
X
X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
X From: jerry@eagle.uucp (Jerry Schwarz)
X Newsgroups: net.general
X Subject: Usenet Etiquette -- Please Read
X Message-ID: <642@eagle.UUCP>
X Date: Friday, 19-Nov-82 16:14:55 EST
X Followup-To: net.news
X Expires: Saturday, 1-Jan-83 00:00:00 EST
X Date-Received: Friday, 19-Nov-82 16:59:30 EST
X Organization: Bell Labs, Murray Hill
X
X The body of the article comes here, after a blank line.
X
X Here is an example of a message in the old format (before
X the existence of this standard). It is recommended that
X implementations also accept articles in this format to
X ease upward conversion.
X
X From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
X Newsgroups: net.general
X Title: Usenet Etiquette -- Please Read
X Article-I.D.: eagle.642
X Posted: Fri Nov 19 16:14:55 1982
X Received: Fri Nov 19 16:59:30 1982
X Expires: Mon Jan 1 00:00:00 1990
X
X The body of the article comes here, after a blank line.
X
X Some news systems transmit news in the ``A'' format, which
X looks like this:
X
X Aeagle.642
X net.general
X cbosgd!mhuxj!mhuxt!eagle!jerry
X Fri Nov 19 16:14:55 1982
X Usenet Etiquette - Please Read
X The body of the article comes here, with no blank line.
X
X An article consists of several header lines, followed by a
X blank line, followed by the body of the message. The
X header lines consist of a keyword, a colon, a blank, and
X some additional information. This is a subset of the
X ARPANET standard, simplified to allow simpler software to
X handle it. The ``from'' line may optionally include a
X full name, in the format above, or use the ARPANET angle
X bracket syntax. To keep the implementations simple, other
X formats (for example, with part of the machine address
X after the close parenthesis) are not allowed. The ARPANET
X convention of continuation header lines (beginning with a
X
X
X
X
X
X
X
X
X
X
X
X - 3 -
X
X
X
X blank or tab) is allowed.
X
X Certain headers are required, certain headers are
X optional. Any unrecognized headers are allowed, and will
X be passed through unchanged. The required headers are
X Relay-Version, Posting-Version, From, Date, Newsgroups,
X Subject, Message-ID, Path. The optional headers are
X Followup-To, Date-Received, Expires, Reply-To, Sender,
X References, Control, Distribution, Organization.
X
X 2.1 Required Headers
X
X 2.1.1 Relay-Version This header line shows the version
X of the program responsible for the transmission of this
X article over the immediate link, that is, the program that
X is relaying the article from the next site. For example,
X suppose site A sends an article to site B, and site B
X forwards the article to site C. The message being
X transmitted from A to B would have a Relay-Version header
X identifying the program running on A, and the message
X transmitted from B to C would identify the program running
X on B. This header can be used to interpret older headers
X in an upward compatible way. Relay-Version must always be
X the first in a message; thus, all articles meeting this
X standard will begin with an upper case ``R''. No other
X restrictions are placed on the order of header lines.
X
X The line contains two fields, separated by semicolons.
X The fields are the version and the full domain name of the
X site. The version should identify the system program used
X (e.g., ``B'') as well as a version number and version
X date. For example, the header line might contain
X
X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
X
X This header should not be passed on to additional sites.
X A relay program, when passing an article on, should
X include only its own Relay-Version, not the Relay-Version
X of some other site. (For upward compatibility with older
X software, if a Relay-Version is found in a header which is
X not the first line, it should be assumed to be moved by an
X older version of news and deleted.)
X
X 2.1.2 Posting-Version This header identifies the
X software responsible for entering this message into the
X network. It has the same format as Relay-Version. It
X will normally identify the same site as the Message-ID,
X unless the posting site is serving as a gateway for a
X message that already contains a message ID generated by
X mail. (While it is permissible for a gateway to use an
X externally generated message ID, the message ID should be
X
X
X
X
X
X
X
X
X
X
X
X - 4 -
X
X
X
X checked to ensure it conforms to this standard and to RFC
X 822.)
X
X 2.1.3 From The From line contains the electronic mailing
X address of the person who sent the message, in the ARPA
X internet syntax. It may optionally also contain the full
X name of the person, in parentheses, after the electronic
X address. The electronic address is the same as the entity
X responsible for originating the article, unless the Sender
X header is present, in which case the From header might not
X be verified. Note that in all site and domain names,
X upper and lower case are considered the same, thus
X mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.UUcp
X are all equivalent. User names may or may not be case
X sensitive, for example, Billy@cbosgd.UUCP might be
X different from BillY@cbosgd.UUCP. Programs should avoid
X changing the case of electronic addresses when forwarding
X news or mail.
X
X RFC 822 specifies that all text in parentheses is to be
X interpreted as a comment. It is common in ARPANET mail to
X place the full name of the user in a comment at the end of
X the From line. This standard specifies a more rigid
X syntax. The full name is not considered a comment, but an
X optional part of the header line. Either the full name is
X omitted, or it appears in parentheses after the electronic
X address of the person posting the article, or it appears
X before an electronic address enclosed in angle brackets.
X Thus, the three permissible forms are:
X
X From: mark@cbosgd.UUCP
X From: mark@cbosgd.UUCP (Mark Horton)
X From: Mark Horton <mark@cbosgd.UUCP>
X
X Full names may contain any printing ASCII characters from
X space through tilde, with the exceptions that they may not
X contain parentheses ``('' or ``)'', or angle brackets
X ``<'' or ``>''. Additional restrictions may be placed on
X full names by the mail standard, in particular, the
X characters comma ``,'', colon ``:'', and semicolon ``;''
X are inadvisable in full names.
X
X 2.1.4 Date The Date line (formerly ``Posted'') is the
X date, in a format that must be acceptable both to the
X ARPANET and to the getdate routine, that the article was
X originally posted to the network. This date remains
X unchanged as the article is propagated throughout the
X network. One format that is acceptable to both is
X
X Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
X
X
X
X
X
X
X
X
X
X
X
X
X - 5 -
X
X
X
X Several examples of valid dates appear in the sample
X article above. Note in particular that ctime format:
X
X Wdy Mon DD HH:MM:SS YYYY
X
X is not acceptable because it is not a valid ARPANET date.
X However, since older software still generates this format,
X news implementations are encouraged to accept this format
X and translate it into an acceptable format.
X
X The contents of the TIMEZONE field is currently subject to
X revision. Eventually, we hope to accept all possible
X worldwide time zone abbreviations, including the usual
X American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
X the other North American zones (Bering through
X Newfoundland), European zones, Australian zones, and so
X on. Lacking a complete list at present (and unsure if an
X unambiguous list exists), authors of software are
X encouraged to keep this code flexible, and in particular
X not to assume that time zone names are exactly three
X letters long. Implementations are free to edit this
X field, keeping the time the same, but changing the time
X zone (with an appropriate adjustment to the local time
X shown) to a known time zone.
X
X 2.1.5 Newsgroups The Newsgroups line specifies which
X newsgroup or newsgroups the article belongs in. Multiple
X newsgroups may be specified, separated by a comma.
X Newsgroups specified must all be the names of existing
X newsgroups, as no new newsgroups will be created by simply
X posting to them.
X
X Wildcards (e.g., the word ``all'') are never allowed in a
X Newsgroups line. For example, a newsgroup ``net.all'' is
X illegal, although a newsgroup name ``net.sport.football''
X is permitted.
X
X If an article is received with a Newsgroups line listing
X some valid newsgroups and some invalid newsgroups, a site
X should not remove invalid newsgroups from the list.
X Instead, the invalid newsgroups should be ignored. For
X example, suppose site A subscribes to the classes
X ``btl.all'' and ``net.all'', and exchanges news articles
X with site B, which subscribes to ``net.all'' but not
X ``btl.all''. Suppose A receives an article with
X ``Newsgroups: net.micro,btl.general''. This article is
X passed on to B because B receives net.micro, but B does
X not receive btl.general. A must leave the Newsgroup line
X unchanged. If it were to remove ``btl.general'', the
X edited header could eventually reenter the ``btl.all''
X class, resulting in an article that is not shown to users
X
X
X
X
X
X
X
X
X
X
X
X - 6 -
X
X
X
X subscribing to ``btl.general''. Also, followups from
X outside ``btl.all'' would not be shown to such users.
X
X 2.1.6 Subject The Subject line (formerly ``Title'')
X tells what the article is about. It should be suggestive
X enough of the contents of the article to enable a reader
X to make a decision whether to read the article based on
X the subject alone. If the article is submitted in
X response to another article (e.g., is a ``followup'') the
X default subject should begin with the four characters
X ``Re: '' and the References line is required. (The user
X might wish to edit the subject of the followup, but the
X default should begin with ``Re: ''.)
X
X 2.1.7 Message-ID The Message-ID line gives the article a
X unique identifier. The same message ID may not be reused
X during the lifetime of any article with the same message
X ID. (It is recommended that no message ID be reused for
X at least two years.) Message ID's have the syntax
X
X "<" "string not containing blank or >" ">"
X
X In order to conform to RFC 822, the Message-ID must have
X the format
X
X "<" "unique" "@" "full domain name" ">"
X
X where ``full domain name'' is the full name of the host at
X which the article entered the network, including a domain
X that host is in, and unique is any string of printing
X ASCII characters, not including "<", ">", or "@". For
X example, the "unique" part could be an integer
X representing a sequence number for articles submitted to
X the network, or a short string derived from the date and
X time the article was created. For example, valid message
X ID for an article submitted from site ucbvax in domain
X Berkeley.ARPA would be "<4123@ucbvax.Berkeley.ARPA>".
X Programmers are urged not to make assumptions about the
X content of message ID fields from other hosts, but to
X treat them as unknown character strings. It is not safe,
X for example, to assume that a message ID will be under 14
X characters, nor that it is unique in the first 14
X characters.
X
X The angle brackets are considered part of the message ID.
X Thus, in references to the message ID, such as the
X ihave/sendme and cancel control messages, the angle
X brackets are included. White space characters (e.g.,
X blank and tab) are not allowed in a message ID. All
X characters between the angle brackets must be printing
X ASCII characters.
X
X
X
X
X
X
X
X
X
X
X
X - 7 -
X
X
X
X 2.1.8 Path This line shows the path the article took to
X reach the current system. When a system forwards the
X message, it should add its own name to the list of systems
X in the Path line. The names may be separated by any
X punctuation character or characters, thus
X ``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and
X ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp'' and even
X ``teklabs, zehntel, sri-unix@cca!decvax'' are valid
X entries. (The latter path indicates a message that passed
X through decvax, cca, sri-unix, zehntel, and teklabs, in
X that order.) Additional names should be added from the
X left, for example, the most recently added name in the
X third example was ``teklabs''. Letters, digits, periods
X and hyphens are considered part of site names; other
X punctuation, including blanks, are considered separators.
X
X Normally, the rightmost name will be the name of the
X originating system. However, it is also permissible to
X include an extra entry on the right, which is the name of
X the sender. This is for upward compatibility with older
X system.
X
X The Path line is not used for replies, and should not be
X taken as a mailing address. It is intended to show the
X route the message travelled to reach the local site.
X There are several uses for this information. One is to
X monitor USENET routing for performance reasons. Another
X is to establish a path to reach new sites. Perhaps the
X most important is to cut down on redundant USENET traffic
X by failing to forward a message to a site that is known to
X have already received it. In particular, when site A
X sends an article to site B, the Path line includes ``A'',
X so that site B will not immediately send the article back
X to site A. The site name each site uses to identify
X itself should be the same as the name by which its
X neighbors know it, in order to make this optimization
X possible.
X
X A site adds its own name to the front of a path when it
X receives a message from another site. Thus, if a message
X with path A!X!Y!Z is passed from site A to site B, B will
X add its own name to the path when it receives the message
X from A, e.g., B!A!X!Y!Z. If B then passes the message on
X to C, the message sent to C will contain the path
X B!A!X!Y!Z, and when C receives it, C will change it to
X C!B!A!X!Y!Z.
X
X Special upward compatibility note: Since the From, Sender,
X and Reply-To lines are in internet format, and since many
X USENET sites do not yet have mailers capable of
X understanding internet format, it would break the reply
X
X
X
X
X
X
X
X
X
X
X
X - 8 -
X
X
X
X capability to completely sever the connection between the
X Path header and the reply function. Thus, sites are
X required to continue to keep the Path line in a working
X reply format as much as possible, until January 1, 1984.
X It is recognized that the path is not always a valid reply
X string in older implementations, and no requirement to fix
X this problem is placed on implementations. However, the
X existing convention of placing the site name and an ``!''
X at the front of the path, and of starting the path with
X the site name, an ``!'', and the user name, should be
X maintained at least until 1984.
X
X 2.2 Optional Headers
X
X 2.2.1 Reply-To This line has the same format as From.
X If present, mailed replies to the author should be sent to
X the name given here. Otherwise, replies are mailed to the
X name on the From line. (This does not prevent additional
X copies from being sent to recipients named by the replier,
X or on To or Cc lines.) The full name may be optionally
X given, in parentheses, as in the From line.
X
X 2.2.2 Sender This field is present only if the submitter
X manually enters a From line. It is intended to record the
X entity responsible for submitting the article to the
X network, and should be verified by the software at the
X submitting site.
X
X For example, if John Smith is visiting CCA and wishes to
X post an article to the network, using friend Sarah Jones
X account, the message might read
X
X From: smith@ucbvax.uucp (John Smith)
X Sender: jones@cca.arpa (Sarah Jones)
X
X If a gateway program enters a mail message into the
X network at site sri-unix, the lines might read
X
X From: John.Doe@CMU-CS-A.ARPA
X Sender: network@sri-unix.ARPA
X
X The primary purpose of this field is to be able to track
X down articles to determine how they were entered into the
X network. The full name may be optionally given, in
X parentheses, as in the From line.
X
X 2.2.3 Followup-To This line has the same format as
X Newsgroups. If present, follow-up articles are to be
X posted to the newsgroup(s) listed here. If this line is
X not present, followups are posted to the newsgroup(s)
X listed in the Newsgroups line, except that followups to
X
X
X
X
X
X
X
X
X
X
X
X - 9 -
X
X
X
X ``net.general'' should instead go to ``net.followup''.
X
X 2.2.4 Date-Received This line (formerly ``Received'') is
X in a legal USENET date format. It records the date and
X time that the article was first received on the local
X system. If this line is present in an article being
X transmitted from one host to another, the receiving host
X should ignore it and replace it with the current date.
X Since this field is intended for local use only, no site
X is required to support it. However, no site should pass
X this field on to another site unchanged.
X
X 2.2.5 Expires This line, if present, is in a legal
X USENET date format. It specifies a suggested expiration
X date for the article. If not present, the local default
X expiration date is used.
X
X This field is intended to be used to clean up articles
X with a limited usefulness, or to keep important articles
X around for longer than usual. For example, a message
X announcing an upcoming seminar could have an expiration
X date the day after the seminar, since the message is not
X useful after the seminar is over. Since local sites have
X local policies for expiration of news (depending on
X available disk space, for instance), users are discouraged
X from providing expiration dates for articles unless there
X is a natural expiration date associated with the topic.
X System software should almost never provide a default
X Expires line. Leave it out and allow local policies to be
X used unless there is a good reason not to.
X
X 2.2.6 References This field lists the message ID's of
X any articles prompting the submission of this article. It
X is required for all follow-up articles, and forbidden when
X a new subject is raised. Implementations should provide a
X follow-up command, which allows a user to post a follow-up
X article. This command should generate a Subject line
X which is the same as the original article, except that if
X the original subject does not begin with ``Re: '' or ``re:
X '', the four characters ``Re: '' are inserted before the
X subject. If there is no References line on the original
X header, the References line should contain the message ID
X of the original article (including the angle brackets).
X If the original article does have a References line, the
X followup article should have a References line containing
X the text of the original References line, a blank, and the
X message ID of the original article.
X
X The purpose of the References header is to allow articles
X to be grouped into conversations by the user interface
X program. This allows conversations within a newsgroup to
X
X
X
X
X
X
X
X
X
X
X
X - 10 -
X
X
X
X be kept together, and potentially users might shut off
X entire conversations without unsubscribing to a newsgroup.
X User interfaces may not make use of this header, but all
X automatically generated followups should generate the
X References line for the benefit of systems that do use it,
X and manually generated followups (e.g. typed in well after
X the original article has been printed by the machine)
X should be encouraged to include them as well.
X
X 2.2.7 Control If an article contains a Control line, the
X article is a control message. Control messages are used
X for communication among USENET host machines, not to be
X read by users. Control messages are distributed by the
X same newsgroup mechanism as ordinary messages. The body
X of the Control header line is the message to the host.
X
X For upward compatibility, messages that match the
X newsgroup pattern ``all.all.ctl'' should also be
X interpreted as control messages. If no Control: header is
X present on such messages, the subject is used as the
X control message. However, messages on newsgroups matching
X this pattern do not conform to this standard.
X
X 2.2.8 Distribution This line is used to alter the
X distribution scope of the message. It has the same format
X as the Newsgroups line. User subscriptions are still
X controlled by Newsgroups, but the message is sent to all
X systems subscribing to the newsgroups on the Distribution
X line instead of the Newsgroups line. Thus, a car for sale
X in New Jersey might have headers including
X
X Newsgroups: net.auto,net.wanted
X Distribution: nj.all
X
X so that it would only go to persons subscribing to
X net.auto or net.wanted within New Jersey. The intent of
X this header is to further restrict the distribution of a
X newsgroup, not to increase it. A local newsgroup, such as
X nj.crazy-eddie, will probably not be propagated by sites
X outside New Jersey that do not show such a newsgroup as
X valid. Wildcards in newsgroup names in the Distribution
X line are allowed. Followup articles should default to the
X same Distribution line as the original article, but the
X user can change it to a more limited one, or escalate the
X distribution if it was originally restricted and a more
X widely distributed reply is appropriate.
X
X 2.2.9 Organization The text of this line is a short
X phrase describing the organization to which the sender
X belongs, or to which the machine belongs. The intent of
X this line is to help identify the person posting the
X
X
X
X
X
X
X
X
X
X
X
X - 11 -
X
X
X
X message, since site names are often cryptic enough to make
X it hard to recognize the organization by the electronic
X address.
X
X
X 3. Control Messages
X
X This section lists the control messages currently defined.
X The body of the Control header is the control message.
X Messages are a sequence of zero or more words, separated
X by white space (blanks or tabs). The first word is the
X name of the control message, remaining words are
X parameters to the message. The remainder of the header
X and the body of the message are also potential parameters;
X for example, the From line might suggest an address to
X which a response is to be mailed.
X
X Implementors and administrators may choose to allow
X control messages to be automatically carried out, or to
X queue them for manual processing. However, manually
X processed messages should be dealt with promptly.
X
X 3.1 Cancel
X
X cancel <message ID>
X
X If an article with the given message ID is present on the
X local system, the article is cancelled. This mechanism
X allows a user to cancel an article after the article has
X been distributed over the network.
X
X Only the author of the article or the local super user is
X allowed to use this message. The verified sender of a
X message is the Sender line, or if no Sender line is
X present, the From line. The verified sender of the cancel
X message must be the same as either the Sender or From
X field of the original message. A verified sender in the
X cancel message is allowed to match an unverified From in
X the original message.
X
X 3.2 Ihave/Sendme
X
X ihave <message ID list> <remotesys>
X sendme <message ID list> <remotesys>
X
X This message is part of the ``ihave/sendme'' protocol,
X which allows one site (say ``A'') to tell another site
X (``B'') that a particular message has been received on A.
X Suppose that site A receives article ``ucbvax.1234'', and
X wishes to transmit the article to site B. A sends the
X control message ``ihave ucbvax.1234 A'' to site B (by
X
X
X
X
X
X
X
X
X
X
X
X - 12 -
X
X
X
X posting it to newsgroup ``to.B''). B responds with the
X control message ``sendme ucbvax.1234 B'' (on newsgroup
X to.A) if it has not already received the article. Upon
X receiving the Sendme message, A sends the article to B.
X
X This protocol can be used to cut down on redundant traffic
X between sites. It is optional and should be used only if
X the particular situation makes it worthwhile. Frequently,
X the outcome is that, since most original messages are
X short, and since there is a high overhead to start sending
X a new message with UUCP, it costs as much to send the
X Ihave as it would cost to send the article itself.
X
X One possible solution to this overhead problem is to batch
X requests. Several message ID's may be announced or
X requested in one message. If no message ID's are listed
X in the control message, the body of the message should be
X scanned for message ID's, one per line.
X
X 3.3 Newgroup
X
X newgroup <groupname>
X
X This control message creates a new newsgroup with the name
X given. Since no articles may be posted or forwarded until
X a newsgroup is created, this message is required before a
X newsgroup can be used. The body of the message is
X expected to be a short paragraph describing the intended
X use of the newsgroup.
X
X 3.4 Rmgroup
X
X rmgroup <groupname>
X
X This message removes a newsgroup with the given name.
X Since the newsgroup is removed from every site on the
X network, this command should be used carefully by a
X responsible administrator.
X
X 3.5 Sendsys
X
X sendsys (no arguments)
X
X The ``sys'' file, listing all neighbors and which
X newsgroups are sent to each neighbor, will be mailed to
X the author of the control message (Reply-to, if present,
X otherwise From). This information is considered public
X information, and it is a requirement of membership in
X USENET that this information be provided on request,
X either automatically in response to this control message,
X or manually, by mailing the requested information to the
X
X
X
X
X
X
X
X
X
X
X
X - 13 -
X
X
X
X author of the message. This information is used to keep
X the map of USENET up to date, and to determine where
X netnews is sent.
X
X The format of the file mailed back to the author should be
X the same as that of the ``sys'' file. This format has one
X line per neighboring site (plus one line for the local
X site), containing four colon separated fields. The first
X field has the site name of the neighbor, the second field
X has a newsgroup pattern describing the newsgroups sent to
X the neighbor. The third and fourth fields are not defined
X by this standard. A sample response:
X
X From cbosgd!mark Sun Mar 27 20:39:37 1983
X Subject: response to your sendsys request
X To: mark@cbosgd.UUCP
X
X Responding-System: cbosgd.UUCP
X cbosgd:osg,cb,btl,bell,net,fa,to,test
X ucbvax:net,fa,to.ucbvax:L:
X cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
X cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
X sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
X npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
X mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
X
X 3.6 Senduuname
X
X senduuname (no arguments)
X
X The ``uuname'' program is run, and the output is mailed to
X the author of the control message (Reply-to, if present,
X otherwise From). This program lists all uucp neighbors of
X the local site. This information is used to make maps of
X the UUCP network. The sys file is not the same as the
X UUCP L.sys file. The L.sys file should never be
X transmitted to another party without the consent of the
X sites whose passwords are listed therein.
X
X It is optional for a site to provide this information.
X Some reply should be made to the author of the control
X message, so that a transmission error won't be blamed. It
X is also permissible for a site to run the uuname program
X (or in some other way determine the uucp neighbors) and
X edit the output, either automatically or manually, before
X mailing the reply back to the author. The file should
X contain one site per line, beginning with the uucp site
X name. Additional information may be included, separated
X from the site name by a blank or tab. The phone number or
X password for the site should NOT be included, as the reply
X is considered to be in the public domain. (The uuname
X
X
X
X
X
X
X
X
X
X
X
X - 14 -
X
X
X
X program will send only the site name and not the entire
X contents of the L.sys file, thus, phone numbers and
X passwords are not transmitted.)
X
X The purpose of this message is to generate and maintain
X UUCP mail routing maps. Thus, connections over which mail
X can be sent using the site!user syntax should be included,
X regardless of whether the link is actually a UUCP link at
X the physical level. If a mail router should use it, it
X should be included. Since all information sent in
X response to this message is optional, sites are free to
X edit the list, deleting secret or private links they do
X not wish to publicise.
X
X 3.7 Version
X
X version (no arguments)
X
X The name and version of the software running on the local
X system is to be mailed back to the author of the article
X (Reply-to if present, otherwise From).
X
X
X 4. Transmission Methods
X
X USENET is not a physical network, but rather a logical
X network resting on top of several existing physical
X networks. These networks include, but are not limited to,
X UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC
X Hyperchannel, and a Berknet. What is important is that
X two neighboring systems on USENET have some method to get
X a new article, in the format listed here, from one system
X to the other, and once on the receiving system, processed
X by the netnews software on that system. (On UNIX systems,
X this usually means the ``rnews'' program being run with
X the article on the standard input.)
X
X It is not a requirement that USENET sites have mail
X systems capable of understanding the ARPA Internet mail
X syntax, but it is strongly recommended. Since From,
X Reply-To, and Sender lines use the Internet syntax,
X replies will be difficult or impossible without an
X internet mailer. A site without an internet mailer can
X attempt to use the Path header line for replies, but this
X field is not guaranteed to be a working path for replies.
X In any event, any site generating or forwarding news
X messages must have an internet address that allows them to
X receive mail from sites with internet mailers, and they
X must include their internet address on their From line.
X
X
X
X
X
X
X
X
X
X
X
X
X
X - 15 -
X
X
X
X 4.1 Remote Execution
X
X Some networks permit direct remote command execution. On
X these networks, news may be forwarded by spooling the
X rnews command with the article on the standard input. For
X example, if the remote system is called ``remote'', news
X would be sent over a UUCP link with the command ``uux -
X remote!rnews'', and on a Berknet, ``net -mremote rnews''.
X It is important that the article be sent via a reliable
X mechansim, normally involving the possibility of spooling,
X rather than direct real-time remote execution. This is
X because, if the remote system is down, a direct execution
X command will fail, and the article will never be
X delivered. If the article is spooled, it will eventually
X be delivered when both systems are up.
X
X 4.2 Transfer by Mail
X
X On some systems, direct remote spooled execution is not
X possible. However, most systems support electronic mail,
X and a news article can be sent as mail. One approach is
X to send a mail message which is identical to the news
X message: the mail headers are the news headers, and the
X mail body is the news body. By convention, this mail is
X sent to the user ``newsmail'' on the remote machine.
X
X One problem with this method is that it may not be
X possible to convince the mail system that the From line of
X the message is valid, since the mail message was generated
X by a program on a system different from the source of the
X news article. Another problem is that error messages
X caused by the mail transmission would be sent to the
X originator of the news article, who has no control over
X news transmission between two cooperating hosts and does
X not know who to contact. Transmission error messages
X should be directed to a responsible contact person on the
X sending machine.
X
X A solution to this problem is to encapsulate the news
X article into a mail message, such that the entire article
X (headers and body) are part of the body of the mail
X message. The convention here is that such mail is sent to
X user ``rnews'' on the remote system. A mail message body
X is generated by prepending the letter ``N'' to each line
X of the news article, and then attaching whatever mail
X headers are convenient to generate. The N's are attached
X to prevent any special lines in the news article from
X interfering with mail transmission, and to prevent any
X extra lines inserted by the mailer (headers, blank lines,
X etc.) from becoming part of the news article. A program
X on the receiving machine receives mail to ``rnews'',
X
X
X
X
X
X
X
X
X
X
X
X - 16 -
X
X
X
X extracting the article itself and invoking the ``rnews''
X program. An example in this format might look like this:
X
X Date: Monday, 3-Jan-83 08:33:47 MST
X From: news@cbosgd.UUCP
X Subject: network news article
X To: rnews@npois.UUCP
X
X NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
X NPosting-Version: B 2.9 6/21/82 sask.UUCP
X NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
X NFrom: derek@sask.UUCP (Derek Andrew)
X NNewsgroups: net.test
X NSubject: necessary test
X NMessage-ID: <176@sask.UUCP>
X NDate: Monday, 3-Jan-83 00:59:15 MST
X N
X NThis really is a test. If anyone out there more than 6
X Nhops away would kindly confirm this note I would
X Nappreciate it. We suspect that our news postings
X Nare not getting out into the world.
X N
X
X
X Using mail solves the spooling problem, since mail must
X always be spooled if the destination host is down.
X However, it adds more overhead to the transmission process
X (to encapsulate and extract the article) and makes it
X harder for software to give different priorities to news
X and mail.
X
X 4.3 Batching
X
X Since news articles are usually short, and since a large
X number of messages are often sent between two sites in a
X day, it may make sense to batch news articles. Several
X articles can be combined into one large article, using
X conventions agreed upon in advance by the two sites. One
X such batching scheme is described here; its use is still
X considered experimental.
X
X News articles are combined into a script, separated by a
X header of the form:
X
X ##! rnews 1234
X
X where 1234 is the length, in bytes, of the article. Each
X such line is followed by an article containing the given
X number of bytes. (The newline at the end of each line of
X the article is counted as one byte, for purposes of this
X count, even if it is stored as CRLF.) For example, a batch
X
X
X
X
X
X
X
X
X
X
X
X - 17 -
X
X
X
X of articles might look like this:
X
X #! rnews 374
X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
X From: jerry@eagle.uucp (Jerry Schwarz)
X Newsgroups: net.general
X Subject: Usenet Etiquette -- Please Read
X Message-ID: <642@eagle.UUCP>
X Date: Friday, 19-Nov-82 16:14:55 EST
X
X Here is an important message about USENET Etiquette.
X #! rnews 378
X Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
X Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
X Path: cbosgd!mhuxj!mhuxt!eagle!jerry
X From: jerry@eagle.uucp (Jerry Schwarz)
X Newsgroups: net.followup
X Subject: Notes on Etiquette article
X Message-ID: <643@eagle.UUCP>
X Date: Friday, 19-Nov-82 17:24:12 EST
X
X There was something I forgot to mention in the last message.
X
X Batched news is recognized because the first character in
X the message is ``#''. The message is then passed to the
X unbatcher for interpretation.
X
X
X 5. The News Propagation Algorithm
X
X This section describes the overall scheme of USENET and
X the algorithm followed by sites in propagating news to the
X entire network. Since all sites are affected by
X incorrectly formatted articles and by propagation errors,
X it is important for the method to be standardized.
X
X USENET is a directed graph. Each node in the graph is a
X host computer, each arc in the graph is a transmission
X path from one host to another host. Each arc is labelled
X with a newsgroup pattern, specifying which newsgroup
X classes are forwarded along that link. Most arcs are
X bidirectional, that is, if site A sends a class of
X newsgroups to site B, then site B usually sends the same
X class of newsgroups to site A. This bidirectionality is
X not, however, required.
X
X USENET is made up of many subnetworks. Each subnet has a
X name, such as ``net'' or ``btl''. The special subnet
X ``net'' is defined to be USENET, although the union of all
X
X
X
X
X
X
X
X
X
X
X
X - 18 -
X
X
X
X subnets may be a superset of USENET (because of sites that
X get local newsgroup classes but do not get net.all). Each
X subnet is a connected graph, that is, a path exists from
X every node to every other node in the subnet. In
X addition, the entire graph is (theoretically) connected.
X (In practice, some political considerations have caused
X some sites to be unable to post articles reaching the rest
X of the network.)
X
X An article is posted on one machine to a list of
X newsgroups. That machine accepts it locally, then
X forwards it to all its neighbors that are interested in at
X least one of the newsgroups of the message. (Site A deems
X site B to be ``interested'' in a newsgroup if the
X newsgroup matches the pattern on the arc from A to B.
X This pattern is stored in a file on the A machine.) The
X sites receiving the incoming article examine it to make
X sure they really want the article, accept it locally, and
X then in turn forward the article to all their interested
X neighbors. This process continues until the entire
X network has seen the article.
X
X An important part of the algorithm is the prevention of
X loops. The above process would cause a message to loop
X along a cycle forever. In particular, when site A sends
X an article to site B, site B will send it back to site A,
X which will send it to site B, and so on. One solution to
X this is the history mechanism. Each site keeps track of
X all articles it has seen (by their message ID) and
X whenever an article comes in that it has already seen, the
X incoming article is discarded immediately. This solution
X is sufficient to prevent loops, but additional
X optimizations can be made to avoid sending articles to
X sites that will simply throw them away.
X
X One optimization is that an article should never be sent
X to a machine listed in the Path line of the header. When
X a machine name is in the Path line, the message is known
X to have passed through the machine. Another optimization
X is that, if the article originated on site A, then site A
X has already seen the article. (Origination can be
X determined by the Posting-Version line.)
X
X Thus, if an article is posted to newsgroup ``net.misc'',
X it will match the pattern ``net.all'' (where ``all'' is a
X metasymbol that matches any string), and will be forwarded
X to all sites that subscribe to net.all (as determined by
X what their neighbors send them). These sites make up the
X ``net'' subnetwork. An article posted to ``btl.general''
X will reach all sites receiving ``btl.all'', but will not
X reach sites that do not get ``btl.all''. In effect, the
X
X
X
X
X
X
X
X
X
X
X
X - 19 -
X
X
X
X articles reaches the ``btl'' subnetwork. An article
X posted to newsgroups ``net.micro,btl.general'' will reach
X all sites subscribing to either of the two classes.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X============
X
XFrom schein Thu Jun 9 14:36:35 1988 remote from cbmvax
XReceived: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87))
X id AA14116; Thu, 9 Jun 88 14:36:35 edt
XDate: Thu, 9 Jun 88 14:36:35 edt
XFrom: cbmvax!schein (Dan Schein CATS)
XMessage-Id: <8806091836.AA14116@cbmvax.UUCP>
XTo: heimat!sysop
XSubject: How to UseNet
X
X
X How to Use USENET Effectively
X
X
X Matt Bishop
X Research Institute for Advanced Computer Science
X Mail Stop 230-5
X NASA Ames Research Center
X
X Moffett Field, CA 94035
X
X
X
X 1. Introduction
X
X USENET is a worldwide bulletin board system in which
X thousands of computers pass articles back and forth. Of necessi-
X ty, customs have sprung up enabling very diverse people and
X groups to communicate peaceably and effectively using USENET.
X These customs are for the most part written, but are scattered
X over several documents that can be difficult to find; in any
X case, even if a new user can find all the documents, he most
X likely will have neither the time nor the inclination to read
X them all. This document is intended to collect all these conven-
X tions into one place, thereby making it easy for new users to
X learn about the world of USENET. (Old-timers, too, will benefit
X from reading this.)
X
X You should read this document and understand it thoroughly
X before you even think about posting anything. If you have ques-
X tions, please ask your USENET administrator (who can usually be
X reached by sending mail to usenet) or a more knowledgeable USENET
X user. Believe me, you will save yourself a lot of grief.
X
X The mechanics of posting an article to USENET are explained
END_OF_FILE
if test 48305 -ne `wc -c <'man/Standards.aa'`; then
echo shar: \"'man/Standards.aa'\" unpacked with wrong size!
fi
# end of 'man/Standards.aa'
fi
echo shar: End of archive 15 \(of 16\).
cp /dev/null ark15isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 16 archives.
rm -f ark[1-9]isdone ark[1-9][0-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0
--
Submissions to comp.sources.amiga and comp.binaries.amiga should be sent to:
amiga@cs.odu.edu
or amiga@xanth.cs.odu.edu ( obsolescent mailers may need this address )
or ...!uunet!xanth!amiga ( very obsolescent mailers need this address )
Comments, questions, and suggestions should be addressed to ``amiga-request''
(please only use ``amiga'' for actual submissions) at the above addresses.