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