sources-request@mirror.UUCP (11/06/86)
Submitted by: seismo!rick (Rick Adams) Mod.sources: Volume 7, Issue 48 Archive-name: 2.11news/Part08 [ I held off posting for a couple of days becuase of the West Coast "newsquake." --r$ ] Path: seismo!rick From: rick@seismo.CSS.GOV (Rick Adams) Newsgroups: mod.sources Subject: news 2.11 documentation (6 of 6) Message-ID: <41912@beno.seismo.CSS.GOV> Date: 30 Oct 86 21:44:19 GMT Distribution: world Organization: Center for Seismic Studies, Arlington, VA Lines: 1490 # To extract, sh this file # # news 2.11 documentation 6 of 6 # if test ! -d doc then mkdir doc fi echo x - doc/standard.mn 1>&2 sed 's/.//' >doc/standard.mn <<'*-*-END-of-doc/standard.mn-*-*' -.ds h0 "RFC xxx -.ds h1 DRAFT -.ds h2 % -.ds f0 "Standard for Interchange of USENET Messages -.ds f1 -.ds f2 "October 20, 1986 -.mt -Standard for Interchange of USENET Messages -[Obsoletes RFC 850] -.au -Mark R. Horton -.ai -AT&T Bell Laboratories -Columbus, OH 43213 -.au -Revised for B 2.11 news by Rick Adams -.hn -Introduction -.pg -This document defines the standard format for the interchange -of network News messages among USENET hosts. -It describes the format for messages themselves, -and gives partial standards for transmission of news. -The news transmission is not entirely standardized -in order to give a good deal of flexibility -to the individual hosts to choose transmission hardware and software, -whether to batch news, -and so on. -.pg -There are five sections to this document. -Section two 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. -.hn -Message Format -.pg -The primary consideration in choosing a message format is -that it fit in with existing tools as well as possible. -Existing tools include both implementations of mail and news. -(The -.i notesfiles -system from the University of Illinois -is considered a news implementation.) -A standard format for mail messages has existed for many years on the ARPANET, -and this format meets most of the needs of USENET. -Since the ARPANET format is extensible, -extensions to meet the additional needs of USENET -are easily made within the ARPANET standard. -Therefore, -the rule is adopted that all USENET news messages -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 message -and forbidding use of certain ARPANET features. -However, -it should always be possible to use a tool -expecting an ARPANET message to process a news message. -In any situation where this standard conflicts with the ARPANET standard, -RFC 822 should be considered correct and this standard in error. -.pg -An example message is included to illustrate the fields. -.sd -From: jerry@eagle.ATT.COM (Jerry Schwarz) -Path: cbosgd!mhuxj!mhuxt!eagle!jerry -Newsgroups: news.announce -Subject: Usenet Etiquette -- Please Read -Message-ID: <642@eagle.ATT.COM> -Date: Fri, 19 Nov 82 16:14:55 GMT -Followup-To: news.misc -Expires: Sat, 1 Jan 83 00:00:00 -0500 -Organization: AT&T Bell Laboratories, Murray Hill - -The body of the message comes here, after a blank line. -.ed -Here is an example of a message in the old format -(before the existence of this standard). -It is recommended that implementations also accept messages -in this format to ease upward conversion. -.sd -From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) -Newsgroups: news.misc -Title: Usenet Etiquette -- Please Read -Article-I.D.: eagle.642 -Posted: Fri Nov 19 16:14:55 1982 -Received: Fri Nov 19 16:59:30 1982 -Expires: Mon Jan 1 00:00:00 1990 - -The body of the message comes here, after a blank line. -.ed -Some news systems transmit news in the -.pa A -format, -which looks like this: -.sd -Aeagle.642 -news.misc -cbosgd!mhuxj!mhuxt!eagle!jerry -Fri Nov 19 16:14:55 1982 -Usenet Etiquette - Please Read -The body of the message comes here, with no blank line. -.ed -.pg -A message consists of several header lines, -followed by a blank line, -followed by the body of the message. -The header lines consist of a keyword, -a colon, -a blank, -and some additional information. -This is a subset of the ARPANET standard, -simplified to allow simpler software to handle it. -The -.hf From -line may optionally include a full name, -in the format above, -or use the ARPANET angle bracket syntax. -To keep the implementations simple, -other formats -(for example, -with part of the machine address after the close parenthesis) -are not allowed. -The ARPANET convention of continuation header lines -(beginning with a blank or tab) -is allowed. -.pg -Certain headers are required, -and certain other headers are optional. -Any unrecognized headers are allowed, -and will be passed through unchanged. -The required headers are -.hf From , -.hf Date , -.hf Newsgroups , -.hf Subject , -.hf Message-ID , -and -.hf Path . -The optional headers are -.hf Followup-To , -.hf Expires , -.hf Reply-To , -.hf Sender , -.hf References , -.hf Control , -.hf Distribution , -.hf Keywords , -.hf Summary , -.hf Approved , -.hf Lines , -.hf Xref , -and -.hf Organization . -.hn 2 -Required Headers -.hn 3 -From -.pg -The -.hf From -line contains the electronic mailing address of the person who sent the message, -in the ARPA internet syntax. -It may optionally also contain the full name of the person, -in parentheses, -after the electronic address. -The electronic address is the same as the entity responsible -for originating the message, -unless the -.hf Sender -header is present, -in which case the -.hf From -header might not be verified. -Note that in all host and domain names, -upper and lower case are considered the same, -thus -.cf mark@cbosgd.ATT.COM , -.cf mark@cbosgd.att.com , -and -.cf mark@CBosgD.ATt.COm -are all equivalent. -User names may or may not be case sensitive, for example, -.cf Billy@cbosgd.ATT.COM -might be different from -.cf BillY@cbosgd.ATT.COM . -Programs should avoid changing the case of electronic addresses -when forwarding news or mail. -.pg -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 -.hf From -line. -This standard specifies a more rigid syntax. -The full name is not considered a comment, -but an optional part of the header line. -Either the full name is omitted, -or it appears in parentheses after the electronic address -of the person posting the message, -or it appears before an electronic address which is enclosed in angle brackets. -Thus, -the three permissible forms are: -.sd -From: mark@cbosgd.ATT.COM -From: mark@cbosgd.ATT.COM (Mark Horton) -From: Mark Horton <mark@cbosgd.ATT.COM> -.ed -Full names may contain any printing ASCII characters from space through tilde, -except 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, -in particular, -the characters -\&\*(lq,\*(rq (comma), -\&\*(lq:\*(rq (colon), -\&\*(lq@\*(rq (at), -\&\*(lq!\*(rq (bang), -\&\*(lq/\*(rq (slash), -\&\*(lq=\*(rq (equal), -and \*(lq;\*(rq (semicolon) are inadvisable in full names. -.hn 3 -Date -.pg -The -.hf Date -line (formerly -.hf Posted ) -is the date, -in a format that must be acceptable both to the ARPANET -and to the -.i getdate (3) -routine, -that the message was originally posted to the network. -This date remains unchanged as the message is propagated -throughout the network. -One format that is acceptable to both is: -.sd c -\f2Wdy\fP, \f2DD\fP\ \f2Mon\fP\ \f2YY\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2TIMEZONE\fP -.ed -Several examples of valid dates appear in the sample -message above. -Note in particular that -.i ctime (3) -format: -.sd c -\f2Wdy\fP \f2Mon\fP \f2DD\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2YYYY\fP -.ed -is -.i not -acceptable because it is not a valid ARPANET date. -However, -since older software still generates this format, -news implementations are encouraged to accept this format -and translate it into an acceptable format. -.pg -There is no hope of having a complete list of timezones. -Universal Time (GMT), the North American timezones -(PST, PDT, MST, MDT, CST, CDT, EST, EDT) and the -+/\-hhmm offset specifed in RFC822 should be supported. -It is recommended that times in message headers be transmitted in GMT -and displayed in the local time zone. -.hn 3 -Newsgroups -.pg -The -.hf Newsgroups -line specifies the newsgroup or newsgroups in which the message belongs. -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. -.pg -Wildcards -.i e\f1.\fPg ., ( -the word -.ng all) -are never allowed in a -.hf Newsgroups -line. -For example, -a newsgroup -.ng comp.all -is illegal, -although a newsgroup name -.ng rec.sport.football -is permitted. -.pg -If a message is received with a -.hf Newsgroups -line listing some valid newsgroups and some invalid newsgroups, -a host should not remove invalid newsgroups from the list. -Instead, -the invalid newsgroups should be ignored. -For example, -suppose host -.cn A -subscribes to the classes -.ng btl.all -and -.ng comp.all , -and exchanges news messages with host -.cn B , -which subscribes to -.ng comp.all -but not -.ng btl.all . -Suppose -.cn A -receives a message with -.sd c -Newsgroups: comp.unix,btl.general -.ed -This message is passed on to -.cn B -because -.cn B -receives -.ng comp.unix , -but -.cn B -does not receive -.ng btl.general . -.cn A -must leave the -.hf Newsgroups -line unchanged. -If it were to remove -.ng btl.general , -the edited header could eventually re-enter the -.ng btl.all -class, -resulting in a message that is not shown to users subscribing to -.ng btl.general . -Also, -follow-ups from outside -.ng btl.all -would not be shown to such users. -.hn 3 -Subject -.pg -The -.hf Subject -line -(formerly -.hf Title ) -tells what the message is about. -It should be suggestive enough of the contents of the message -to enable a reader to make a decision whether to read the message -based on the subject alone. -If the message is submitted in response to another message -.i e\f1.\fPg ., ( -is a -.i follow-up ) -the default subject should begin with the four characters \*(lqRe: \*(rq -and the -.hf References -line is required. -For follow-ups, the use of the -.hf Summary -line is encouraged. -.hn 3 -Message-ID -.pg -The -.hf Message-ID -line gives the message a unique identifier. -The Message-ID may not be reused during the lifetime of any previous message -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 -.sd c -<\f2string not containing blank or \*(lq>\*(rq\fP> -.ed -In order to conform to RFC 822, -the Message-ID must have the format -.sd c -<\f2unique\fP@\f2full_domain_name\fP> -.ed -where -.i "full_domain_name" -is the full name of the host at which the message entered the network, -including a domain that host is in, -and -.i unique -is any string of printing ASCII characters, -not including -\*(lq<\*(rq (left angle bracket), -\*(lq>\*(rq (right angle bracket), -or \*(lq@\*(rq (at sign). -For example, -the -.i unique -part could be an integer representing a sequence number -for messages submitted to the network, -or a short string derived from the date and time the message was created. -For example, -a valid Message-ID for a message submitted from host -.cn ucbvax -in domain -.cf Berkeley.EDU -would be -.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. -It is not safe, -for example, -to assume that a Message-ID will be under 14 characters, -that it is unique in the first 14 characters, nor that -is does not contain a \*(lq/\*(rq. -.pg -The angle brackets are considered part of the Message-ID. -Thus, -in references to the Message-ID, -such as the -.pa ihave/sendme -and -.pa cancel -control messages, -the angle brackets are included. -White space characters -.i e\f1.\fPg ., ( -blank and tab) -are not allowed in a Message-ID. -Slashes (\*(lq/\*(rq) are strongly discouraged. -All characters between the angle brackets must be printing ASCII characters. -.hn 3 -Path -.pg -This line shows the path the message 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 -.hf Path -line. -The names may be separated by any punctuation character or characters -(except \*(lq.\*(rq which is considered part of the hostname). -Thus, the following are valid entries: -.sd c -cbosgd!mhuxj!mhuxt -cbosgd, mhuxj, mhuxt -@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM -teklabs, zehntel, sri-unix@cca!decvax -.ed -(The latter path indicates a message that passed through -.cn decvax , -.cn cca , -.cn sri-unix , -.cn zehntel , -and -.cn teklabs , -in that order.) -Additional names should be added from the left. -For example, -the most recently added name in the third example was -.cn teklabs . -Letters, -digits, -periods and hyphens are considered part of host names; -other punctuation, -including blanks, -are considered separators. -.pg -Normally, -the rightmost name will be the name of the originating system. -However, -it is also permissible to include an extra entry on the right, -which is the name of the sender. -This is for upward compatibility with older systems. -.pg -The -.hf Path -line is not used for replies, -and should not be taken as a mailing address. -It is intended to show the route -the message traveled to reach the local host. -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 hosts. -Perhaps the most important use is to cut down on redundant USENET traffic -by failing to forward a message to a host that is -known to have already received it. -In particular, when host -.cn A -sends a message to host -.cn B , -the -.hf Path -line includes -.cn A , -so that host -.cn B -will not immediately send the message back to host -.cn A . -The name each host uses to identify itself should be -the same as the name by which its neighbors know it, -in order to make this optimization possible. -.pg -A host adds its own name to the front of a path -when it receives a message from another host. -Thus, if a message with path -.cf A!X!Y!Z -is passed from host -.cn A -to host -.cn B , -.cn B -will add its own name to the path when it receives the message from -.cn A , -.i e\f1.\fPg ., -.cf \*(lqB!A!X!Y!Z\*(rq . -If -.cn B -then passes the message on to -.cn C , -the message sent to -.cn C -will contain the path -.cf B!A!X!Y!Z , -and when -.cn C -receives it, -.cn C -will change it to -.cf C!B!A!X!Y!Z . -.pg -Special upward compatibility note: -Since the -.hf From , -.hf Sender , -and -.hf Reply-To -lines are in internet format, -and since many USENET hosts do not yet have mailers -capable of understanding internet format, -it would break the reply capability to completely sever the connection -between the -.hf Path -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. -However, -the existing convention of placing the host name and an -.cf ! -at the front of the path, -and of starting the path with the host name, -an -.cf ! , -and the user name, -should be maintained when possible. -.hn 2 -Optional Headers -.hn 3 -Reply-To -.pg -This line has the same format as -.hf From . -If present, -mailed replies to the author should be sent to the name given here. -Otherwise, -replies are mailed to the name on the -.hf From -line. -(This does not prevent additional copies from being sent to recipients -named by the replier, -or on -.hf To -or -.hf Cc -lines.) -The full name may be optionally given, -in parentheses, -as in the -.hf From -line. -.hn 3 -Sender -.pg -This field is present only if the submitter manually enters a -.hf From -line. -It is intended to record the entity responsible -for submitting the message to the network. -It should be verified by the software at the submitting host. -.pg -For example, -if John Smith is visiting CCA and wishes to post a message to the network, -using friend Sarah Jones' account, -the message might read -.sd -From: smith@ucbvax.Berkeley.EDU (John Smith) -Sender: jones@cca.COM (Sarah Jones) -.ed -If a gateway program enters a mail message into the network at host -.cn unix.SRI.COM , -the lines might read -.sd -From: John.Doe@A.CS.CMU.EDU -Sender: network@unix.SRI.COM -.ed -The primary purpose of this field is to be able to track down messages -to determine how they were entered into the network. -The full name may be optionally given, -in parentheses, -as in the -.hf From -line. -.hn 3 -Followup-To -.pg -This line has the same format as -.hf Newsgroups . -If present, -follow-up messages are to be posted -to the newsgroup or newsgroups listed here. -If this line is not present, -follow-ups are posted to the newsgroup or newsgroups listed in the -.hf Newsgroups -line. -.pg -If the keyword -.i poster -is present, follow-up messages are not permitted. The message should -be mailed to the submitter of the message via mail. -.hn 3 -Expires -.pg -This line, -if present, -is in a legal USENET date format. -It specifies a suggested expiration date for the message. -If not present, -the local default expiration date is used. -.P -This field is intended to be used to clean up -messages with a limited usefulness, -or to keep important messages around for longer than usual. -For example, -a message announcing an upcoming seminar -could have an expiration date the day after the seminar, -since the message is not useful after the seminar is over. -Since local hosts have local policies for expiration of news -(depending on available disk space, -for instance), -users are discouraged from providing expiration dates for messages -unless there is a natural expiration date associated with the topic. -System software should almost never provide a default -.hf Expires -line. -Leave it out and allow local policies to be used -unless there is a good reason not to. -.hn 3 -References -.pg -This field lists the Message-ID's of any messages prompting -the submission of this message. -It is required for all follow-up message, -and forbidden when a new subject is raised. -Implementations should provide a follow-up command, -which allows a user to post a follow-up message. -This command should generate a -.hf Subject -line which is the same as the original message, -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. -If there is no -.hf References -line on the original header, -the -.hf References -line should contain the Message-ID of the original message -(including the angle brackets). -If the original message does have a -.hf References -line, -the follow-up message should have a -.hf References -line containing the text of the original -.hf References -line, -a blank, -and the Message-ID of the original message. -.pg -The purpose of the -.hf References -header is to allow messages 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 need not make use of this header, -but all automatically generated follow-ups should generate the -.hf References -line for the benefit of systems that do use it, -and manually generated follow-ups -.i e\f1.\fPg ., ( -typed in well after the original message has been printed by the machine) -should be encouraged to include them as well. -.pg -It is permissible to not include the entire previous -.hf References -line if it is too long. An attempt should be made to include a reasonable -number of backwards references. -.hn 3 -Control -.pg -If a message contains a -.hf Control -line, -the message is a control message. -Control messages are used for communication among USENET host machines, -not to be read by users. -Control messages are distributed by the same newsgroup mechanism -as ordinary messages. -The body of the -.hf Control -header line is the message to the host. -.pg -For upward compatibility, -messages that match the newsgroup pattern -.ng all.all.ctl -should also be interpreted as control messages. -If no -.hf Control -header is present on such messages, -the subject is used as the control message. -However, -messages on newsgroups matching this pattern do not conform to this standard. -.pg -Also for upward compatibility, -if the first 4 characters of the -.hf Subject: -line are \*(lqcmsg\*(rq, the rest of the -.hf Subject: -line should be interpreted as a control message. -.hn 3 -Distribution -.pg -This line is used to alter the distribution scope of the message. -It is a comma separated list similar to the -.hf Newsgroups -line. User subscriptions are still controlled by -.hf Newsgroups , -but the message is sent to all systems subscribing to the newsgroups -on the -.hf Distribution -line in addition to the -.hf Newsgroups -line. -For the message to be transmitted, the receiving site must normally receive -one of the specified newsgroups -.b AND -must receive one of the specified distributions. -Thus, -a car for sale in New Jersey might have headers including -.sd -Newsgroups: rec.auto,misc.forsale -Distribution: nj,ny -.ed -so that it would only go to persons subscribing to -.ng rec.auto -or -.ng misc.forsale -within New Jersey or New York. -The intent of this header is to restrict the distribution of a newsgroup -further, not to increase it. A local newsgroup, such as -.ng nj.crazy-eddie , -will probably not be propagated by hosts outside New Jersey -that do not show such a newsgroup as valid. -A follow-up message should default to the same -.hf Distribution -line as the original message, 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. -.hn 3 -Organization -.pg -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 host names are often cryptic enough to make it hard -to recognize the organization by the electronic address. -.hn 3 -Keywords -.pg -A few, well selected keywords identifying the message should be on -this line. This is used as an aid in determining if this message is -interesting to the reader. -.hn 3 -Summary -.pg -This line should contain a brief summary of the message. It is -usually used as part of a follow-up to another message. Again, it is -very useful to the reader in determining whether to read the message. -.hn 3 -Approved -.pg -This line is required for any message posted to a moderated newsgroup. -It should be added by the moderator and consist of his mail address. -It is also required with certain control messages. -.hn 3 -Lines -.pg -This contains a count of the number of lines in the body of the message. -.hn 3 -Xref -.pg -This line contains the name of the host (with domains omitted) and a -white space separated list of colon separated pairs of newsgroup names -and message numbers. These are the newsgroups listed in the -.hf Newsgroups -line and the corresponding message numbers from the spool directory. -.pg -This is only of value to the local system, so it should not be transmitted. -For example, in: -.sd c -Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid -From: reid@decwrl.DEC.COM (Brian Reid) -Newsgroups: news.lists,news.groups -Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86 -Message-ID: <5658@decwrl.DEC.COM> -Date: 1 Oct 86 11:26:15 GMT -Organization: DEC Western Research Laboratory -Lines: 441 -Approved: reid@decwrl.UUCP -Xref: seismo news.lists:461 news.groups:6378 -.ed -the -.hf Xref -line shows that the message is message number 461 in the newsgroup -.b news.lists , -and message number 6378 in the newsgroup -.b news.groups , -on host -.i seismo . -This information may be used by certain user interfaces. -.hn 1 -Control Messages -.pg -This section lists the control messages currently defined. -The body of the -.hf Control -header is the control message. -Messages are a sequence of zero or more words, -separated by white space (blanks or tabs). -The first word is the name of the control message, -remaining words are parameters to the message. -The remainder of the header and the body of the message -are also potential parameters; -for example, -the -.hf From -line might suggest an address to which a response is to be mailed. -.pg -Implementors and administrators may choose to allow control messages -to be carried out automatically, -or to queue them for manual processing. -However, -manually processed messages should be dealt with promptly. -.pg -Failed control messages should NOT be mailed to the originator of the message, -but to the local \*(lqusenet\*(rq account. -.hn 2 -Cancel -.pg l -.sd -cancel <Message-ID> -.ed -If a message with the given Message-ID is present on the local system, -the message is cancelled. -This mechanism allows a user to cancel a message -after the message has been distributed over the network. -.pg -If the system is unable to cancel the message as requested, it should not -forward the cancellation request to its neighbor systems. -.pg -Only the author of the message or the local news administrator -is allowed to send this message. -The verified sender of a message is the -.hf Sender -line, -or if no -.hf Sender -line is present, -the -.hf From -line. -The verified sender of the cancel message must be the same -as either the -.hf Sender -or -.hf From -field of the original message. -A verified sender in the cancel message is allowed to match an unverified -.hf From -in the original message. -.hn 2 -Ihave/Sendme -.pg l -.sd -ihave <Message-ID list> [<remotesys>] -sendme <Message-ID list> [<remotesys>] -.ed -This message is part of the -.pa ihave/sendme -protocol, -which allows one host -(say -.cn A ) -to tell another host -.cn B ) ( -that a particular message has been received on -.cn A . -Suppose that host -.cn A -receives message -.cf <1234@ucbvax.Berkeley.edu> , -and wishes to transmit the message to host -.cn B . -.cn A -sends the control message -.cf "ihave <1234@ucbvax.Berkeley.edu> A" -to host -.cn B -(by posting it to newsgroup -.bi B ). \f3to.\fP -.cn B -responds with the control message -.cf "sendme <1234@ucbvax.Berkeley.edu> B" -(on newsgroup -.bi A ) \f3to.\fP -if it has not already received the message. -Upon receiving the -.pa sendme -message, -.cn A -sends the message to -.cn B . -.pg -This protocol can be used to cut down on redundant traffic between hosts. -It is optional and should be used -only if the particular situation makes it worthwhile. -Frequently, -the outcome is that, -since most original messages are short, -and since there is a high overhead to start sending a new message with UUCP, -it costs as much to send the -.pa ihave -as it would cost to send the message itself. -.pg -One possible solution to this overhead problem is to batch requests. -Several Message-ID's may be announced or requested in one message. -If no Message-ID's are listed in the control message, -the body of the message should be scanned for Message-ID's, -one per line. -.hn 2 -Newgroup -.sd -newgroup <groupname> [moderated] -.ed -.pg -This control message creates a new newsgroup with the given name. -Since no messages 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. -.pg -If the second argument is present and it is the keyword -.i moderated , -the group should be created moderated instead of the default of unmoderated. -The -.pa newgroup -message should be ignored unless there is an -.hf Approved -line in the same message header. -.hn 2 -Rmgroup -.sd -rmgroup <groupname> -.ed -.pg -This message removes a newsgroup with the given name. -Since the newsgroup is removed from every host on the network, -this command should be used carefully by a responsible administrator. -The rmgroup message should be ignored unless there is an -.hf Approved: -line in the same message header. -.hn 2 -Sendsys -.sd -sendsys (no arguments) -.ed -.pg -The -.i sys -file, -listing all neighbors and which newsgroups are sent to each neighbor, -will be mailed to the author of the control message -.hf Reply-To , ( -if present, -otherwise -.hf From ). -This information is considered public information, -and it is a requirement of membership in USENET -that this information be provided on request, -either automatically in response to this control message, -or manually, -by mailing the requested information to the author of the message. -This information is used to keep the map of USENET up to date, -and to determine where netnews is sent. -.pg -The format of the file mailed back to the author -should be the same as that of the -.i sys -file. -This format has one line per neighboring host -(plus one line for the local host), -containing four colon separated fields. -The first field has the host 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. -The -.i sys -file is -.b not -the same as the UUCP -.i L.sys -file. -A sample response is: -.sd -From: cbosgd!mark (Mark Horton) -Date: Sun, 27 Mar 83 20:39:37 -0500 -Subject: response to your sendsys request -To: mark@cbosgd.ATT.COM - -Responding-System: cbosgd.ATT.COM -cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,test -ucbvax:world,comp,to.ucbvax:L: -cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg -cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb -sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent -npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois -mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi -.ed -.hn 2 -Senduuname -.pg l -.sd -senduuname (no arguments) -.ed -The -.i uuname (1) -program is run, -and the output is mailed to the author of the control message -.hf Reply-to , ( -if present, -otherwise -.hf From ). -This program lists all UUCP neighbors of the local host. -This information is used to make maps of the UUCP network. -The -.i L.sys -file should -.b never -be transmitted to another party -without the consent of the hosts whose passwords are listed therein. -.pg -It is optional for a host 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 host to run the -.i uuname -program -(or in some other way determine the UUCP neighbors) -and edit the output, -either automatically or manually, -before mailing the reply back to the author. -The file should contain one host per line, -beginning with the UUCP host name. -Additional information may be included, -separated from the host name by a blank or tab. -The phone number or password for the host should -.ng not -be included, -as the reply is considered to be in the public domain. -(The -.i uuname -program will send only the host name and not the entire contents of the -.i L.sys -file, -thus, -phone numbers and passwords are not transmitted.) -.pg -The purpose of this message was to generate and maintain UUCP mail routing maps. -Thus, connections over which mail can be sent using the -.cf host!user -syntax should be included, -regardless of whether the link is actually a UUCP link at the physical level. -If a mail router should use it, -it should be included. -Since all information sent in response to this message is optional, -hosts are free to edit the list, -deleting secret or private links they do not wish to publicize. -This control message is not used any more. -.hn 2 -Version -.pg l -.sd -version (no arguments) -.ed -The name and version of the software running on the local system -is to be mailed back to the author of the message -.hf Reply-to "" ( -if present, -otherwise -.hf From ). -.hn 2 -checkgroups -.pg -The message body is a list of \*(lqofficial\*(rq newsgroups and their -description, one group per line. They are compared against the list -of active newsgroups on the current host. The names of any obsolete or new -newsgroups are mailed to the user \*(lqusenet\*(rq and descriptions of the -new newsgroups are added to the help file used when posting news. -.hn 1 -Transmission Methods -.pg -USENET is not a physical network, -but rather a logical network -resting on top of several existing physical networks. -These networks include, -but are not limited to, -UUCP, -the ARPANET, -an Ethernet, -the BLICN network, -an NSC Hyperchannel, -and a BERKNET. -What is important is that two neighboring systems on USENET -have some method to get a new message, -in the format listed here, -from one system to the other, -and once on the receiving system, -processed by the netnews software on that system. -(On -.ux -systems, -this usually means the -.i rnews -program being run with the message on the standard input.) -.pg -It is not a requirement that USENET hosts have mail systems -capable of understanding the ARPA Internet mail syntax, -but it is strongly recommended. -Since -.hf From , -.hf Reply-To , -and -.hf Sender -lines use the Internet syntax, -replies will be difficult or impossible without an internet mailer. -A host without an internet mailer can attempt to use the -.hf Path -header line for replies, -but this field is not guaranteed to be a working path for replies. -In any event, -any host generating or forwarding news messages -must have an internet address that allows them -to receive mail from hosts with internet mailers, -and they must include their internet address on their From line. -.hn 2 -Remote Execution -.pg -Some networks permit direct remote command execution. -On these networks, -news may be forwarded by spooling the -.i rnews -command with the message on the standard input. -For example, -if the remote system is called -.cn remote , -news would be sent over a UUCP link with the command -.sd c -uux \- remote!rnews -.ed -and on a Berknet, -.sd c -net \-mremote rnews -.ed -It is important that the message be sent via a reliable mechanism, -normally involving the possibility of spooling, -rather than direct real-time remote execution. -This is because, -if the remote system is down, -a direct execution command will fail, -and the message will never be delivered. -If the message is spooled, -it will eventually be delivered when both systems are up. -.hn 2 -Transfer by Mail -.pg -On some systems, -direct remote spooled execution is not possible. -However, -most systems support electronic mail, -and a news message can be sent as mail. -One approach is to send a mail message -which is identical to the news message: -the mail headers are the news headers, -and the mail body is the news body. -By convention, -this mail is sent to the user -.i newsmail -on the remote machine. -.pg -One problem with this method is that it may not be possible to convince -the mail system that the -.hf From -line of the message is valid, -since the mail message was generated by a program -on a system different from the source of the news message. -Another problem is that error messages caused by the mail transmission -would be sent to the originator of the news message, -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. -.pg -A solution to this problem is to encapsulate the news message -into a mail message, such that the entire message -(headers and body) -are part of the body of the mail message. -The convention here is that such mail is sent to user -.i rnews -on the remote system. -A mail message body is generated by prepending the letter -.qp N -to each line of the news message, -and then attaching whatever mail headers are convenient to generate. -The -.qp N 's -are attached to prevent any special 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. -A program on the receiving machine receives mail to -.i rnews , -extracting the message itself and invoking the -.i rnews -program. -An example in this format might look like this: -.sd -Date: Mon, 3 Jan 83 08:33:47 MST -From: news@cbosgd.ATT.COM -Subject: network news message -To: rnews@npois.ATT.COM - -NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek -NFrom: derek@sask.UUCP (Derek Andrew) -NNewsgroups: misc.test -NSubject: necessary test -NMessage-ID: <176@sask.UUCP> -NDate: Mon, 3 Jan 83 00:59:15 MST -N -NThis really is a test. If anyone out there more than 6 -Nhops away would kindly confirm this note I would -Nappreciate it. We suspect that our news postings -Nare not getting out into the world. -N -.ed -.pg -Using mail solves the spooling problem, -since mail must always be spooled if the destination host is down. -However, -it adds more overhead to the transmission process -(to encapsulate and extract the message) -and makes it harder for software to give different priorities -to news and mail. -.hn 2 -Batching -.pg -Since news messages are usually short, -and since a large number of messages -are often sent between two hosts in a day, -it may make sense to batch news messages. -Several messages can be combined into one large message, -using conventions agreed upon in advance by the two hosts. -One such batching scheme is described here; -its use is highly recommended. -.pg -News messages are combined into a script, separated by a header of the form: -.sd -#! rnews 1234 -.ed -where -.i 1234 -is the length, -in bytes, -of the message. -Each such line is followed by a message containing the given number of bytes. -(The newline at the end of each line of the message is counted as one byte, -for purposes of this count, even if it is stored as -.qc "CARRIAGE RETURN\s+2><\s-2LINE FEED" \&.) -For example, -a batch of message might look like this: -.sd -#! rnews 239 -From: jerry@eagle.ATT.COM (Jerry Schwarz) -Path: cbosgd!mhuxj!mhuxt!eagle!jerry -Newsgroups: news.announce -Subject: Usenet Etiquette -- Please Read -Message-ID: <642@eagle.ATT.COM> -Date: Fri, 19 Nov 82 16:14:55 EST -Approved: mark@cbosgd.ATT.COM - -Here is an important message about USENET Etiquette. -#! rnews 234 -From: jerry@eagle.ATT.COM (Jerry Schwarz) -Path: cbosgd!mhuxj!mhuxt!eagle!jerry -Newsgroups: news.announce -Subject: Notes on Etiquette message -Message-ID: <643@eagle.ATT.COM> -Date: Fri, 19 Nov 82 17:24:12 EST -Approved: mark@cbosgd.ATT.COM - -There was something I forgot to mention in the last message. -.ed -Batched news is recognized because the first character in the message is -.qp # . -The message is then passed to the unbatcher for interpretation. -.pg -The second argument (in this example -.i rnews ), -determines which batching scheme is being used. Cooperating hosts -may use whatever scheme is appropriate for them. -.hn 1 -The News Propagation Algorithm -.pg -This section describes the overall scheme of USENET and the algorithm -followed by hosts in propagating news to the entire network. -Since all hosts are affected by incorrectly formatted messages -and by propagation errors, -it is important for the method to be standardized. -.pg -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 labeled with a newsgroup pattern, -specifying which newsgroup classes are forwarded along that link. -Most arcs are bidirectional, -that is, -if host -.cn A -sends a class of newsgroups to host -.cn B , -then host -.cn B -usually sends the same class of newsgroups to host -.cn A . -This bidirectionality is not, -however, -required. -.pg -USENET is made up of many subnetworks. -Each subnet has a name, -such as -.ng comp -or -.ng btl . -Each subnet is a connected graph, -that is, -a path exists from every node to every other node in the subnet. -In addition, -the entire graph is -(theoretically) -connected. -(In practice, -some political considerations have caused some hosts -to be unable to post messages reaching the rest of the network.) -.pg -A message is posted on one machine to a list of newsgroups. -That machine accepts it locally, -then forwards it to all its neighbors that are interested -in at least one of the newsgroups of the message. -(Site -.cn A -deems host -.cn B -to be \*(lqinterested\*(rq in a newsgroup -if the newsgroup matches the pattern on the arc from -.cn A -to -.cn B . -This pattern is stored in a file on the -.cn A -machine.) -The hosts receiving the incoming message examine it -to make sure they really want the message, -accept it locally, -and then in turn forward the message to all -.i their -interested neighbors. -This process continues until the entire network has seen the message. -.pg -An important part of the algorithm is the prevention of loops. -The above process would cause a message to loop along a cycle forever. -In particular, -when host -.cn A -sends a message to host -.cn B , -host -.cn B -will send it back to host -.cn A , -which will send it to host -.cn B , -and so on. -One solution to this is the history mechanism. -Each host keeps track of all messages it has seen -(by their Message-ID) -and whenever a message comes in that it has already seen, -the incoming message is discarded immediately. -This solution is sufficient to prevent loops, -but additional optimizations can be made to avoid sending messages to hosts -that will simply throw them away. -.pg -One optimization is that a message should never be sent to a machine -listed in the -.hf Path -line of the header. -When a machine name is in the -.hf Path -line, -the message is known to have passed through the machine. -Another optimization is that, if the message originated on host -.cn A , -then host -.cn A -has already seen the message. -.P -Thus, -if a message is posted to newsgroup -.ng misc.misc , -it will match the pattern -.ng misc.all -(where -.ng all -is a metasymbol that matches any string), -and will be forwarded to all hosts that subscribe to -.ng misc.all -(as determined by what their neighbors send them). -These hosts make up the -.ng misc -subnetwork. -A message posted to -.ng btl.general -will reach all hosts receiving -.ng btl.all , -but will not reach hosts that do not get -.ng btl.all . -In effect, -the messages reaches the -.ng btl -subnetwork. -A messages posted to newsgroups -.ng misc.misc,btl.general -will reach all hosts subscribing to either of the two classes. *-*-END-of-doc/standard.mn-*-* exit