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