-
-
Notifications
You must be signed in to change notification settings - Fork 2
/
rfc2980.txt
1515 lines (999 loc) · 55.8 KB
/
rfc2980.txt
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
Network Working Group S. Barber
Request for Comments: 2980 Academ Consulting Services
Category: Informational October 2000
Common NNTP Extensions
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
In this document, a number of popular extensions to the Network News
Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
and discussed. While this document is not intended to serve as a
standard of any kind, it will hopefully serve as a reference document
for future implementers of the NNTP protocol. In the role, this
document would hopefully create the possibility for some level of
interoperability among implementations that make use of extensions.
Introduction
RFC 977 [1] defines the NNTP protocol and was released over a decade
ago. Since then, NNTP has become one of the most popular protocols
in use on the Internet. Many implementations of the protocol have
been created on many different platforms and operating systems. With
the growth in use of the protocol, work began on a revision to NNTP
in 1991, but that work did not result in a new standard protocol
specification. However, many ideas from that working group did find
their way into many implementations of NNTP. Additionally, many
other extensions, often created by newsreader authors, are also in
use. This document will capture and define all known extensions to
NNTP available in official NNTP server releases of some type as of
this writing. Where possible, the server software first implementing
a particular extension will be noted. It is the hope of the author
that using this document in tandem with RFC 977 will limit the
addition of new extensions that essentially do the same thing.
Software developers may wish to use this document and others [2] as a
resource for the development of new software.
Barber Informational [Page 1]
RFC 2980 Common NNTP Extensions October 2000
This document does not specify an Internet Standard of any kind. It
only attempts to document current practices. While this document may
clarify some ambiguity in RFC 977, RFC 977 should be regarded as
authoritative in all cases. There are some implementations that are
not strictly RFC 977 compliant and where necessary, these deviations
from the standard will be noted. This document does reflect the work
of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
Barber.
This document is provided to help implementers have a uniform source
of information about extensions, however, it is important for any
prospective implementer to understand that the extensions listed here
are NOT part of any current standard for NNTP. In fact, some of the
ones listed in this document should not be included in new NNTP
implementations as they should no longer be used modern NNTP
environments. Such commands should be considered historic and are
documented as such in this document.
Extensions fall into three categories: transport, newsreader and
other. Transport extensions are additions to the NNTP specification
that were made specifically to move news articles from one server to
another server. Newsreader extensions are additions to the NNTP
specification that were made to assist NNTP clients in selecting and
retrieving news articles from servers. Other extensions to the NNTP
specification are those which did not specifically fall into either
of the other two categories. Examples of other extensions include
authentication and time-of-day extensions. For each command, the
format of section 3 of RFC 977 will be used.
1. Transport Extensions
A transport extension is one which is primarily used in inter-server
communications. Following are the descriptions of each transport
extension commands and the responses which will be returned by those
commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted. A parameter that may be
repeated is followed by an ellipsis.
Barber Informational [Page 2]
RFC 2980 Common NNTP Extensions October 2000
1.1.1 The CHECK command
CHECK <message-id>
CHECK is used by a peer to discover if the article with the specified
message-id should be sent to the server using the TAKETHIS command.
The peer does not have to wait for a response from the server before
sending the next command.
From using the responses to the sequence of CHECK commands, a list of
articles to be sent can be constructed for subsequent use by the
TAKETHIS command.
The use of the CHECK command for streaming is optional. Some
implementations will directly use the TAKETHIS command and send all
articles in the send queue on that peer for the server.
On some implementations, the use of the CHECK command is not
permitted when the server is in slave mode (via the SLAVE command).
Responses that are of the form X3X must specify the message-id in the
response.
1.1.2. Responses
238 no such article found, please send it to me
400 not accepting articles
431 try sending it again later
438 already have it, please don't send it to me
480 Transfer permission denied
500 Command not understood
1.2.1 The MODE STREAM command
MODE STREAM
MODE STREAM is used by a peer to indicate to the server that it would
like to suspend the lock step conversational nature of NNTP and send
commands in streams. This command should be used before TAKETHIS and
CHECK. See the section on the commands TAKETHIS and CHECK for more
details.
1.2.2. Responses
203 Streaming is OK
500 Command not understood
Barber Informational [Page 3]
RFC 2980 Common NNTP Extensions October 2000
1.3.1 The TAKETHIS command
TAKETHIS <message-id>
TAKETHIS is used to send articles to a server when in streaming mode.
The entire article (header and body, in that sequence) is sent
immediately after the peer sends the TAKETHIS command. The peer does
not have to wait for a response from the server before sending the
next command and the associated article.
During transmission of the article, the peer should send the entire
article, including header and body, in the manner specified for text
transmission from the server. See RFC 977, Section 2.4.1 for
details.
Responses that are of the form X3X must specify the message-id in the
response.
1.3.2. Responses
239 article transferred ok
400 not accepting articles
439 article transfer failed
480 Transfer permission denied
500 Command not understood
1.4.1 The XREPLIC command
XREPLIC ggg:nnn[,ggg:nnn...]
The XREPLIC command makes is possible to exactly duplicate the news
spool structure of one server in another server. It first appeared
in INN.
This command works similarly to the IHAVE command as specified in RFC
977. The same response codes are used. The command line arguments
consist of entries separated by a single comma. Each entry consists
of a news group name, a colon, and an article number. If the server
responds with a 335 response, the article should be filed in the news
group(s) and article number(s) specified in the XREPLIC command line.
If the server cannot do successfully install the article once it has
accepted it, a 436 or 437 response code can be used to indicate the
failure.
This command should only be used when the receiving server is being
fed by only one other server. It is likely that when used with
servers that have multiple feeds that this command will frequently
fail.
Barber Informational [Page 4]
RFC 2980 Common NNTP Extensions October 2000
XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
INN now has the ability to slave servers via transparent means,
simply by having the article's Xref header transferred. (In previous
versions, this header was generated locally and stripped off on
outgoing feeds.)
It is likely that future versions of INN will no longer support
XREPLIC.
1.4.2. Responses
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again
2. Newsreader Extensions
Newsreader extensions are those which are primarily used by
newsreading clients. Following are the descriptions of each
newsreader extension commands and the responses which will be
returned by those commands.
Each command is shown in upper case for clarity, although case is
ignored in the interpretation of commands by the NNTP server. Any
parameters are shown in lower case. A parameter shown in [square
brackets] is optional. For example, [GMT] indicates that the
triglyph GMT may present or omitted. A parameter that may be
repeated is followed by an ellipsis. Mutually exclusive parameters
are separated by a vertical bar (|) character. For example,
ggg|<message-id> indicates that a group name or a <message-id> may
be specified, but not both. Some parameters, notably <message-id>,
is case specific. See RFC 1036 for these details.
Also, certain commands make use of a pattern for selection of
multiple news groups. The pattern in all cases is based on the
wildmat [4] format introduced by Rich Salz in 1986. Arguments
expected to be in wildmat format will be represented by the string
wildmat. This format is discussed in detail in section 3.3 of this
document.
2.1.1 Extensions to the LIST command
The original LIST command took no arguments in RFC 977 and returned
the contents of the active file in a specific format. Since the
original newsreaders made use of other information available in the
news transport software in addition to the active file, extensions to
Barber Informational [Page 5]
RFC 2980 Common NNTP Extensions October 2000
the LIST command were created to make that information available to
NNTP newsreaders. There may be other extensions to the LIST command
that simply return the contents of a file. This approach is
suggested over the addition of over verbs. For example, LIST MOTD
could be used instead of adding XMOTD.
2.1.2 LIST ACTIVE
LIST ACTIVE [wildmat]
LIST ACTIVE is exactly the same as the LIST command specified in RFC
977. The responses and the format should exactly match the LIST
command without arguments. If the optional matching parameter is
specified, the list is limited to only the groups that match the
pattern. Specifying a single group is usually very efficient for the
server, and multiple groups may be specified by using wildmat
patterns (described later in this document), not regular expressions.
If nothing is matched an empty list is returned, not an error. This
command first appeared in the UNIX reference version.
2.1.3 LIST ACTIVE.TIMES
LIST ACTIVE.TIMES
The active.times file is maintained by some news transports systems
to contain information about the when and who created a particular
news group. The format of this file generally include three fields.
The first field is the name of the news group. The second is the
time when this group was created on this news server measured in
seconds since January 1, 1970. The third is the email address of the
entity that created the news group. When executed, the information
is displayed following the 215 response. When display is completed,
the server will send a period on a line by itself. If the
information is not available, the server will return the 503 error
response. This command first appeared in the UNIX reference version.
2.1.3.1 Responses
215 information follows
503 program error, function not performed
2.1.4 LIST DISTRIBUTIONS
LIST DISTRIBUTIONS
The distributions file is maintained by some news transport systems
to contain information about valid values for the Distribution: line
in a news article header and about what the values mean. Each line
Barber Informational [Page 6]
RFC 2980 Common NNTP Extensions October 2000
contains two fields, the value and a short explanation on the meaning
of the value. When executed, the information is displayed following
the 215 response. When display is completed, the server will send a
period on a line by itself. If the information is not available, the
server will return the 503 error response. This command first
appeared in the UNIX reference version.
2.1.4.1 Responses
215 information follows
503 program error, function not performed
2.1.5 LIST DISTRIB.PATS
LIST DISTRIB.PATS
The distrib.pats file is maintained by some news transport systems to
contain default values for the Distribution: line in a news article
header when posting to particular news groups. This information
could be used to provide a default value for the Distribution: line
in the header when posting an article. The information returned
involves three fields separated by colons. The first column is a
weight. The second is a group name or a pattern that can be used to
match a group name in the wildmat format. The third is the value of
the Distribution: line that should be used when the group name
matches and the weight value is the highest. All this processing is
done by the news posting client and not by the server itself. The
server just provides this information to the client for it to use or
ignore as it chooses. When executed, the information is displayed
following the 215 response. When display is completed, the server
will send a period on a line by itself. If the information is not
available, the server will return the 503 error response. This
command first appeared in INN.
2.1.5.1 Responses
215 information follows
503 program error, function not performed
2.1.6 LIST NEWSGROUPS
LIST NEWSGROUPS [wildmat]
The newsgroups file is maintained by some news transport systems to
contain the name of each news group which is active on the server and
a short description about the purpose of each news group. Each line
in the file contains two fields, the news group name and a short
explanation of the purpose of that news group. When executed, the
Barber Informational [Page 7]
RFC 2980 Common NNTP Extensions October 2000
information is displayed following the 215 response. When display is
completed, the server will send a period on a line by itself. If the
information is not available, the server will return the 503
response. If the optional matching parameter is specified, the list
is limited to only the groups that match the pattern (no matching is
done on the group descriptions). Specifying a single group is
usually very efficient for the server, and multiple groups may be
specified by using wildmat patterns (similar to file globbing), not
regular expressions. If nothing is matched an empty list is
returned, not an error.
When the optional parameter is specified, this command is equivalent
to the XGTITLE command, though the response code are different.
215 information follows
503 program error, function not performed
2.1.7 LIST OVERVIEW.FMT
LIST OVERVIEW.FMT
The overview.fmt file is maintained by some news transport systems to
contain the order in which header information is stored in the
overview databases for each news group. When executed, news article
header fields are displayed one line at a time in the order in which
they are stored in the overview database [5] following the 215
response. When display is completed, the server will send a period
on a line by itself. If the information is not available, the server
will return the 503 response.
Please note that if the header has the word "full" (without quotes)
after the colon, the header's name is prepended to its field in the
output returned by the server.
Many newsreaders work better if Xref: is one of the optional fields.
It is STRONGLY recommended that this command be implemented in any
server that implements the XOVER command. See section 2.8 for more
details about the XOVER command.
2.1.7.1 Responses
215 information follows
503 program error, function not performed
Barber Informational [Page 8]
RFC 2980 Common NNTP Extensions October 2000
2.1.8 LIST SUBSCRIPTIONS
LIST SUBSCRIPTIONS
This command is used to get a default subscription list for new users
of this server. The order of groups is significant.
When this list is available, it is preceded by the 215 response and
followed by a period on a line by itself. When this list is not
available, the server returns a 503 response code.
2.1.8.1 Responses
215 information follows
503 program error, function not performed
2.2 LISTGROUP
LISTGROUP [ggg]
The LISTGROUP command is used to get a listing of all the article
numbers in a particular news group.
The optional parameter ggg is the name of the news group to be
selected (e.g. "news.software.b"). A list of valid news groups may
be obtained from the LIST command. If no group is specified, the
current group is used as the default argument.
The successful selection response will be a list of the article
numbers in the group followed by a period on a line by itself.
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
news group is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the news group is not case-dependent. It must
otherwise match a news group obtained from the LIST command or an
error will result.
2.2.1 Responses
211 list of article numbers follow
412 Not currently in newsgroup
502 no permission
Barber Informational [Page 9]
RFC 2980 Common NNTP Extensions October 2000
2.3 MODE READER
MODE READER is used by the client to indicate to the server that it
is a news reading client. Some implementations make use of this
information to reconfigure themselves for better performance in
responding to news reader commands. This command can be contrasted
with the SLAVE command in RFC 977, which was not widely implemented.
MODE READER was first available in INN.
2.3.1 Responses
200 Hello, you can post
201 Hello, you can't post
2.4 XGTITLE
XGTITLE [wildmat]
The XGTITLE command is used to retrieve news group descriptions for
specific news groups.
This extension first appeared in ANU-NEWS, an NNTP implementation for
DEC's VMS. The optional parameter is a pattern in wildmat format.
When executed, a 282 response is given followed by lines that have
two fields, the news group name (which matches the pattern in the
argument) and a short explanation of the purpose of the news group.
When no argument is specified, the default argument is the current
group name. When display is completed, the server sends a period on
a line by itself.
Please note that this command and the LIST NEWSGROUP command provide
the same functionality with different response codes.
Since this command provides the same functionality as LIST NEWSGROUP
it is suggested that this extension be deprecated and no longer be
used in newsreading clients.
Note that there is a conflict in one of the response codes from
XGTITLE and some of the authentication extensions.
2.5.1 Responses
481 Groups and descriptions unavailable
282 list of groups and descriptions follows
Barber Informational [Page 10]
RFC 2980 Common NNTP Extensions October 2000
2.6 XHDR
XHDR header [range|<message-id>]
The XHDR command is used to retrieve specific headers from specific
articles.
The required parameter is the name of a header line (e.g. "subject")
in a news group article. See RFC 1036 for a list of valid header
lines. The optional range argument may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
The optional message-id argument indicates a specific article. The
range and message-id arguments are mutually exclusive. If no
argument is specified, then information from the current article is
displayed. Successful responses start with a 221 response followed
by a the matched headers from all matched messages. Each line
containing matched headers returned by the server has an article
number (or message ID, if a message ID was specified in the command),
then one or more spaces, then the value of the requested header in
that article. Once the output is complete, a period is sent on a
line by itself. If the optional argument is a message-id and no such
article exists, the 430 error response is returned. If a range is
specified, a news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Some implementations will return "(none)" followed by a period on a
line by itself if no headers match in any of the articles searched.
Others return the 221 response code followed by a period on a line by
itself.
The XHDR command has been available in the UNIX reference
implementation from its first release. However, until now, it has
been documented only in the source for the server.
Barber Informational [Page 11]
RFC 2980 Common NNTP Extensions October 2000
2.6.1 Responses
221 Header follows
412 No news group current selected
420 No current article selected
430 no such article
502 no permission
2.7 XINDEX
XINDEX ggg
The XINDEX command is used to retrieve an index file in the format of
originally created for use by the TIN [6] news reader.
The required parameter ggg is the name of the news group to be
selected (e.g. "news.software.b"). A list of valid news groups may
be obtained from the LIST command.
The successful selection response will return index file in the
format used by the TIN news reader followed by a period on a line by
itself.
When a valid group is selected by means of this command, the
internally maintained "current article pointer" is set to the first
article in the group. If an invalid group is specified, the
previously selected group and article remain selected. If an empty
news group is selected, the "current article pointer" is in an
indeterminate state and should not be used.
Note that the name of the news group is not case-dependent. It must
otherwise match a news group obtained from the LIST command or an
error will result.
The format of the tin-style index file is discussed in the
documentation for the TIN newsreader. Since more recent versions of
TIN support the news overview (NOV) format, it is recommended that
this extension become historic and no longer be used in current
servers or future implementations.
2.7.1 Responses
218 tin-style index follows
418 no tin-style index is available for this news group
Barber Informational [Page 12]
RFC 2980 Common NNTP Extensions October 2000
2.8 XOVER
XOVER [range]
The XOVER command returns information from the overview database for
the article(s) specified. This command was originally suggested as
part of the OVERVIEW work described in "The Design of a Common
Newsgroup Overview Database for Newsreaders" by Geoff Collyer. This
document is distributed in the Cnews distribution. The optional
range argument may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
If no argument is specified, then information from the current
article is displayed. Successful responses start with a 224 response
followed by the overview information for all matched messages. Once
the output is complete, a period is sent on a line by itself. If no
argument is specified, the information for the current article is
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Each line of output will be formatted with the article number,
followed by each of the headers in the overview database or the
article itself (when the data is not available in the overview
database) for that article separated by a tab character. The
sequence of fields must be in this order: subject, author, date,
message-id, references, byte count, and line count. Other optional
fields may follow line count. Other optional fields may follow line
count. These fields are specified by examining the response to the
LIST OVERVIEW.FMT command. Where no data exists, a null field must
be provided (i.e. the output will have two tab characters adjacent to
each other). Servers should not output fields for articles that have
been removed since the XOVER database was created.
The LIST OVERVIEW.FMT command should be implemented if XOVER is
implemented. A client can use LIST OVERVIEW.FMT to determine what
optional fields and in which order all fields will be supplied by
the XOVER command. See Section 2.1.7 for more details about the LIST
OVERVIEW.FMT command.
Barber Informational [Page 13]
RFC 2980 Common NNTP Extensions October 2000
Note that any tab and end-of-line characters in any header data that
is returned will be converted to a space character.
2.8.1 Responses
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
2.9 XPAT
XPAT header range|<message-id> pat [pat...]
The XPAT command is used to retrieve specific headers from specific
articles, based on pattern matching on the contents of the header.
This command was first available in INN.
The required header parameter is the name of a header line (e.g.
"subject") in a news group article. See RFC 1036 for a list of valid
header lines. The required range argument may be any of the
following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
The required message-id argument indicates a specific article. The
range and message-id arguments are mutually exclusive. At least one
pattern in wildmat must be specified as well. If there are
additional arguments the are joined together separated by a single
space to form one complete pattern. Successful responses start with
a 221 response followed by a the headers from all messages in which
the pattern matched the contents of the specified header line. This
includes an empty list. Once the output is complete, a period is
sent on a line by itself. If the optional argument is a message-id
and no such article exists, the 430 error response is returned. A
502 response will be returned if the client only has permission to
transfer articles.
2.9.1 Responses
221 Header follows
430 no such article
502 no permission
Barber Informational [Page 14]
RFC 2980 Common NNTP Extensions October 2000
2.10 The XPATH command
XPATH <message-id>
The XPATH command is used to determine the filenames in which an
article is filed. It first appeared in INN.
The required parameter message-id is the message id of an article as
shown in that article's message-id header. According to RFC 1036
[3], all message ids for all articles within the netnews environment
are unique, but articles may be crossposted to multiple groups. The
response to an XPATH command will include a listing of all filenames
in which an article is stored separated by spaces or a response
indicating that no article with the specified message-id exists. The
returned data is only useful if the news client knows the
implementation details of the server. Because of this, it is
recommended that client avoid using this command.
2.10.1 Responses
223 path1[ path2 ...]
430 no such article on server
2.11 The XROVER command
XROVER [range]
The XROVER command returns reference information from the overview
database for the article(s) specified. This command first appeared
in the Unix reference implementation. The optional range argument
may be any of the following:
an article number
an article number followed by a dash to indicate
all following
an article number followed by a dash followed by
another article number
Successful responses start with a 224 response followed by the
contents of reference information for all matched messages. Once the
output is complete, a period is sent on a line by itself. If no
argument is specified, the information for the current article is
returned. A news group must have been selected earlier, else a 412
error response is returned. If no articles are in the range
specified, a 420 error response is returned by the server. A 502
response will be returned if the client only has permission to
transfer articles.
Barber Informational [Page 15]
RFC 2980 Common NNTP Extensions October 2000
The output will be formatted with the article number, followed by the
contents of the References: line for that article, but does not
contain the field name itself.
This command provides the same basic functionality as using the XHDR
command and "references" as the header argument.
2.11.1 Responses
224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission
2.12 XTHREAD
XTHREAD [DBINIT|THREAD]
The XTHREAD command is used to retrieve threading information
in format of originally created for use by the TRN [6] news
reader.
The command XTHREAD DBINIT may be issued prior to entering
any groups to see if a thread database exists. If it does,
the database's byte order and version number are returned
as binary data.
If no parameter is given, XTHREAD THREAD is assumed.
To use XTHREAD THREAD, a news group must have been selected
earlier, else a 412 error response is returned.
A 502 response will be returned if the client only has
permission to transfer articles. A 503 response is returned
if the threading files are not available.
The format of the trn-style thread format is discussed in
the documentation for the TRN newsreader. Since more recent
versions of TRN support the news overview (NOV) format, it
is recommended that this extension become historic and no
longer be used in current servers or future implementations.
2.12.1 Responses
288 Binary data to follow
412 No newsgroup current selected
502 No permission
503 program error, function not performed
Barber Informational [Page 16]
RFC 2980 Common NNTP Extensions October 2000
3. Other Extensions
3.1 AUTHINFO
AUTHINFO is used to inform a server about the identity of a user of
the server. In all cases, clients must provide this information when
requested by the server. Servers are not required to accept
authentication information that is volunteered by the client.
Clients must accommodate servers that reject any authentication
information volunteered by the client.
There are three forms of AUTHINFO in use. The original version, an
NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
which is called AUTHINFO GENERIC.
3.1.1 Original AUTHINFO
AUTHINFO USER username
AUTHINFO PASS password
The original AUTHINFO is used to identify a specific entity to the
server using a simple username/password combination. It first
appeared in the UNIX reference implementation.
When authorization is required, the server will send a 480 response
requesting authorization from the client. The client must enter
AUTHINFO USER followed by the username. Once sent, the server will
cache the username and may send a 381 response requesting the
password associated with that username. Should the server request a
password using the 381 response, the client must enter AUTHINFO PASS
followed by a password and the server will then check the
authentication database to see if the username/password combination
is valid. If the combination is valid or if no password is required,
the server will return a 281 response. The client should then retry
the original command to which the server responded with the 480
response. The command should then be processed by the server
normally. If the combination is not valid, the server will return a
502 response.
Clients must provide authentication when requested by the server. It
is possible that some implementations will accept authentication
information at the beginning of a session, but this was not the
original intent of the specification. If a client attempts to
reauthenticate, the server may return 482 response indicating that
the new authentication data is rejected by the server. The 482 code
will also be returned when the AUTHINFO commands are not entered in
the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
PASS preceding AUTHINFO USER).
Barber Informational [Page 17]
RFC 2980 Common NNTP Extensions October 2000
All information is passed in cleartext.
When authentication succeeds, the server will create an email address
for the client from the user name supplied in the AUTHINFO USER
command and the hostname generated by a reverse lookup on the IP
address of the client. If the reverse lookup fails, the IP address,
represented in dotted-quad format, will be used. Once authenticated,
the server shall generate a Sender: line using the email address
provided by authentication if it does not match the client-supplied
From: line. Additionally, the server should log the event, including
the email address. This will provide a means by which subsequent
statistics generation can associate newsgroup references with unique
entities - not necessarily by name.
3.1.1.1 Responses
281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission
3.1.2 AUTHINFO SIMPLE
AUTHINFO SIMPLE
user password
This version of AUTHINFO was part of a proposed NNTP V2
specification, which was started in 1991 but never completed, and is
implemented in some servers and clients. It is a refinement of the
original AUTHINFO and provides the same basic functionality, but the
sequence of commands is much simpler.
When authorization is required, the server sends a 450 response
requesting authorization from the client. The client must enter
AUTHINFO SIMPLE. If the server will accept this form of
authentication, the server responds with a 350 response. The client
must then send the username followed by one or more space characters
followed by the password. If accepted, the server returns a 250
response and the client should then retry the original command to
which the server responded with the 450 response. The command should
then be processed by the server normally. If the combination is not