1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="robots" content="index,follow">
<meta name="creator" content="rfcmarkup version 1.109">
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
<meta name="DC.Relation.Replaces" content="rfc850">
<meta name="DC.Identifier" content="urn:ietf:rfc:1036">
<meta name="DC.Date.Issued" content="December, 1987">
<meta name="DC.Creator" content="Adams, R.">
<meta name="DC.Creator" content="Horton, M.R.">
<meta name="DC.Description.Abstract" content="This RFC defines the standard format for the interchange of network
News messages among USENET hosts. It updates and replaces RFC-850,
reflecting version B2.11 of the News program. This memo is distributed
as an RFC to make this information easily accessible to the Internet
community. It does not specify an Internet standard.">
<meta name="DC.Title" content="Standard for interchange of USENET messages">
<link rel="icon" href="index_files/rfc.png" type="image/png">
<link rel="shortcut icon" href="index_files/rfc.png" type="image/png">
<title>RFC 1036 - Standard for interchange of USENET messages</title>
<style type="text/css"><!--
/* Effective stylesheet produced by snapshot save */
body { margin: 0px 8px; font-size: 1em; }
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
.pre { white-space: pre; font-family: monospace; }
.newpage { page-break-before: always; }
.invisible { text-decoration: none; color: white; }
a.selflink { color: black; text-decoration: none; }
@media print {
body { font-family: monospace; font-size: 10.5pt; }
h1, h2, h3, h4, h5, h6 { font-size: 1em; }
a:link, a:visited { color: inherit; text-decoration: none; }
.noprint { display: none; }
}
@media screen {
.grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
.docinfo { background-color: rgb(238, 238, 238); }
.top { border-top: 7px solid rgb(238, 238, 238); }
.bgbrown { background-color: rgb(136, 68, 0); }
.legend { font-size: 90%; }
}
--></style>
<!--[if IE]>
<style>
body {
font-size: 13px;
margin: 10px 10px;
}
</style>
<![endif]-->
<script type="text/javascript"><!--
/* Script removed by snapshot save */
--></script>
</head>
<body onload="">
<div style="height: 13px;">
<div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgbrown" title="Click for colour legend."> </div>
<div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout="">
</div>
</div>
<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc1036.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc1036" title="PDF version of this document">pdf</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=1036">Errata</a>] </span><br>
<span class="pre noprint docinfo"> </span><br>
<span class="pre noprint docinfo">Obsoleted by: <a href="https://tools.ietf.org/html/rfc5536">5536</a>, <a href="https://tools.ietf.org/html/rfc5537">5537</a> </span><br>
<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br>
<pre>Network Working Group M. Horton
Request for Comments: 1036 AT&T Bell Laboratories
Obsoletes: <a href="https://tools.ietf.org/html/rfc850">RFC-850</a> R. Adams
Center for Seismic Studies
December 1987
<span class="h1"><h1>Standard for Interchange of USENET Messages</h1></span>
STATUS OF THIS MEMO
This document defines the standard format for the interchange of
network News messages among USENET hosts. It updates and replaces
<a href="https://tools.ietf.org/html/rfc850">RFC-850</a>, reflecting version B2.11 of the News program. This memo is
disributed as an RFC to make this information easily accessible to
the Internet community. It does not specify an Internet standard.
Distribution of this memo is unlimited.
<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span>
This document defines the standard format for the interchange of
network News messages among USENET hosts. It describes the format
for messages themselves and gives partial standards for transmission
of news. The news transmission is not entirely in order to give a
good deal of flexibility to the hosts to choose transmission
hardware and software, to batch news, and so on.
There are five sections to this document. Section two defines the
format. Section three defines the valid control messages. Section
four specifies some valid transmission methods. Section five
describes the overall news propagation algorithm.
<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Message Format</h2></span>
The primary consideration in choosing a message format is that it
fit in with existing tools as well as possible. Existing tools
include implementations of both mail and news. (The notesfiles
system from the University of Illinois is considered a news
implementation.) A standard format for mail messages has existed
for many years on the Internet, and this format meets most of the
needs of USENET. Since the Internet format is extensible,
extensions to meet the additional needs of USENET are easily made
within the Internet standard. Therefore, the rule is adopted that
all USENET news messages must be formatted as valid Internet mail
messages, according to the Internet standard <a href="https://tools.ietf.org/html/rfc822">RFC-822</a>. The USENET
News standard is more restrictive than the Internet standard,
<span class="grey">Horton & Adams [Page 1]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
placing additional requirements on each message and forbidding use
of certain Internet features. However, it should always be possible
to use a tool expecting an Internet message to process a news
message. In any situation where this standard conflicts with the
Internet standard, <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> should be considered correct and this
standard in error.
Here is an example USENET message to illustrate the fields.
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 GMT
Followup-To: news.misc
Expires: Sat, 1 Jan 83 00:00:00 -0500
Organization: AT&T Bell Laboratories, Murray Hill
The body of the message comes here, after a blank line.
Here is an example of a message in the old format (before the
existence of this standard). It is recommended that
implementations also accept messages in this format to ease upward
conversion.
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: news.misc
Title: Usenet Etiquette -- Please Read
Article-I.D.: eagle.642
Posted: Fri Nov 19 16:14:55 1982
Received: Fri Nov 19 16:59:30 1982
Expires: Mon Jan 1 00:00:00 1990
The body of the message comes here, after a blank line.
Some news systems transmit news in the A format, which looks like
this:
Aeagle.642
news.misc
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
The body of the message comes here, with no blank line.
A standard USENET message consists of several header lines, followed
by a blank line, followed by the body of the message. Each header
<span class="grey">Horton & Adams [Page 2]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
line consist of a keyword, a colon, a blank, and some additional
information. This is a subset of the Internet standard, simplified
to allow simpler software to handle it. The "From" line may
optionally include a full name, in the format above, or use the
Internet angle bracket syntax. To keep the implementations simple,
other formats (for example, with part of the machine address after
the close parenthesis) are not allowed. The Internet convention of
continuation header lines (beginning with a blank or tab) is
allowed.
Certain headers are required, and certain other headers are
optional. Any unrecognized headers are allowed, and will be passed
through unchanged. The required header lines are "From", "Date",
"Newsgroups", "Subject", "Message-ID", and "Path". The optional
header lines are "Followup-To", "Expires", "Reply-To", "Sender",
"References", "Control", "Distribution", "Keywords", "Summary",
"Approved", "Lines", "Xref", and "Organization". Each of these
header lines will be described below.
<span class="h3"><h3><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a>. Required Header lines</h3></span>
<span class="h4"><h4><a class="selflink" name="section-2.1.1" href="#section-2.1.1">2.1.1</a>. From</h4></span>
The "From" line contains the electronic mailing address of the
person who sent the message, in the Internet syntax. It may
optionally also contain the full name of the person, in parentheses,
after the electronic address. The electronic address is the same as
the entity responsible for originating the message, unless the
"Sender" header is present, in which case the "From" header might
not be verified. Note that in all host and domain names, upper and
lower case are considered the same, thus "mark@cbosgd.ATT.COM",
"mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
User names may or may not be case sensitive, for example,
"Billy@cbosgd.ATT.COM" might be different from
"BillY@cbosgd.ATT.COM". Programs should avoid changing the case of
electronic addresses when forwarding news or mail.
<a href="https://tools.ietf.org/html/rfc822">RFC-822</a> specifies that all text in parentheses is to be interpreted
as a comment. It is common in Internet mail to place the full name
of the user in a comment at the end of the "From" line. This
standard specifies a more rigid syntax. The full name is not
considered a comment, but an optional part of the header line.
Either the full name is omitted, or it appears in parentheses after
the electronic address of the person posting the message, or it
appears before an electronic address which is enclosed in angle
brackets. Thus, the three permissible forms are:
<span class="grey">Horton & Adams [Page 3]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
From: mark@cbosgd.ATT.COM
From: mark@cbosgd.ATT.COM (Mark Horton)
From: Mark Horton <mark@cbosgd.ATT.COM>
Full names may contain any printing ASCII characters from space
through tilde, except that they may not contain "(" (left
parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
">" (right angle bracket). Additional restrictions may be placed on
full names by the mail standard, in particular, the characters ","
(comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
(equal), and ";" (semicolon) are inadvisable in full names.
<span class="h4"><h4><a class="selflink" name="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Date</h4></span>
The "Date" line (formerly "Posted") is the date that the message was
originally posted to the network. Its format must be acceptable
both in <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> and to the getdate(3) routine that is provided with
the Usenet software. This date remains unchanged as the message is
propagated throughout the network. One format that is acceptable to
both is:
Wdy, DD Mon YY HH:MM:SS TIMEZONE
Several examples of valid dates appear in the sample message above.
Note in particular that ctime(3) format:
Wdy Mon DD HH:MM:SS YYYY
is not acceptable because it is not a valid <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> date. However,
since older software still generates this format, news
implementations are encouraged to accept this format and translate
it into an acceptable format.
There is no hope of having a complete list of timezones. Universal
Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
CDT, EST, EDT) and the +/-hhmm offset specifed in <a href="https://tools.ietf.org/html/rfc822">RFC-822</a> should be
supported. It is recommended that times in message headers be
transmitted in GMT and displayed in the local time zone.
<span class="h4"><h4><a class="selflink" name="section-2.1.3" href="#section-2.1.3">2.1.3</a>. Newsgroups</h4></span>
The "Newsgroups" line specifies the newsgroup or newsgroups in which
the message belongs. Multiple newsgroups may be specified,
separated by a comma. Newsgroups specified must all be the names of
existing newsgroups, as no new newsgroups will be created by simply
posting to them.
<span class="grey">Horton & Adams [Page 4]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
Wildcards (e.g., the word "all") are never allowed in a "News-
groups" line. For example, a newsgroup comp.all is illegal,
although a newsgroup rec.sport.football is permitted.
If a message is received with a "Newsgroups" line listing some valid
newsgroups and some invalid newsgroups, a host should not remove
invalid newsgroups from the list. Instead, the invalid newsgroups
should be ignored. For example, suppose host A subscribes to the
classes btl.all and comp.all, and exchanges news messages with host
B, which subscribes to comp.all but not btl.all. Suppose A receives
a message with Newsgroups: comp.unix,btl.general.
This message is passed on to B because B receives comp.unix, but B
does not receive btl.general. A must leave the "Newsgroups" line
unchanged. If it were to remove btl.general, the edited header
could eventually re-enter the btl.all class, resulting in a message
that is not shown to users subscribing to btl.general. Also,
follow-ups from outside btl.all would not be shown to such users.
<span class="h4"><h4><a class="selflink" name="section-2.1.4" href="#section-2.1.4">2.1.4</a>. Subject</h4></span>
The "Subject" line (formerly "Title") tells what the message is
about. It should be suggestive enough of the contents of the
message to enable a reader to make a decision whether to read the
message based on the subject alone. If the message is submitted in
response to another message (e.g., is a follow-up) the default
subject should begin with the four characters "Re:", and the
"References" line is required. For follow-ups, the use of the
"Summary" line is encouraged.
<span class="h4"><h4><a class="selflink" name="section-2.1.5" href="#section-2.1.5">2.1.5</a>. Message-ID</h4></span>
The "Message-ID" line gives the message a unique identifier. The
Message-ID may not be reused during the lifetime of any previous
message with the same Message-ID. (It is recommended that no
Message-ID be reused for at least two years.) Message-ID's have the
syntax:
<string not containing blank or ">">
In order to conform to <a href="https://tools.ietf.org/html/rfc822">RFC-822</a>, the Message-ID must have the format:
<unique@full_domain_name>
where full_domain_name is the full name of the host at which the
message entered the network, including a domain that host is in, and
unique is any string of printing ASCII characters, not including "<"
(left angle bracket), ">" (right angle bracket), or "@" (at sign).
<span class="grey">Horton & Adams [Page 5]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
For example, the unique part could be an integer representing a
sequence number for messages submitted to the network, or a short
string derived from the date and time the message was created. For
example, a valid Message-ID for a message submitted from host ucbvax
in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
Programmers are urged not to make assumptions about the content of
Message-ID fields from other hosts, but to treat them as unknown
character strings. It is not safe, for example, to assume that a
Message-ID will be under 14 characters, that it is unique in the
first 14 characters, nor that is does not contain a "/".
The angle brackets are considered part of the Message-ID. Thus, in
references to the Message-ID, such as the ihave/sendme and cancel
control messages, the angle brackets are included. White space
characters (e.g., blank and tab) are not allowed in a Message-ID.
Slashes ("/") are strongly discouraged. All characters between the
angle brackets must be printing ASCII characters.
<span class="h4"><h4><a class="selflink" name="section-2.1.6" href="#section-2.1.6">2.1.6</a>. Path</h4></span>
This line shows the path the message took to reach the current
system. When a system forwards the message, it should add its own
name to the list of systems in the "Path" line. The names may be
separated by any punctuation character or characters (except "."
which is considered part of the hostname). Thus, the following are
valid entries:
cbosgd!mhuxj!mhuxt
cbosgd, mhuxj, mhuxt
@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
teklabs, zehntel, sri-unix@cca!decvax
(The latter path indicates a message that passed through decvax,
cca, sri-unix, zehntel, and teklabs, in that order.) Additional
names should be added from the left. For example, the most recently
added name in the fourth example was teklabs. Letters, digits,
periods and hyphens are considered part of host names; other
punctuation, including blanks, are considered separators.
Normally, the rightmost name will be the name of the originating
system. However, it is also permissible to include an extra entry
on the right, which is the name of the sender. This is for upward
compatibility with older systems.
The "Path" line is not used for replies, and should not be taken as
a mailing address. It is intended to show the route the message
traveled to reach the local host. There are several uses for this
information. One is to monitor USENET routing for performance
<span class="grey">Horton & Adams [Page 6]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
reasons. Another is to establish a path to reach new hosts.
Perhaps the most important use is to cut down on redundant USENET
traffic by failing to forward a message to a host that is known to
have already received it. In particular, when host A sends a
message to host B, the "Path" line includes A, so that host B will
not immediately send the message back to host A. The name each host
uses to identify itself should be the same as the name by which its
neighbors know it, in order to make this optimization possible.
A host adds its own name to the front of a path when it receives a
message from another host. Thus, if a message with path "A!X!Y!Z"
is passed from host A to host B, B will add its own name to the path
when it receives the message from A, e.g., "B!A!X!Y!Z". If B then
passes the message on to C, the message sent to C will contain the
path "B!A!X!Y!Z", and when C receives it, C will change it to
"C!B!A!X!Y!Z".
Special upward compatibility note: Since the "From", "Sender", and
"Reply-To" lines are in Internet format, and since many USENET hosts
do not yet have mailers capable of understanding Internet format, it
would break the reply capability to completely sever the connection
between the "Path" header and the reply function. It is recognized
that the path is not always a valid reply string in older
implementations, and no requirement to fix this problem is placed on
implementations. However, the existing convention of placing the
host name and an "!" at the front of the path, and of starting the
path with the host name, an "!", and the user name, should be
maintained when possible.
<span class="h3"><h3><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a>. Optional Headers</h3></span>
<span class="h4"><h4><a class="selflink" name="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Reply-To</h4></span>
This line has the same format as "From". If present, mailed replies
to the author should be sent to the name given here. Otherwise,
replies are mailed to the name on the "From" line. (This does not
prevent additional copies from being sent to recipients named by the
replier, or on "To" or "Cc" lines.) The full name may be optionally
given, in parentheses, as in the "From" line.
<span class="h4"><h4><a class="selflink" name="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Sender</h4></span>
This field is present only if the submitter manually enters a "From"
line. It is intended to record the entity responsible for
submitting the message to the network. It should be verified by the
software at the submitting host.
<span class="grey">Horton & Adams [Page 7]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
For example, if John Smith is visiting CCA and wishes to post a
message to the network, using friend Sarah Jones' account, the
message might read:
From: smith@ucbvax.Berkeley.EDU (John Smith)
Sender: jones@cca.COM (Sarah Jones)
If a gateway program enters a mail message into the network at host
unix.SRI.COM, the lines might read:
From: John.Doe@A.CS.CMU.EDU
Sender: network@unix.SRI.COM
The primary purpose of this field is to be able to track down
messages to determine how they were entered into the network. The
full name may be optionally given, in parentheses, as in the "From"
line.
<span class="h4"><h4><a class="selflink" name="section-2.2.3" href="#section-2.2.3">2.2.3</a>. Followup-To</h4></span>
This line has the same format as "Newsgroups". If present, follow-
up messages are to be posted to the newsgroup or newsgroups listed
here. If this line is not present, follow-ups are posted to the
newsgroup or newsgroups listed in the "Newsgroups" line.
If the keyword poster is present, follow-up messages are not
permitted. The message should be mailed to the submitter of the
message via mail.
<span class="h4"><h4><a class="selflink" name="section-2.2.4" href="#section-2.2.4">2.2.4</a>. Expires</h4></span>
This line, if present, is in a legal USENET date format. It
specifies a suggested expiration date for the message. If not
present, the local default expiration date is used. This field is
intended to be used to clean up messages with a limited usefulness,
or to keep important messages around for longer than usual. For
example, a message announcing an upcoming seminar could have an
expiration date the day after the seminar, since the message is not
useful after the seminar is over. Since local hosts have local
policies for expiration of news (depending on available disk space,
for instance), users are discouraged from providing expiration dates
for messages unless there is a natural expiration date associated
with the topic. System software should almost never provide a
default "Expires" line. Leave it out and allow local policies to be
used unless there is a good reason not to.
<span class="grey">Horton & Adams [Page 8]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
<span class="h4"><h4><a class="selflink" name="section-2.2.5" href="#section-2.2.5">2.2.5</a>. References</h4></span>
This field lists the Message-ID's of any messages prompting the
submission of this message. It is required for all follow-up
messages, and forbidden when a new subject is raised.
Implementations should provide a follow-up command, which allows a
user to post a follow-up message. This command should generate a
"Subject" line which is the same as the original message, except
that if the original subject does not begin with "Re:" or "re:", the
four characters "Re:" are inserted before the subject. If there is
no "References" line on the original header, the "References" line
should contain the Message-ID of the original message (including the
angle brackets). If the original message does have a "References"
line, the follow-up message should have a "References" line
containing the text of the original "References" line, a blank, and
the Message-ID of the original message.
The purpose of the "References" header is to allow messages to be
grouped into conversations by the user interface program. This
allows conversations within a newsgroup to be kept together, and
potentially users might shut off entire conversations without
unsubscribing to a newsgroup. User interfaces need not make use of
this header, but all automatically generated follow-ups should
generate the "References" line for the benefit of systems that do
use it, and manually generated follow-ups (e.g., typed in well after
the original message has been printed by the machine) should be
encouraged to include them as well.
It is permissible to not include the entire previous "References"
line if it is too long. An attempt should be made to include a
reasonable number of backwards references.
<span class="h4"><h4><a class="selflink" name="section-2.2.6" href="#section-2.2.6">2.2.6</a>. Control</h4></span>
If a message contains a "Control" line, the message is a control
message. Control messages are used for communication among USENET
host machines, not to be read by users. Control messages are
distributed by the same newsgroup mechanism as ordinary messages.
The body of the "Control" header line is the message to the host.
For upward compatibility, messages that match the newsgroup pattern
"all.all.ctl" should also be interpreted as control messages. If no
"Control" header is present on such messages, the subject is used as
the control message. However, messages on newsgroups matching this
pattern do not conform to this standard.
<span class="grey">Horton & Adams [Page 9]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
Also for upward compatibility, if the first 4 characters of the
"Subject:" line are "cmsg", the rest of the "Subject:" line should
be interpreted as a control message.
<span class="h4"><h4><a class="selflink" name="section-2.2.7" href="#section-2.2.7">2.2.7</a>. Distribution</h4></span>
This line is used to alter the distribution scope of the message.
It is a comma separated list similar to the "Newsgroups" line. User
subscriptions are still controlled by "Newsgroups", but the message
is sent to all systems subscribing to the newsgroups on the
"Distribution" line in addition to the "Newsgroups" line. For the
message to be transmitted, the receiving site must normally receive
one of the specified newsgroups AND must receive one of the
specified distributions. Thus, a message concerning a car for sale
in New Jersey might have headers including:
Newsgroups: rec.auto,misc.forsale
Distribution: nj,ny
so that it would only go to persons subscribing to rec.auto or misc.
for sale within New Jersey or New York. The intent of this header
is to restrict the distribution of a newsgroup further, not to
increase it. A local newsgroup, such as nj.crazy-eddie, will
probably not be propagated by hosts outside New Jersey that do not
show such a newsgroup as valid. A follow-up message should default
to the same "Distribution" line as the original message, but the
user can change it to a more limited one, or escalate the
distribution if it was originally restricted and a more widely
distributed reply is appropriate.
<span class="h4"><h4><a class="selflink" name="section-2.2.8" href="#section-2.2.8">2.2.8</a>. Organization</h4></span>
The text of this line is a short phrase describing the organization
to which the sender belongs, or to which the machine belongs. The
intent of this line is to help identify the person posting the
message, since host names are often cryptic enough to make it hard
to recognize the organization by the electronic address.
<span class="h4"><h4><a class="selflink" name="section-2.2.9" href="#section-2.2.9">2.2.9</a>. Keywords</h4></span>
A few well-selected keywords identifying the message should be on
this line. This is used as an aid in determining if this message is
interesting to the reader.
<span class="h4"><h4><a class="selflink" name="section-2.2.10" href="#section-2.2.10">2.2.10</a>. Summary</h4></span>
This line should contain a brief summary of the message. It is
usually used as part of a follow-up to another message. Again, it
<span class="grey">Horton & Adams [Page 10]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
is very useful to the reader in determining whether to read the
message.
<span class="h4"><h4><a class="selflink" name="section-2.2.11" href="#section-2.2.11">2.2.11</a>. Approved</h4></span>
This line is required for any message posted to a moderated
newsgroup. It should be added by the moderator and consist of his
mail address. It is also required with certain control messages.
<span class="h4"><h4><a class="selflink" name="section-2.2.12" href="#section-2.2.12">2.2.12</a>. Lines</h4></span>
This contains a count of the number of lines in the body of the
message.
<span class="h4"><h4><a class="selflink" name="section-2.2.13" href="#section-2.2.13">2.2.13</a>. Xref</h4></span>
This line contains the name of the host (with domains omitted) and a
white space separated list of colon-separated pairs of newsgroup
names and message numbers. These are the newsgroups listed in the
"Newsgroups" line and the corresponding message numbers from the
spool directory.
This is only of value to the local system, so it should not be
transmitted. For example, in:
Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
From: reid@decwrl.DEC.COM (Brian Reid)
Newsgroups: news.lists,news.groups
Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
Message-ID: <5658@decwrl.DEC.COM>
Date: 1 Oct 86 11:26:15 GMT
Organization: DEC Western Research Laboratory
Lines: 441
Approved: reid@decwrl.UUCP
Xref: seismo news.lists:461 news.groups:6378
the "Xref" line shows that the message is message number 461 in the
newsgroup news.lists, and message number 6378 in the newsgroup
news.groups, on host seismo. This information may be used by
certain user interfaces.
<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. Control Messages</h2></span>
This section lists the control messages currently defined. The body
of the "Control" header line is the control message. Messages are a
sequence of zero or more words, separated by white space (blanks or
tabs). The first word is the name of the control message, remaining
words are parameters to the message. The remainder of the header
<span class="grey">Horton & Adams [Page 11]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
and the body of the message are also potential parameters; for
example, the "From" line might suggest an address to which a
response is to be mailed.
Implementors and administrators may choose to allow control messages
to be carried out automatically, or to queue them for annual
processing. However, manually processed messages should be dealt
with promptly.
Failed control messages should NOT be mailed to the originator of
the message, but to the local "usenet" account.
<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Cancel</h3></span>
cancel <Message-ID>
If a message with the given Message-ID is present on the local
system, the message is cancelled. This mechanism allows a user to
cancel a message after the message has been distributed over the
network.
If the system is unable to cancel the message as requested, it
should not forward the cancellation request to its neighbor systems.
Only the author of the message or the local news administrator is
allowed to send this message. The verified sender of a message is
the "Sender" line, or if no "Sender" line is present, the "From"
line. The verified sender of the cancel message must be the same as
either the "Sender" or "From" field of the original message. A
verified sender in the cancel message is allowed to match an
unverified "From" in the original message.
<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Ihave/Sendme</h3></span>
ihave <Message-ID list> [<remotesys>]
sendme <Message-ID list> [<remotesys>]
This message is part of the ihave/sendme protocol, which allows one
host (say A) to tell another host (B) that a particular message has
been received on A. Suppose that host A receives message
"<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to
host B.
A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to
host B (by posting it to newsgroup to.B). B responds with the
control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup
to.A), if it has not already received the message. Upon receiving
<span class="grey">Horton & Adams [Page 12]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
the sendme message, A sends the message to B.
This protocol can be used to cut down on redundant traffic between
hosts. It is optional and should be used only if the particular
situation makes it worthwhile. Frequently, the outcome is that,
since most original messages are short, and since there is a high
overhead to start sending a new message with UUCP, it costs as much
to send the ihave as it would cost to send the message itself.
One possible solution to this overhead problem is to batch requests.
Several Message-ID's may be announced or requested in one message.
If no Message-ID's are listed in the control message, the body of
the message should be scanned for Message-ID's, one per line.
<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Newgroup</h3></span>
newgroup <groupname> [moderated]
This control message creates a new newsgroup with the given name.
Since no messages may be posted or forwarded until a newsgroup is
created, this message is required before a newsgroup can be used.
The body of the message is expected to be a short paragraph
describing the intended use of the newsgroup.
If the second argument is present and it is the keyword moderated,
the group should be created moderated instead of the default of
unmoderated. The newgroup message should be ignored unless there is
an "Approved" line in the same message header.
<span class="h3"><h3><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Rmgroup</h3></span>
rmgroup <groupname>
This message removes a newsgroup with the given name. Since the
newsgroup is removed from every host on the network, this command
should be used carefully by a responsible administrator. The
rmgroup message should be ignored unless there is an "Approved:"
line in the same message header.
<span class="grey">Horton & Adams [Page 13]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
<span class="h3"><h3><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Sendsys</h3></span>
<span class="h3"><h3> sendsys (no arguments)</h3></span>
The sys file, listing all neighbors and the newsgroups to be sent to
each neighbor, will be mailed to the author of the control message
("Reply-To", if present, otherwise "From"). This information is
considered public information, and it is a requirement of membership
in USENET that this information be provided on request, either
automatically in response to this control message, or manually, by
mailing the requested information to the author of the message.
This information is used to keep the map of USENET up to date, and
to determine where netnews is sent.
The format of the file mailed back to the author should be the same
as that of the sys file. This format has one line per neighboring
host (plus one line for the local host), containing four colon
separated fields. The first field has the host name of the
neighbor, the second field has a newsgroup pattern describing the
newsgroups sent to the neighbor. The third and fourth fields are
not defined by this standard. The sys file is not the same as the
UUCP L.sys file. A sample response is:
From: cbosgd!mark (Mark Horton)
Date: Sun, 27 Mar 83 20:39:37 -0500
Subject: response to your sendsys request
To: mark@cbosgd.ATT.COM
Responding-System: cbosgd.ATT.COM
cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
test
ucbvax:world,comp,to.ucbvax:L:
cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
/sescent
npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
<span class="h3"><h3><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a>. Version</h3></span>
version (no arguments)
The name and version of the software running on the local system is
to be mailed back to the author of the message ("Reply-to" if
present, otherwise "From").
<span class="h3"><h3><a class="selflink" name="section-3.7" href="#section-3.7">3.7</a>. Checkgroups</h3></span>
<span class="grey">Horton & Adams [Page 14]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
The message body is a list of "official" newsgroups and their
description, one group per line. They are compared against the list
of active newsgroups on the current host. The names of any obsolete
or new newsgroups are mailed to the user "usenet" and descriptions
of the new newsgroups are added to the help file used when posting
news.
<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. Transmission Methods</h2></span>
USENET is not a physical network, but rather a logical network
resting on top of several existing physical networks. These
networks include, but are not limited to, UUCP, the Internet, an
Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
What is important is that two neighboring systems on USENET have
some method to get a new message, in the format listed here, from
one system to the other, and once on the receiving system, processed
by the netnews software on that system. (On UNIX systems, this
usually means the rnews program being run with the message on the
standard input. <1>)
It is not a requirement that USENET hosts have mail systems capable
of understanding the Internet mail syntax, but it is strongly
recommended. Since "From", "Reply-To", and "Sender" lines use the
Internet syntax, replies will be difficult or impossible without an
Internet mailer. A host without an Internet mailer can attempt to
use the "Path" header line for replies, but this field is not
guaranteed to be a working path for replies. In any event, any host
generating or forwarding news messages must have an Internet address
that allows them to receive mail from hosts with Internet mailers,
and they must include their Internet address on their From line.
<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Remote Execution</h3></span>
Some networks permit direct remote command execution. On these
networks, news may be forwarded by spooling the rnews command with
the message on the standard input. For example, if the remote
system is called remote, news would be sent over a UUCP link
with the command:
uux - remote!rnews
and on a Berknet:
net -mremote rnews
<span class="grey">Horton & Adams [Page 15]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
It is important that the message be sent via a reliable mechanism,
normally involving the possibility of spooling, rather than direct
real-time remote execution. This is because, if the remote system
is down, a direct execution command will fail, and the message will
never be delivered. If the message is spooled, it will eventually
be delivered when both systems are up.
<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Transfer by Mail</h3></span>
On some systems, direct remote spooled execution is not possible.
However, most systems support electronic mail, and a news message
can be sent as mail. One approach is to send a mail message which
is identical to the news message: the mail headers are the news
headers, and the mail body is the news body. By convention, this
mail is sent to the user newsmail on the remote machine.
One problem with this method is that it may not be possible to
convince the mail system that the "From" line of the message is
valid, since the mail message was generated by a program on a
system different from the source of the news message. Another
problem is that error messages caused by the mail transmission
would be sent to the originator of the news message, who has no
control over news transmission between two cooperating hosts
and does not know whom to contact. Transmission error messages
should be directed to a responsible contact person on the
sending machine.
A solution to this problem is to encapsulate the news message into a
mail message, such that the entire message (headers and body) are
part of the body of the mail message. The convention here is that
such mail is sent to user rnews on the remote system. A mail
message body is generated by prepending the letter N to each line of
the news message, and then attaching whatever mail headers are
convenient to generate. The N's are attached to prevent any special
lines in the news message from interfering with mail transmission,
and to prevent any extra lines inserted by the mailer (headers,
blank lines, etc.) from becoming part of the news message. A
program on the receiving machine receives mail to rnews, extracting
the message itself and invoking the rnews program. An example in
this format might look like this:
<span class="grey">Horton & Adams [Page 16]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
Date: Mon, 3 Jan 83 08:33:47 MST
From: news@cbosgd.ATT.COM
Subject: network news message
To: rnews@npois.ATT.COM
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: misc.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Mon, 3 Jan 83 00:59:15 MST
N
NThis really is a test. If anyone out there more than 6
Nhops away would kindly confirm this note I would
Nappreciate it. We suspect that our news postings
Nare not getting out into the world.
N
Using mail solves the spooling problem, since mail must always be
spooled if the destination host is down. However, it adds more
overhead to the transmission process (to encapsulate and extract the
message) and makes it harder for software to give different
priorities to news and mail.
<span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. Batching</h3></span>
Since news messages are usually short, and since a large number of
messages are often sent between two hosts in a day, it may make
sense to batch news messages. Several messages can be combined into
one large message, using conventions agreed upon in advance by the
two hosts. One such batching scheme is described here; its use is
highly recommended.
News messages are combined into a script, separated by a header of
the form:
#! rnews 1234
where 1234 is the length of the message in bytes. Each such line is
followed by a message containing the given number of bytes. (The
newline at the end of each line of the message is counted as one
byte, for purposes of this count, even if it is stored as <CARRIAGE
RETURN><LINE FEED>.) For example, a batch of message might look
like this:
<span class="grey">Horton & Adams [Page 17]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
#! rnews 239
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 EST
Approved: mark@cbosgd.ATT.COM
Here is an important message about USENET Etiquette.
#! rnews 234
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Notes on Etiquette message
Message-ID: <643@eagle.ATT.COM>
Date: Fri, 19 Nov 82 17:24:12 EST
Approved: mark@cbosgd.ATT.COM
There was something I forgot to mention in the last
message.
Batched news is recognized because the first character in the
message is #. The message is then passed to the unbatcher for
interpretation.
The second argument (in this example rnews) determines which
batching scheme is being used. Cooperating hosts may use whatever
scheme is appropriate for them.
<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. The News Propagation Algorithm</h2></span>
This section describes the overall scheme of USENET and the
algorithm followed by hosts in propagating news to the entire
logical network. Since all hosts are affected by incorrectly
formatted messages and by propagation errors, it is important
for the method to be standardized.
USENET is a directed graph. Each node in the graph is a host
computer, and each arc in the graph is a transmission path from
one host to another host. Each arc is labeled with a newsgroup
pattern, specifying which newsgroup classes are forwarded along
that link. Most arcs are bidirectional, that is, if host A
sends a class of newsgroups to host B, then host B usually sends
the same class of newsgroups to host A. This bidirectionality
is not, however, required.
USENET is made up of many subnetworks. Each subnet has a name, such
<span class="grey">Horton & Adams [Page 18]</span>
</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a>
<span class="grey"><a href="#">RFC 1036</a> Standard for USENET Messages December 1987</span>
as comp or btl. Each subnet is a connected graph, that is, a path
exists from every node to every other node in the subnet. In
addition, the entire graph is (theoretically) connected. (In
practice, some political considerations have caused some hosts to be
unable to post messages reaching the rest of the network.)
A message is posted on one machine to a list of newsgroups. That
machine accepts it locally, then forwards it to all its neighbors
that are interested in at least one of the newsgroups of the
message. (Site A deems host B to be "interested" in a newsgroup if
the newsgroup matches the pattern on the arc from A to B. This
pattern is stored in a file on the A machine.) The hosts receiving
the incoming message examine it to make sure they really want the
message, accept it locally, and then in turn forward the message to
all their interested neighbors. This process continues until the
entire network has seen the message.
An important part of the algorithm is the prevention of loops. The
above process would cause a message to loop along a cycle forever.
In particular, when host A sends a message to host B, host B will
send it back to host A, which will send it to host B, and so on.
One solution to this is the history mechanism. Each host keeps
track of all messages it has seen (by their Message-ID) and
whenever a message comes in that it has already seen, the incoming
message is discarded immediately. This solution is sufficient to
prevent loops, but additional optimizations can be made to avoid
sending messages to hosts that will simply throw them away.
One optimization is that a message should never be sent to a machine
listed in the "Path" line of the header. When a machine name is
in the "Path" line, the message is known to have passed through the
machine. Another optimization is that, if the message originated
on host A, then host A has already seen the message. Thus, if a
message is posted to newsgroup misc.misc, it will match the pattern
misc.all (where all is a metasymbol that matches any string), and
will be forwarded to all hosts that subscribe to misc.all (as
determined by what their neighbors send them). These hosts make up
the misc subnetwork. A message posted to btl.general will reach all
hosts receiving btl.all, but will not reach hosts that do not get
btl.all. In effect, the messages reaches the btl subnetwork. A
messages posted to newsgroups misc.misc,btl.general will reach all
hosts subscribing to either of the two classes.
Notes
<1> UNIX is a registered trademark of AT&T.
Horton & Adams [Page 19]
</pre><br>
<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.109, available from
<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a>
</small></small></span>
</body></html>
|
