![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to standard CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10no / cmd / netnews / doc|
Return to standard CVS log | Up to [Research Unix] / researchv10no / cmd / netnews / doc |
1.1 root 1:
2:
3:
4: Standard for Interchange of USENET Messages
5:
6: Mark R. Horton
7:
8:
9:
10:
11: 1. Introduction
Introduction
Introduction
Introduction
12:
13: This document defines the standard format for interchange
14: of Network News articles among USENET sites. It describes
15: the format for articles themselves, and gives partial
16: standards for transmission of news. The news transmission
17: is not entirely standardized in order to give a good deal
18: of flexibility to the individual hosts to choose
19: transmission hardware and software, whether to batch news,
20: and so on.
21:
22: There are five sections to this document. Section two
23: section defines the format. Section three defines the
24: valid control messages. Section four specifies some valid
25: transmission methods. Section five describes the overall
26: news propagation algorithm.
27:
28:
29: 2. Article Format
Article Format
Article Format
Article Format
30:
31: The primary consideration in choosing an article format is
32: that it fit in with existing tools as well as possible.
33: Existing tools include both implementations of mail and
34: news. (The notesfiles system from the University of
__________
35: Illinois is considered a news implementation.) A standard
36: format for mail messages has existed for many years on the
37: ARPANET, and this format meets most of the needs of
38: USENET. Since the ARPANET format is extensible,
39: extensions to meet the additional needs of USENET are
40: easily made within the ARPANET standard. Therefore, the
41: rule is adopted that all USENET news articles must be
42: formatted as valid ARPANET mail messages, according to the
43: ARPANET standard RFC 822. This standard is more
44: restrictive than the ARPANET standard, placing additional
45: requirements on each article and forbidding use of certain
46: ARPANET features. However, it should always be possible
47: to use a tool expecting an ARPANET message to process a
48: news article. In any situation where this standard
49: conflicts with the ARPANET standard, RFC 822 should be
50: considered correct and this standard in error.
51:
52: An example message is included to illustrate the fields.
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70: - 2 -
71:
72:
73:
74: Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
75: Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
76: Path: cbosgd!mhuxj!mhuxt!eagle!jerry
77: From: [email protected] (Jerry Schwarz)
78: Newsgroups: net.general
79: Subject: Usenet Etiquette -- Please Read
80: Message-ID: <[email protected]>
81: Date: Friday, 19-Nov-82 16:14:55 EST
82: Followup-To: net.news
83: Expires: Saturday, 1-Jan-83 00:00:00 EST
84: Date-Received: Friday, 19-Nov-82 16:59:30 EST
85: Organization: Bell Labs, Murray Hill
86:
87: The body of the article comes here, after a blank line.
88:
89: Here is an example of a message in the old format (before
90: the existence of this standard). It is recommended that
91: implementations also accept articles in this format to
92: ease upward conversion.
93:
94: From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
95: Newsgroups: net.general
96: Title: Usenet Etiquette -- Please Read
97: Article-I.D.: eagle.642
98: Posted: Fri Nov 19 16:14:55 1982
99: Received: Fri Nov 19 16:59:30 1982
100: Expires: Mon Jan 1 00:00:00 1990
101:
102: The body of the article comes here, after a blank line.
103:
104: Some news systems transmit news in the ``A'' format, which
105: looks like this:
106:
107: Aeagle.642
108: net.general
109: cbosgd!mhuxj!mhuxt!eagle!jerry
110: Fri Nov 19 16:14:55 1982
111: Usenet Etiquette - Please Read
112: The body of the article comes here, with no blank line.
113:
114: An article consists of several header lines, followed by a
115: blank line, followed by the body of the message. The
116: header lines consist of a keyword, a colon, a blank, and
117: some additional information. This is a subset of the
118: ARPANET standard, simplified to allow simpler software to
119: handle it. The ``from'' line may optionally include a
120: full name, in the format above, or use the ARPANET angle
121: bracket syntax. To keep the implementations simple, other
122: formats (for example, with part of the machine address
123: after the close parenthesis) are not allowed. The ARPANET
124: convention of continuation header lines (beginning with a
125:
126:
127:
128:
129:
130:
131:
132:
133:
134:
135:
136: - 3 -
137:
138:
139:
140: blank or tab) is allowed.
141:
142: Certain headers are required, certain headers are
143: optional. Any unrecognized headers are allowed, and will
144: be passed through unchanged. The required headers are
145: Relay-Version, Posting-Version, From, Date, Newsgroups,
146: Subject, Message-ID, Path. The optional headers are
147: Followup-To, Date-Received, Expires, Reply-To, Sender,
148: References, Control, Distribution, Organization.
149:
150: 2.1 Required Headers
Required Headers
Required Headers
Required Headers
151:
152: 2.1.1 Relay-Version This header line shows the version
_____________
153: of the program responsible for the transmission of this
154: article over the immediate link, that is, the program that
155: is relaying the article from the next site. For example,
156: suppose site A sends an article to site B, and site B
157: forwards the article to site C. The message being
158: transmitted from A to B would have a Relay-Version header
159: identifying the program running on A, and the message
160: transmitted from B to C would identify the program running
161: on B. This header can be used to interpret older headers
162: in an upward compatible way. Relay-Version must always be
163: the first in a message; thus, all articles meeting this
164: standard will begin with an upper case ``R''. No other
165: restrictions are placed on the order of header lines.
166:
167: The line contains two fields, separated by semicolons.
168: The fields are the version and the full domain name of the
169: site. The version should identify the system program used
170: (e.g., ``B'') as well as a version number and version
171: date. For example, the header line might contain
172:
173: Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
174:
175: This header should not be passed on to additional sites.
176: A relay program, when passing an article on, should
177: include only its own Relay-Version, not the Relay-Version
178: of some other site. (For upward compatibility with older
179: software, if a Relay-Version is found in a header which is
180: not the first line, it should be assumed to be moved by an
181: older version of news and deleted.)
182:
183: 2.1.2 Posting-Version This header identifies the
_______________
184: software responsible for entering this message into the
185: network. It has the same format as Relay-Version. It
186: will normally identify the same site as the Message-ID,
187: unless the posting site is serving as a gateway for a
188: message that already contains a message ID generated by
189: mail. (While it is permissible for a gateway to use an
190: externally generated message ID, the message ID should be
191:
192:
193:
194:
195:
196:
197:
198:
199:
200:
201:
202: - 4 -
203:
204:
205:
206: checked to ensure it conforms to this standard and to RFC
207: 822.)
208:
209: 2.1.3 From The From line contains the electronic mailing
____
210: address of the person who sent the message, in the ARPA
211: internet syntax. It may optionally also contain the full
212: name of the person, in parentheses, after the electronic
213: address. The electronic address is the same as the entity
214: responsible for originating the article, unless the Sender
215: header is present, in which case the From header might not
216: be verified. Note that in all site and domain names,
217: upper and lower case are considered the same, thus
218: [email protected], [email protected], and [email protected]
219: are all equivalent. User names may or may not be case
220: sensitive, for example, [email protected] might be
221: different from [email protected]. Programs should avoid
222: changing the case of electronic addresses when forwarding
223: news or mail.
224:
225: RFC 822 specifies that all text in parentheses is to be
226: interpreted as a comment. It is common in ARPANET mail to
227: place the full name of the user in a comment at the end of
228: the From line. This standard specifies a more rigid
229: syntax. The full name is not considered a comment, but an
230: optional part of the header line. Either the full name is
231: omitted, or it appears in parentheses after the electronic
232: address of the person posting the article, or it appears
233: before an electronic address enclosed in angle brackets.
234: Thus, the three permissible forms are:
235:
236: From: [email protected]
237: From: [email protected] (Mark Horton)
238: From: Mark Horton <[email protected]>
239:
240: Full names may contain any printing ASCII characters from
241: space through tilde, with the exceptions that they may not
242: contain parentheses ``('' or ``)'', or angle brackets
243: ``<'' or ``>''. Additional restrictions may be placed on
244: full names by the mail standard, in particular, the
245: characters comma ``,'', colon ``:'', and semicolon ``;''
246: are inadvisable in full names.
247:
248: 2.1.4 Date The Date line (formerly ``Posted'') is the
____
249: date, in a format that must be acceptable both to the
250: ARPANET and to the getdate routine, that the article was
251: originally posted to the network. This date remains
252: unchanged as the article is propagated throughout the
253: network. One format that is acceptable to both is
254:
255: Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
256:
257:
258:
259:
260:
261:
262:
263:
264:
265:
266:
267:
268: - 5 -
269:
270:
271:
272: Several examples of valid dates appear in the sample
273: article above. Note in particular that ctime format:
274:
275: Wdy Mon DD HH:MM:SS YYYY
276:
277: is not acceptable because it is not a valid ARPANET date.
___
278: However, since older software still generates this format,
279: news implementations are encouraged to accept this format
280: and translate it into an acceptable format.
281:
282: The contents of the TIMEZONE field is currently subject to
283: revision. Eventually, we hope to accept all possible
284: worldwide time zone abbreviations, including the usual
285: American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
286: the other North American zones (Bering through
287: Newfoundland), European zones, Australian zones, and so
288: on. Lacking a complete list at present (and unsure if an
289: unambiguous list exists), authors of software are
290: encouraged to keep this code flexible, and in particular
291: not to assume that time zone names are exactly three
292: letters long. Implementations are free to edit this
293: field, keeping the time the same, but changing the time
294: zone (with an appropriate adjustment to the local time
295: shown) to a known time zone.
296:
297: 2.1.5 Newsgroups The Newsgroups line specifies which
__________
298: newsgroup or newsgroups the article belongs in. Multiple
299: newsgroups may be specified, separated by a comma.
300: Newsgroups specified must all be the names of existing
301: newsgroups, as no new newsgroups will be created by simply
302: posting to them.
303:
304: Wildcards (e.g., the word ``all'') are never allowed in a
305: Newsgroups line. For example, a newsgroup ``net.all'' is
306: illegal, although a newsgroup name ``net.sport.football''
307: is permitted.
308:
309: If an article is received with a Newsgroups line listing
310: some valid newsgroups and some invalid newsgroups, a site
311: should not remove invalid newsgroups from the list.
312: Instead, the invalid newsgroups should be ignored. For
313: example, suppose site A subscribes to the classes
314: ``btl.all'' and ``net.all'', and exchanges news articles
315: with site B, which subscribes to ``net.all'' but not
316: ``btl.all''. Suppose A receives an article with
317: ``Newsgroups: net.micro,btl.general''. This article is
318: passed on to B because B receives net.micro, but B does
319: not receive btl.general. A must leave the Newsgroup line
320: unchanged. If it were to remove ``btl.general'', the
321: edited header could eventually reenter the ``btl.all''
322: class, resulting in an article that is not shown to users
323:
324:
325:
326:
327:
328:
329:
330:
331:
332:
333:
334: - 6 -
335:
336:
337:
338: subscribing to ``btl.general''. Also, followups from
339: outside ``btl.all'' would not be shown to such users.
340:
341: 2.1.6 Subject The Subject line (formerly ``Title'')
_______
342: tells what the article is about. It should be suggestive
343: enough of the contents of the article to enable a reader
344: to make a decision whether to read the article based on
345: the subject alone. If the article is submitted in
346: response to another article (e.g., is a ``followup'') the
347: default subject should begin with the four characters
348: ``Re: '' and the References line is required. (The user
349: might wish to edit the subject of the followup, but the
350: default should begin with ``Re: ''.)
351:
352: 2.1.7 Message-ID The Message-ID line gives the article a
__________
353: unique identifier. The same message ID may not be reused
354: during the lifetime of any article with the same message
355: ID. (It is recommended that no message ID be reused for
356: at least two years.) Message ID's have the syntax
357:
358: "<" "string not containing blank or >" ">"
359:
360: In order to conform to RFC 822, the Message-ID must have
361: the format
362:
363: "<" "unique" "@" "full domain name" ">"
364:
365: where ``full domain name'' is the full name of the host at
366: which the article entered the network, including a domain
367: that host is in, and unique is any string of printing
368: ASCII characters, not including "<", ">", or "@". For
369: example, the "unique" part could be an integer
370: representing a sequence number for articles submitted to
371: the network, or a short string derived from the date and
372: time the article was created. For example, valid message
373: ID for an article submitted from site ucbvax in domain
374: Berkeley.ARPA would be "<[email protected]>".
375: Programmers are urged not to make assumptions about the
376: content of message ID fields from other hosts, but to
377: treat them as unknown character strings. It is not safe,
378: for example, to assume that a message ID will be under 14
379: characters, nor that it is unique in the first 14
380: characters.
381:
382: The angle brackets are considered part of the message ID.
383: Thus, in references to the message ID, such as the
384: ihave/sendme and cancel control messages, the angle
385: brackets are included. White space characters (e.g.,
386: blank and tab) are not allowed in a message ID. All
387: characters between the angle brackets must be printing
388: ASCII characters.
389:
390:
391:
392:
393:
394:
395:
396:
397:
398:
399:
400: - 7 -
401:
402:
403:
404: 2.1.8 Path This line shows the path the article took to
____
405: reach the current system. When a system forwards the
406: message, it should add its own name to the list of systems
407: in the Path line. The names may be separated by any
408: punctuation character or characters, thus
409: ``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and
410: ``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp'' and even
411: ``teklabs, zehntel, sri-unix@cca!decvax'' are valid
412: entries. (The latter path indicates a message that passed
413: through decvax, cca, sri-unix, zehntel, and teklabs, in
414: that order.) Additional names should be added from the
415: left, for example, the most recently added name in the
416: third example was ``teklabs''. Letters, digits, periods
417: and hyphens are considered part of site names; other
418: punctuation, including blanks, are considered separators.
419:
420: Normally, the rightmost name will be the name of the
421: originating system. However, it is also permissible to
422: include an extra entry on the right, which is the name of
423: the sender. This is for upward compatibility with older
424: system.
425:
426: The Path line is not used for replies, and should not be
427: taken as a mailing address. It is intended to show the
428: route the message travelled to reach the local site.
429: There are several uses for this information. One is to
430: monitor USENET routing for performance reasons. Another
431: is to establish a path to reach new sites. Perhaps the
432: most important is to cut down on redundant USENET traffic
433: by failing to forward a message to a site that is known to
434: have already received it. In particular, when site A
435: sends an article to site B, the Path line includes ``A'',
436: so that site B will not immediately send the article back
437: to site A. The site name each site uses to identify
438: itself should be the same as the name by which its
439: neighbors know it, in order to make this optimization
440: possible.
441:
442: A site adds its own name to the front of a path when it
443: receives a message from another site. Thus, if a message
444: with path A!X!Y!Z is passed from site A to site B, B will
445: add its own name to the path when it receives the message
446: from A, e.g., B!A!X!Y!Z. If B then passes the message on
447: to C, the message sent to C will contain the path
448: B!A!X!Y!Z, and when C receives it, C will change it to
449: C!B!A!X!Y!Z.
450:
451: Special upward compatibility note: Since the From, Sender,
452: and Reply-To lines are in internet format, and since many
453: USENET sites do not yet have mailers capable of
454: understanding internet format, it would break the reply
455:
456:
457:
458:
459:
460:
461:
462:
463:
464:
465:
466: - 8 -
467:
468:
469:
470: capability to completely sever the connection between the
471: Path header and the reply function. Thus, sites are
472: required to continue to keep the Path line in a working
473: reply format as much as possible, until January 1, 1984.
474: It is recognized that the path is not always a valid reply
475: string in older implementations, and no requirement to fix
476: this problem is placed on implementations. However, the
477: existing convention of placing the site name and an ``!''
478: at the front of the path, and of starting the path with
479: the site name, an ``!'', and the user name, should be
480: maintained at least until 1984.
481:
482: 2.2 Optional Headers
Optional Headers
Optional Headers
Optional Headers
483:
484: 2.2.1 Reply-To This line has the same format as From.
________
485: If present, mailed replies to the author should be sent to
486: the name given here. Otherwise, replies are mailed to the
487: name on the From line. (This does not prevent additional
488: copies from being sent to recipients named by the replier,
489: or on To or Cc lines.) The full name may be optionally
490: given, in parentheses, as in the From line.
491:
492: 2.2.2 Sender This field is present only if the submitter
______
493: manually enters a From line. It is intended to record the
494: entity responsible for submitting the article to the
495: network, and should be verified by the software at the
496: submitting site.
497:
498: For example, if John Smith is visiting CCA and wishes to
499: post an article to the network, using friend Sarah Jones
500: account, the message might read
501:
502: From: [email protected] (John Smith)
503: Sender: [email protected] (Sarah Jones)
504:
505: If a gateway program enters a mail message into the
506: network at site sri-unix, the lines might read
507:
508: From: [email protected]
509: Sender: [email protected]
510:
511: The primary purpose of this field is to be able to track
512: down articles to determine how they were entered into the
513: network. The full name may be optionally given, in
514: parentheses, as in the From line.
515:
516: 2.2.3 Followup-To This line has the same format as
___________
517: Newsgroups. If present, follow-up articles are to be
518: posted to the newsgroup(s) listed here. If this line is
519: not present, followups are posted to the newsgroup(s)
520: listed in the Newsgroups line, except that followups to
521:
522:
523:
524:
525:
526:
527:
528:
529:
530:
531:
532: - 9 -
533:
534:
535:
536: ``net.general'' should instead go to ``net.followup''.
537:
538: 2.2.4 Date-Received This line (formerly ``Received'') is
_____________
539: in a legal USENET date format. It records the date and
540: time that the article was first received on the local
541: system. If this line is present in an article being
542: transmitted from one host to another, the receiving host
543: should ignore it and replace it with the current date.
544: Since this field is intended for local use only, no site
545: is required to support it. However, no site should pass
546: this field on to another site unchanged.
547:
548: 2.2.5 Expires This line, if present, is in a legal
_______
549: USENET date format. It specifies a suggested expiration
550: date for the article. If not present, the local default
551: expiration date is used.
552:
553: This field is intended to be used to clean up articles
554: with a limited usefulness, or to keep important articles
555: around for longer than usual. For example, a message
556: announcing an upcoming seminar could have an expiration
557: date the day after the seminar, since the message is not
558: useful after the seminar is over. Since local sites have
559: local policies for expiration of news (depending on
560: available disk space, for instance), users are discouraged
561: from providing expiration dates for articles unless there
562: is a natural expiration date associated with the topic.
563: System software should almost never provide a default
564: Expires line. Leave it out and allow local policies to be
565: used unless there is a good reason not to.
566:
567: 2.2.6 References This field lists the message ID's of
__________
568: any articles prompting the submission of this article. It
569: is required for all follow-up articles, and forbidden when
570: a new subject is raised. Implementations should provide a
571: follow-up command, which allows a user to post a follow-up
572: article. This command should generate a Subject line
573: which is the same as the original article, except that if
574: the original subject does not begin with ``Re: '' or ``re:
575: '', the four characters ``Re: '' are inserted before the
576: subject. If there is no References line on the original
577: header, the References line should contain the message ID
578: of the original article (including the angle brackets).
579: If the original article does have a References line, the
580: followup article should have a References line containing
581: the text of the original References line, a blank, and the
582: message ID of the original article.
583:
584: The purpose of the References header is to allow articles
585: to be grouped into conversations by the user interface
586: program. This allows conversations within a newsgroup to
587:
588:
589:
590:
591:
592:
593:
594:
595:
596:
597:
598: - 10 -
599:
600:
601:
602: be kept together, and potentially users might shut off
603: entire conversations without unsubscribing to a newsgroup.
604: User interfaces may not make use of this header, but all
605: automatically generated followups should generate the
606: References line for the benefit of systems that do use it,
607: and manually generated followups (e.g. typed in well after
608: the original article has been printed by the machine)
609: should be encouraged to include them as well.
610:
611: 2.2.7 Control If an article contains a Control line, the
_______
612: article is a control message. Control messages are used
613: for communication among USENET host machines, not to be
614: read by users. Control messages are distributed by the
615: same newsgroup mechanism as ordinary messages. The body
616: of the Control header line is the message to the host.
617:
618: For upward compatibility, messages that match the
619: newsgroup pattern ``all.all.ctl'' should also be
620: interpreted as control messages. If no Control: header is
621: present on such messages, the subject is used as the
622: control message. However, messages on newsgroups matching
623: this pattern do not conform to this standard.
624:
625: 2.2.8 Distribution This line is used to alter the
____________
626: distribution scope of the message. It has the same format
627: as the Newsgroups line. User subscriptions are still
628: controlled by Newsgroups, but the message is sent to all
629: systems subscribing to the newsgroups on the Distribution
630: line instead of the Newsgroups line. Thus, a car for sale
631: in New Jersey might have headers including
632:
633: Newsgroups: net.auto,net.wanted
634: Distribution: nj.all
635:
636: so that it would only go to persons subscribing to
637: net.auto or net.wanted within New Jersey. The intent of
638: this header is to further restrict the distribution of a
639: newsgroup, not to increase it. A local newsgroup, such as
640: nj.crazy-eddie, will probably not be propagated by sites
641: outside New Jersey that do not show such a newsgroup as
642: valid. Wildcards in newsgroup names in the Distribution
643: line are allowed. Followup articles should default to the
644: same Distribution line as the original article, but the
645: user can change it to a more limited one, or escalate the
646: distribution if it was originally restricted and a more
647: widely distributed reply is appropriate.
648:
649: 2.2.9 Organization The text of this line is a short
____________
650: phrase describing the organization to which the sender
651: belongs, or to which the machine belongs. The intent of
652: this line is to help identify the person posting the
653:
654:
655:
656:
657:
658:
659:
660:
661:
662:
663:
664: - 11 -
665:
666:
667:
668: message, since site names are often cryptic enough to make
669: it hard to recognize the organization by the electronic
670: address.
671:
672:
673: 3. Control Messages
Control Messages
Control Messages
Control Messages
674:
675: This section lists the control messages currently defined.
676: The body of the Control header is the control message.
677: Messages are a sequence of zero or more words, separated
678: by white space (blanks or tabs). The first word is the
679: name of the control message, remaining words are
680: parameters to the message. The remainder of the header
681: and the body of the message are also potential parameters;
682: for example, the From line might suggest an address to
683: which a response is to be mailed.
684:
685: Implementors and administrators may choose to allow
686: control messages to be automatically carried out, or to
687: queue them for manual processing. However, manually
688: processed messages should be dealt with promptly.
689:
690: 3.1 Cancel
Cancel
Cancel
Cancel
691:
692: cancel <message ID>
693:
694: If an article with the given message ID is present on the
695: local system, the article is cancelled. This mechanism
696: allows a user to cancel an article after the article has
697: been distributed over the network.
698:
699: Only the author of the article or the local super user is
700: allowed to use this message. The verified sender of a
701: message is the Sender line, or if no Sender line is
702: present, the From line. The verified sender of the cancel
703: message must be the same as either the Sender or From
704: field of the original message. A verified sender in the
705: cancel message is allowed to match an unverified From in
706: the original message.
707:
708: 3.2 Ihave/Sendme
Ihave/Sendme
Ihave/Sendme
Ihave/Sendme
709:
710: ihave <message ID list> <remotesys>
711: sendme <message ID list> <remotesys>
712:
713: This message is part of the ``ihave/sendme'' protocol,
714: which allows one site (say ``A'') to tell another site
715: (``B'') that a particular message has been received on A.
716: Suppose that site A receives article ``ucbvax.1234'', and
717: wishes to transmit the article to site B. A sends the
718: control message ``ihave ucbvax.1234 A'' to site B (by
719:
720:
721:
722:
723:
724:
725:
726:
727:
728:
729:
730: - 12 -
731:
732:
733:
734: posting it to newsgroup ``to.B''). B responds with the
735: control message ``sendme ucbvax.1234 B'' (on newsgroup
736: to.A) if it has not already received the article. Upon
737: receiving the Sendme message, A sends the article to B.
738:
739: This protocol can be used to cut down on redundant traffic
740: between sites. It is optional and should be used only if
741: the particular situation makes it worthwhile. Frequently,
742: the outcome is that, since most original messages are
743: short, and since there is a high overhead to start sending
744: a new message with UUCP, it costs as much to send the
745: Ihave as it would cost to send the article itself.
746:
747: One possible solution to this overhead problem is to batch
748: requests. Several message ID's may be announced or
749: requested in one message. If no message ID's are listed
750: in the control message, the body of the message should be
751: scanned for message ID's, one per line.
752:
753: 3.3 Newgroup
Newgroup
Newgroup
Newgroup
754:
755: newgroup <groupname>
756:
757: This control message creates a new newsgroup with the name
758: given. Since no articles may be posted or forwarded until
759: a newsgroup is created, this message is required before a
760: newsgroup can be used. The body of the message is
761: expected to be a short paragraph describing the intended
762: use of the newsgroup.
763:
764: 3.4 Rmgroup
Rmgroup
Rmgroup
Rmgroup
765:
766: rmgroup <groupname>
767:
768: This message removes a newsgroup with the given name.
769: Since the newsgroup is removed from every site on the
770: network, this command should be used carefully by a
771: responsible administrator.
772:
773: 3.5 Sendsys
Sendsys
Sendsys
Sendsys
774:
775: sendsys (no arguments)
776:
777: The ``sys'' file, listing all neighbors and which
778: newsgroups are sent to each neighbor, will be mailed to
779: the author of the control message (Reply-to, if present,
780: otherwise From). This information is considered public
781: information, and it is a requirement of membership in
782: USENET that this information be provided on request,
783: either automatically in response to this control message,
784: or manually, by mailing the requested information to the
785:
786:
787:
788:
789:
790:
791:
792:
793:
794:
795:
796: - 13 -
797:
798:
799:
800: author of the message. This information is used to keep
801: the map of USENET up to date, and to determine where
802: netnews is sent.
803:
804: The format of the file mailed back to the author should be
805: the same as that of the ``sys'' file. This format has one
806: line per neighboring site (plus one line for the local
807: site), containing four colon separated fields. The first
808: field has the site name of the neighbor, the second field
809: has a newsgroup pattern describing the newsgroups sent to
810: the neighbor. The third and fourth fields are not defined
811: by this standard. A sample response:
812:
813: From cbosgd!mark Sun Mar 27 20:39:37 1983
814: Subject: response to your sendsys request
815: To: [email protected]
816:
817: Responding-System: cbosgd.UUCP
818: cbosgd:osg,cb,btl,bell,net,fa,to,test
819: ucbvax:net,fa,to.ucbvax:L:
820: cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
821: cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
822: sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
823: npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
824: mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
825:
826: 3.6 Senduuname
Senduuname
Senduuname
Senduuname
827:
828: senduuname (no arguments)
829:
830: The ``uuname'' program is run, and the output is mailed to
831: the author of the control message (Reply-to, if present,
832: otherwise From). This program lists all uucp neighbors of
833: the local site. This information is used to make maps of
834: the UUCP network. The sys file is not the same as the
___
835: UUCP L.sys file. The L.sys file should never be
_____
836: transmitted to another party without the consent of the
837: sites whose passwords are listed therein.
838:
839: It is optional for a site to provide this information.
840: Some reply should be made to the author of the control
841: message, so that a transmission error won't be blamed. It
842: is also permissible for a site to run the uuname program
843: (or in some other way determine the uucp neighbors) and
844: edit the output, either automatically or manually, before
845: mailing the reply back to the author. The file should
846: contain one site per line, beginning with the uucp site
847: name. Additional information may be included, separated
848: from the site name by a blank or tab. The phone number or
849: password for the site should NOT be included, as the reply
850: is considered to be in the public domain. (The uuname
851:
852:
853:
854:
855:
856:
857:
858:
859:
860:
861:
862: - 14 -
863:
864:
865:
866: program will send only the site name and not the entire
867: contents of the L.sys file, thus, phone numbers and
868: passwords are not transmitted.)
869:
870: The purpose of this message is to generate and maintain
871: UUCP mail routing maps. Thus, connections over which mail
872: can be sent using the site!user syntax should be included,
873: regardless of whether the link is actually a UUCP link at
874: the physical level. If a mail router should use it, it
875: should be included. Since all information sent in
876: response to this message is optional, sites are free to
877: edit the list, deleting secret or private links they do
878: not wish to publicise.
879:
880: 3.7 Version
Version
Version
Version
881:
882: version (no arguments)
883:
884: The name and version of the software running on the local
885: system is to be mailed back to the author of the article
886: (Reply-to if present, otherwise From).
887:
888:
889: 4. Transmission Methods
Transmission Methods
Transmission Methods
Transmission Methods
890:
891: USENET is not a physical network, but rather a logical
892: network resting on top of several existing physical
893: networks. These networks include, but are not limited to,
894: UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC
895: Hyperchannel, and a Berknet. What is important is that
896: two neighboring systems on USENET have some method to get
897: a new article, in the format listed here, from one system
898: to the other, and once on the receiving system, processed
899: by the netnews software on that system. (On UNIX systems,
900: this usually means the ``rnews'' program being run with
901: the article on the standard input.)
902:
903: It is not a requirement that USENET sites have mail
904: systems capable of understanding the ARPA Internet mail
905: syntax, but it is strongly recommended. Since From,
906: Reply-To, and Sender lines use the Internet syntax,
907: replies will be difficult or impossible without an
908: internet mailer. A site without an internet mailer can
909: attempt to use the Path header line for replies, but this
910: field is not guaranteed to be a working path for replies.
911: In any event, any site generating or forwarding news
912: messages must have an internet address that allows them to
913: receive mail from sites with internet mailers, and they
914: must include their internet address on their From line.
915:
916:
917:
918:
919:
920:
921:
922:
923:
924:
925:
926:
927:
928: - 15 -
929:
930:
931:
932: 4.1 Remote Execution
Remote Execution
Remote Execution
Remote Execution
933:
934: Some networks permit direct remote command execution. On
935: these networks, news may be forwarded by spooling the
936: rnews command with the article on the standard input. For
937: example, if the remote system is called ``remote'', news
938: would be sent over a UUCP link with the command ``uux -
939: remote!rnews'', and on a Berknet, ``net -mremote rnews''.
940: It is important that the article be sent via a reliable
941: mechansim, normally involving the possibility of spooling,
942: rather than direct real-time remote execution. This is
943: because, if the remote system is down, a direct execution
944: command will fail, and the article will never be
945: delivered. If the article is spooled, it will eventually
946: be delivered when both systems are up.
947:
948: 4.2 Transfer by Mail
Transfer by Mail
Transfer by Mail
Transfer by Mail
949:
950: On some systems, direct remote spooled execution is not
951: possible. However, most systems support electronic mail,
952: and a news article can be sent as mail. One approach is
953: to send a mail message which is identical to the news
954: message: the mail headers are the news headers, and the
955: mail body is the news body. By convention, this mail is
956: sent to the user ``newsmail'' on the remote machine.
957:
958: One problem with this method is that it may not be
959: possible to convince the mail system that the From line of
960: the message is valid, since the mail message was generated
961: by a program on a system different from the source of the
962: news article. Another problem is that error messages
963: caused by the mail transmission would be sent to the
964: originator of the news article, who has no control over
965: news transmission between two cooperating hosts and does
966: not know who to contact. Transmission error messages
967: should be directed to a responsible contact person on the
968: sending machine.
969:
970: A solution to this problem is to encapsulate the news
971: article into a mail message, such that the entire article
972: (headers and body) are part of the body of the mail
973: message. The convention here is that such mail is sent to
974: user ``rnews'' on the remote system. A mail message body
975: is generated by prepending the letter ``N'' to each line
976: of the news article, and then attaching whatever mail
977: headers are convenient to generate. The N's are attached
978: to prevent any special lines in the news article from
979: interfering with mail transmission, and to prevent any
980: extra lines inserted by the mailer (headers, blank lines,
981: etc.) from becoming part of the news article. A program
982: on the receiving machine receives mail to ``rnews'',
983:
984:
985:
986:
987:
988:
989:
990:
991:
992:
993:
994: - 16 -
995:
996:
997:
998: extracting the article itself and invoking the ``rnews''
999: program. An example in this format might look like this:
1000:
1001: Date: Monday, 3-Jan-83 08:33:47 MST
1002: From: [email protected]
1003: Subject: network news article
1004: To: [email protected]
1005:
1006: NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
1007: NPosting-Version: B 2.9 6/21/82 sask.UUCP
1008: NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
1009: NFrom: [email protected] (Derek Andrew)
1010: NNewsgroups: net.test
1011: NSubject: necessary test
1012: NMessage-ID: <[email protected]>
1013: NDate: Monday, 3-Jan-83 00:59:15 MST
1014: N
1015: NThis really is a test. If anyone out there more than 6
1016: Nhops away would kindly confirm this note I would
1017: Nappreciate it. We suspect that our news postings
1018: Nare not getting out into the world.
1019: N
1020:
1021:
1022: Using mail solves the spooling problem, since mail must
1023: always be spooled if the destination host is down.
1024: However, it adds more overhead to the transmission process
1025: (to encapsulate and extract the article) and makes it
1026: harder for software to give different priorities to news
1027: and mail.
1028:
1029: 4.3 Batching
Batching
Batching
Batching
1030:
1031: Since news articles are usually short, and since a large
1032: number of messages are often sent between two sites in a
1033: day, it may make sense to batch news articles. Several
1034: articles can be combined into one large article, using
1035: conventions agreed upon in advance by the two sites. One
1036: such batching scheme is described here; its use is still
1037: considered experimental.
1038:
1039: News articles are combined into a script, separated by a
1040: header of the form:
1041:
1042: ##! rnews 1234
1043:
1044: where 1234 is the length, in bytes, of the article. Each
1045: such line is followed by an article containing the given
1046: number of bytes. (The newline at the end of each line of
1047: the article is counted as one byte, for purposes of this
1048: count, even if it is stored as CRLF.) For example, a batch
1049:
1050:
1051:
1052:
1053:
1054:
1055:
1056:
1057:
1058:
1059:
1060: - 17 -
1061:
1062:
1063:
1064: of articles might look like this:
1065:
1066: #! rnews 374
1067: Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
1068: Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
1069: Path: cbosgd!mhuxj!mhuxt!eagle!jerry
1070: From: [email protected] (Jerry Schwarz)
1071: Newsgroups: net.general
1072: Subject: Usenet Etiquette -- Please Read
1073: Message-ID: <[email protected]>
1074: Date: Friday, 19-Nov-82 16:14:55 EST
1075:
1076: Here is an important message about USENET Etiquette.
1077: #! rnews 378
1078: Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
1079: Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
1080: Path: cbosgd!mhuxj!mhuxt!eagle!jerry
1081: From: [email protected] (Jerry Schwarz)
1082: Newsgroups: net.followup
1083: Subject: Notes on Etiquette article
1084: Message-ID: <[email protected]>
1085: Date: Friday, 19-Nov-82 17:24:12 EST
1086:
1087: There was something I forgot to mention in the last message.
1088:
1089: Batched news is recognized because the first character in
1090: the message is ``#''. The message is then passed to the
1091: unbatcher for interpretation.
1092:
1093:
1094: 5. The News Propagation Algorithm
The News Propagation Algorithm
The News Propagation Algorithm
The News Propagation Algorithm
1095:
1096: This section describes the overall scheme of USENET and
1097: the algorithm followed by sites in propagating news to the
1098: entire network. Since all sites are affected by
1099: incorrectly formatted articles and by propagation errors,
1100: it is important for the method to be standardized.
1101:
1102: USENET is a directed graph. Each node in the graph is a
1103: host computer, each arc in the graph is a transmission
1104: path from one host to another host. Each arc is labelled
1105: with a newsgroup pattern, specifying which newsgroup
1106: classes are forwarded along that link. Most arcs are
1107: bidirectional, that is, if site A sends a class of
1108: newsgroups to site B, then site B usually sends the same
1109: class of newsgroups to site A. This bidirectionality is
1110: not, however, required.
1111:
1112: USENET is made up of many subnetworks. Each subnet has a
1113: name, such as ``net'' or ``btl''. The special subnet
1114: ``net'' is defined to be USENET, although the union of all
1115:
1116:
1117:
1118:
1119:
1120:
1121:
1122:
1123:
1124:
1125:
1126: - 18 -
1127:
1128:
1129:
1130: subnets may be a superset of USENET (because of sites that
1131: get local newsgroup classes but do not get net.all). Each
1132: subnet is a connected graph, that is, a path exists from
1133: every node to every other node in the subnet. In
1134: addition, the entire graph is (theoretically) connected.
1135: (In practice, some political considerations have caused
1136: some sites to be unable to post articles reaching the rest
1137: of the network.)
1138:
1139: An article is posted on one machine to a list of
1140: newsgroups. That machine accepts it locally, then
1141: forwards it to all its neighbors that are interested in at
1142: least one of the newsgroups of the message. (Site A deems
1143: site B to be ``interested'' in a newsgroup if the
1144: newsgroup matches the pattern on the arc from A to B.
1145: This pattern is stored in a file on the A machine.) The
1146: sites receiving the incoming article examine it to make
1147: sure they really want the article, accept it locally, and
1148: then in turn forward the article to all their interested
_____
1149: neighbors. This process continues until the entire
1150: network has seen the article.
1151:
1152: An important part of the algorithm is the prevention of
1153: loops. The above process would cause a message to loop
1154: along a cycle forever. In particular, when site A sends
1155: an article to site B, site B will send it back to site A,
1156: which will send it to site B, and so on. One solution to
1157: this is the history mechanism. Each site keeps track of
1158: all articles it has seen (by their message ID) and
1159: whenever an article comes in that it has already seen, the
1160: incoming article is discarded immediately. This solution
1161: is sufficient to prevent loops, but additional
1162: optimizations can be made to avoid sending articles to
1163: sites that will simply throw them away.
1164:
1165: One optimization is that an article should never be sent
1166: to a machine listed in the Path line of the header. When
1167: a machine name is in the Path line, the message is known
1168: to have passed through the machine. Another optimization
1169: is that, if the article originated on site A, then site A
1170: has already seen the article. (Origination can be
1171: determined by the Posting-Version line.)
1172:
1173: Thus, if an article is posted to newsgroup ``net.misc'',
1174: it will match the pattern ``net.all'' (where ``all'' is a
1175: metasymbol that matches any string), and will be forwarded
1176: to all sites that subscribe to net.all (as determined by
1177: what their neighbors send them). These sites make up the
1178: ``net'' subnetwork. An article posted to ``btl.general''
1179: will reach all sites receiving ``btl.all'', but will not
1180: reach sites that do not get ``btl.all''. In effect, the
1181:
1182:
1183:
1184:
1185:
1186:
1187:
1188:
1189:
1190:
1191:
1192: - 19 -
1193:
1194:
1195:
1196: articles reaches the ``btl'' subnetwork. An article
1197: posted to newsgroups ``net.micro,btl.general'' will reach
1198: all sites subscribing to either of the two classes.
1199:
1200:
1201:
1202:
1203:
1204:
1205:
1206:
1207:
1208:
1209:
1210:
1211:
1212:
1213:
1214:
1215:
1216:
1217:
1218:
1219:
1220:
1221:
1222:
1223:
1224:
1225:
1226:
1227:
1228:
1229:
1230:
1231:
1232:
1233:
1234:
1235:
1236:
1237:
1238:
1239:
1240:
1241:
1242:
1243:
1244:
1245:
1246:
1247:
1248:
1249:
1250:
1251:
1252:
1253:
1254:
1255:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.