From 7edb02677847a8f22df2f41f9e96a1722d73b78f Mon Sep 17 00:00:00 2001 From: CSRG Date: Mon, 14 Apr 1986 01:02:36 -0800 Subject: [PATCH 1/1] BSD 4_3 development Work on file usr/doc/smm/10.newsop/standard.mn Synthesized-from: CSRG/cd1/4.3 --- usr/doc/smm/10.newsop/standard.mn | 1423 +++++++++++++++++++++++++++++ 1 file changed, 1423 insertions(+) create mode 100644 usr/doc/smm/10.newsop/standard.mn diff --git a/usr/doc/smm/10.newsop/standard.mn b/usr/doc/smm/10.newsop/standard.mn new file mode 100644 index 0000000000..0d06b3ac49 --- /dev/null +++ b/usr/doc/smm/10.newsop/standard.mn @@ -0,0 +1,1423 @@ +.ds h0 "Standard for Interchange of USENET Messages +.ds h1 +.ds h2 % +.ds f0 "\*(vr +.ds f1 +.ds f2 "January 17, 1986 +.mt +Standard for Interchange of USENET Messages +.au +Mark R. Horton +.ai +Bell Laboratories +Columbus, OH 43213 +.au +Revised for 2.10.3 by Rick Adams +.hn +Introduction +.pg +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, +whether to batch news, +and so on. +.pg +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. +.hn +Article Format +.pg +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. +(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 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. +However, +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. +.pg +An example message is included to illustrate the fields. +.sd +From: jerry@eagle.uucp (Jerry Schwarz) +Path: cbosgd!mhuxj!mhuxt!eagle!jerry +Newsgroups: net.general +Subject: Usenet Etiquette -- Please Read +Message-ID: <642@eagle.UUCP> +Date: Friday, 19 Nov 82 16:14:55 EST +Followup-To: net.news +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. +.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 articles +in this format to ease upward conversion. +.sd +From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) +Newsgroups: net.general +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 article comes here, after a blank line. +.ed +Some news systems transmit news in the +.pa A +format, +which looks like this: +.sd +Aeagle.642 +net.general +cbosgd!mhuxj!mhuxt!eagle!jerry +Fri Nov 19 16:14:55 1982 +Usenet Etiquette - Please Read +The body of the article comes here, with no blank line. +.ed +.pg +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, +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 , +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 article, +unless the +.hf Sender +header is present, +in which case the +.hf From +header might not be verified. +Note that in all site and domain names, +upper and lower case are considered the same, +thus +.cf mark@cbosgd.UUCP , +.cf mark@cbosgd.uucp , +and +.cf mark@CBosgD.UUcp +are all equivalent. +User names may or may not be case sensitive, for example, +.cf Billy@cbosgd.UUCP +might be different from +.cf BillY@cbosgd.UUCP . +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 article, +or it appears before an electronic address enclosed in angle brackets. +Thus, +the three permissible forms are: +.sd +From: mark@cbosgd.UUCP +From: mark@cbosgd.UUCP (Mark Horton) +From: Mark Horton +.ed +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, +in particular, +the characters +\&\*(lq,\*(rq (comma), +\&\*(lq:\*(rq (colon), +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 article was originally posted to the network. +This date remains unchanged as the article 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 +article 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 +The contents of the +.i TIMEZONE +field is currently subject to revision. +Eventually, +we hope to accept all possible worldwide time zone abbreviations, +including the usual American zones +(PST, +PDT, +MST, +MDT, +CST, +CDT, +EST, +EDT), +the other North American zones +(Bering through Newfoundland), +European zones, +Australian zones, +and so on. +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) +to a known time zone. +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 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. +.pg +Wildcards +.i e\f1.\fPg ., ( +the word +.ng all +are never allowed in a +.hf Newsgroups +line. +For example, +a newsgroup +.ng net.all +is illegal, +although a newsgroup name +.ng net.sport.football +is permitted.) +.pg +If an article is received with a +.hf Newsgroups +line listing some valid newsgroups and some invalid newsgroups, +a site should not remove invalid newsgroups from the list. +Instead, +the invalid newsgroups should be ignored. +For example, +suppose site +.cn A +subscribes to the classes +.ng btl.all +and +.ng net.all , +and exchanges news articles with site +.cn B , +which subscribes to +.ng net.all +but not +.ng btl.all . +Suppose +.cn A +receives an article with +.sd c +Newsgroups: net.micro,btl.general +.ed +This article is passed on to +.cn B +because +.cn B +receives +.ng net.micro , +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 reenter the +.ng btl.all +class, +resulting in an article that is not shown to users subscribing to +.ng btl.general . +Also, +followups 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 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 +.i e\f1.\fPg ., ( +is a +.i followup ) +the default subject should begin with the four characters \*(lqRe: \*(rq +and the +.hf Reference +line is required. +(The user might wish to edit the subject of the followup, +but the default should begin with \*(lqRe: \*(rq.) +.hn 3 +Message-ID +.pg +The +.hf Message-ID +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 +.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 article 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 articles submitted to the network, +or a short string derived from the date and time the article was created. +For example, +a valid message ID for an article submitted from site +.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, +nor that it is unique in the first 14 characters. +.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 +.b 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. +All characters between the angle brackets must be printing ASCII characters. +.hn 3 +Path +.pg +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 +.hf Path +line. +The names may be separated by any punctuation character or characters, +thus +.cf cbosgd!mhuxj!mhuxt , +.cf "cbosgd, mhuxj, mhuxt" , +and +.cf "@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp" +and even +.cf "teklabs, zehntel, sri-unix@cca!decvax" +are valid entries. +(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 site 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 system. +.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 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. +In particular, +when site +.cn A +sends an article to site +.cn B , +the +.hf Path +line includes +.cn A , +so that site +.cn B +will not immediately send the article back to site +.cn A . +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. +.pg +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 +.cf A!X!Y!Z +is passed from site +.cn A +to site +.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 sites 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 site name and an +.cf ! +at the front of the path, +and of starting the path with the site 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 article to the network, +and should be verified by the software at the submitting site. +.pg +For example, +if John Smith is visiting CCA and wishes to post an article to the network, +using friend Sarah Jones account, +the message might read +.sd +From: smith@ucbvax.uucp (John Smith) +Sender: jones@cca.arpa (Sarah Jones) +.ed +If a gateway program enters a mail message into the network at site +.cn sri-unix , +the lines might read +.sd +From: John.Doe@CMU-CS-A.ARPA +Sender: network@sri-unix.ARPA +.ed +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, +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 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 +.hf Newsgroups +line, +except that followups to +.ng net.general +should instead go to +.ng net.followup . +.hn 3 +Expires +.pg +This line, +if present, +is in a legal USENET date format. +It specifies a suggested expiration date for the article. +If not present, +the local default expiration date is used. +.P +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. +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 sites have local policies for expiration of news +(depending on available disk space, +for instance), +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 +.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 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 +.hf Subject +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. +If there is no +.hf References +line on the original header, +the +.hf References +line should contain the message ID of the original article +(including the angle brackets). +If the original article does have a +.hf References +line, +the followup article should have a +.hf References +line containing the text of the original +.hf References +line, +a blank, +and the message ID of the original article. +.pg +The purpose of the +.hf References +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 +.hf References +line for the benefit of systems that do use it, +and manually generated followups +.i e\f1.\fPg ., ( +typed in well after the original article has been printed by the machine) +should be encouraged to include them as well. +.hn 3 +Control +.pg +If an article contains a +.hf Control +line, +the article 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. +.hn 3 +Distribution +.pg +This line is used to alter the distribution scope of the message. +It has the same format as 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 instead of the +.hf Newsgroups +line. +Thus, +a car for sale in New Jersey might have headers including +.sd +Newsgroups: net.auto,net.wanted +Distribution: nj.all +.ed +so that it would only go to persons subscribing to +.ng net.auto +or +.ng net.wanted +within New Jersey. +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 sites outside New Jersey +that do not show such a newsgroup as valid. +Wildcards in newsgroup names in the +.hf Distribution +line are allowed. +Followup articles should default to the same +.hf Distribution +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. +.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 site 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 this article should be on +this line. This is used as an aid in determining if this article is +interesting to the reader. +.hn 3 +Summary +.pg +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. +.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. +.hn 2 +Cancel +.pg l +.sd +cancel +.ed +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. +.pg +If the system is unable to cancel the article as requested, it should not +forward the cancellation request to its neighbor systems. +.pg +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 +.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 +sendme +.ed +This message is part of the +.pa ihave/sendme +protocol, +which allows one site +(say +.cn A ) +to tell another site +.cn B ) ( +that a particular message has been received on +.cn A . +Suppose that site +.cn A +receives article +.cf ucbvax.1234 , +and wishes to transmit the article to site +.cn B . +.cn A +sends the control message +.cf "ihave ucbvax.1234 A" +to site +.cn B +(by posting it to newsgroup +.bi B ). \f3to.\fP +.cn B +responds with the control message +.cf "sendme ucbvax.1234 B" +(on newsgroup +.bi A ) \f3to.\fP +if it has not already received the article. +Upon receiving the +.pa sendme +message, +.cn A +sends the article to +.cn B . +.pg +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. +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 article 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 +.ed +.pg +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. +.hn 2 +Rmgroup +.sd +rmgroup +.ed +.pg +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. +.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 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. +A sample response: +.sd +From cbosgd!mark Sun Mar 27 20:39:37 1983 +Subject: response to your sendsys request +To: mark@cbosgd.UUCP + +Responding-System: cbosgd.UUCP +cbosgd:osg,cb,btl,bell,net,to,test +ucbvax:net,to.ucbvax:L: +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 +.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 site. +This information is used to make maps of the UUCP network. +The +.i sys +file is +.b not +the same as the UUCP +.i L.sys +file. +The +.i L.sys +file should +.b never +be transmitted to another party +without the consent of the sites whose passwords are listed therein. +.pg +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 +.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 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 +.ng not +be included, +as the reply is considered to be in the public domain. +(The +.i uuname +program will send only the site 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 is to generate and maintain UUCP mail routing maps. +Thus, connections over which mail can be sent using the +.cf site!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, +sites are free to edit the list, +deleting secret or private links they do not wish to publicize. +.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 article +.hf Reply-to "" ( +if present, +otherwise +.hf From ). +.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 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. +(On +.ux +systems, +this usually means the +.i rnews +program being run with the article on the standard input.) +.pg +It is not a requirement that USENET sites 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 site 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 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. +.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 article 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 article 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 article will never be delivered. +If the article 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 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. +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 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. +.pg +A solution to this problem is to encapsulate the news article +into a mail message, +such that the entire article +(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 article, +and then attaching whatever mail headers are convenient to generate. +The +.qp N 's +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 +(headers, +blank lines, +etc.) +from becoming part of the news article. +A program on the receiving machine receives mail to +.i rnews , +extracting the article itself and invoking the +.i rnews +program. +An example in this format might look like this: +.sd +Date: Monday, 3-Jan-83 08:33:47 MST +From: news@cbosgd.UUCP +Subject: network news article +To: rnews@npois.UUCP + +NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek +NFrom: derek@sask.UUCP (Derek Andrew) +NNewsgroups: net.test +NSubject: necessary test +NMessage-ID: <176@sask.UUCP> +NDate: Monday, 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 article) +and makes it harder for software to give different priorities +to news and mail. +.hn 2 +Batching +.pg +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. +.pg +News articles 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 article. +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" \&.) +For example, +a batch of articles might look like this: +.sd +#! rnews 207 +From: jerry@eagle.uucp (Jerry Schwarz) +Path: cbosgd!mhuxj!mhuxt!eagle!jerry +Newsgroups: net.general +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. +#! rnews 203 +From: jerry@eagle.uucp (Jerry Schwarz) +Path: cbosgd!mhuxj!mhuxt!eagle!jerry +Newsgroups: net.followup +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. +.ed +Batched news is recognized because the first character in the message is +.qp # . +The message is then passed to the unbatcher for interpretation. +.hn 1 +The News Propagation Algorithm +.pg +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. +.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 labelled with a newsgroup pattern, +specifying which newsgroup classes are forwarded along that link. +Most arcs are bidirectional, +that is, +if site +.cn A +sends a class of newsgroups to site +.cn B , +then site +.cn B +usually sends the same class of newsgroups to site +.cn A . +This bidirectionality is not, +however, +required. +.pg +USENET is made up of many subnetworks. +Each subnet has a name, +such as +.ng net +or +.ng btl . +The special subnet +.ng net +is defined to be USENET, +although the union of all subnets may be a superset of USENET +(because of sites that get local newsgroup classes but do not get +.ng net.all ). +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 sites +to be unable to post articles reaching the rest of the network.) +.pg +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. +(Site +.cn A +deems site +.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 sites receiving the incoming article examine it +to make sure they really want the article, +accept it locally, +and then in turn forward the article to all +.i their +interested neighbors. +This process continues until the entire network has seen the article. +.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 site +.cn A +sends an article to site +.cn B , +site +.cn B +will send it back to site +.cn A , +which will send it to site +.cn B , +and so on. +One solution to this is the history mechanism. +Each site keeps track of all articles it has seen +(by their message ID) +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. +.pg +One optimization is that an article 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 article originated on site +.cn A , +then site +.cn A +has already seen the article. +(Origination can be determined by the +.hf Posting-Version +line.) +.P +Thus, +if an article is posted to newsgroup +.ng net.misc , +it will match the pattern +.ng net.all +(where +.ng all +is a metasymbol that matches any string), +and will be forwarded to all sites that subscribe to +.ng net.all +(as determined by what their neighbors send them). +These sites make up the +.ng net +subnetwork. +An article posted to +.ng btl.general +will reach all sites receiving +.ng btl.all , +but will not reach sites that do not get +.ng btl.all . +In effect, +the articles reaches the +.ng btl +subnetwork. +An article posted to newsgroups +.ng net.micro,btl.general +will reach all sites subscribing to either of the two classes. -- 2.20.1