"Fossies" - the Fresh Open Source Software Archive 
Member "tin-2.6.2/doc/good-netkeeping-seal" (23 Aug 2021, 35305 Bytes) of package /linux/misc/tin-2.6.2.tar.xz:
As a special service "Fossies" has tried to format the requested text file into HTML format (style:
standard) with prefixed line numbers.
Alternatively you can here
view or
download the uninterpreted source code file.
1 From: Jeroen Scheerder <js@phil.uu.nl>
2 Newsgroups: news.software.readers,comp.os.msdos.mail-news,comp.os.os2.mail-news,comp.sys.mac.comm,comp.os.ms-windows.apps.comm,comp.os.ms-windows.apps.winsock.news,alt.usenet.offline-reader,alt.answers,comp.answers,news.answers
3 Subject: Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Software
4 Approved: news-answers-request@MIT.EDU
5 Followup-To: news.software.readers
6 Summary: Guidelines for writers of Usenet reading and posting programs.
7 If you follow these guidelines, you'll make your users and the rest
8 of the Usenet community much happier.
9 X-Note: This is an updated and revised descendant of Ron Newman's GNKSA 1.2
10
11 Archive-name: usenet/software/good-netkeeping-seal
12 Posting-Frequency: monthly (first Sunday)
13 Last-modified: Oct 29 2003
14 X-Version: 2.09 ($Id: gnksa.hdr,v 1.8 2003/10/29 07:31:42 js Exp $)
15 URL: <http://www.gnksa.org/>
16 Maintainer: Jeroen Scheerder <js@gnksa.org>
17
18 -----BEGIN PGP SIGNED MESSAGE-----
19
20 GNKSA * The Good Net-Keeping Seal of Approval
21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22
23 There's a general perception that Usenet is becoming "noisier" the more
24 people join it. There are more blank articles, more mangled headers,
25 more "me too" responses accompanying many lines of quoted text, more
26 followup postings to inappropriate newsgroups, more misattributed
27 quotes, more followups that really should have been e-mail replies, more
28 excessive cross- and multi-postings, more unreadibly encoded or
29 otherwise maimed articles.
30
31 This is often blamed on the new users themselves -- they are called
32 "clueless newbies", unqualified to participate in Usenet because they
33 don't know Unix, or use a misdesigned graphical user interface (GUI), or
34 use an off-line news reader, or use a commercial service such as America
35 Online or Delphi.
36
37 I believe most of this anger is misdirected. The new users aren't
38 really that different from the old-timers. What _is_ different is that
39 many of the old-timers are using relatively well-behaved software,
40 while many of the newbies are using various PC newsreaders that frequently
41 violate assumptions that come naturally to people used to well-behaved
42 readers:
43
44 - The user can see the essential header fields, including "Newsgroups"
45 and "Followup-To".
46 - The user can edit all header fields when composing a followup.
47 - There's a clear difference between `followup' and `reply'.
48 - Followups preserve the Subject and References of the original
49 article, unless the user explicitly changes them.
50 - News software respects "Followup-To" and "Reply-To"
51 specifications.
52 - What the user writes is what gets posted, as is.
53
54 Newer software should be an improvement over an ancient program like
55 `rn'. Instead, much of it is crippled or broken in comparison.
56
57 The Usenet community can deal with this problem by establishing a "Good
58 Net-keeping Seal of Approval" for Usenet reading and posting software.
59 This "Seal" would certify that the software complies with certain
60 minimal standards, such as those listed below.
61
62 A group of volunteers will test all putative Usenet software to
63 determine whether it qualifies for the "Seal", with the intention to
64 periodically post a list of all tested software to
65 news.software.readers, alt.usenet.offline-reader, and other appropriate
66 newsgroups. This periodic posting will list both compliant and
67 non-compliant news programs; for non-compliant programs, it will include
68 a list of all violations of the standards. The hope is that this will
69 encourage the authors of non-compliant software to bring their programs
70 up to "Good Net-Keeping Seal" standards, eventually.
71
72
73 --%-@#@-%--
74
75
76 These are the proposed standards a Usenet news program should meet to
77 deserve the "Good Net-Keeping Seal":
78
79 1) Display all essential header information
80 2) Provide clear, separate commands for new posting, followup, and
81 e-mail reply
82 3) Provide cross-posting functionality
83 4) Allow users to change essential headers
84 5) Ensure followups and e-mail replies contain a correct Subject
85 6) Direct followups to the correct newsgroups
86 7) Make sure followups contain valid References
87 8) Direct e-mail replies to the correct address
88 9) Allow the user to change her mind about whether to post or mail
89 10) Provide adequate quotation and attribution facilities
90 11) Provide a user-specified "Subject: " header
91 12) Provide a valid "From: " header
92 13) Allow users to both cancel and supersede their own articles (and
93 _no_ others!)
94 14) Try to respect the 80-character line-length conventions
95 15) Separate signatures correctly, and don't use excessive ones
96 16) Try to prevent obvious user errors
97 17) Post human-readable articles unless ordered otherwise
98 18) Provide self-protection
99 19) Be kind to servers, leave room for others
100
101 These requirements are described in more detail below. In the spirit of
102 RFC 1123 and Henry Spencer's "son of RFC 1036" proposal, I've
103 capitalized the words "MUST", "MUST NOT", and "DO NOT" to indicate
104 absolute requirements, while using the word "SHOULD" for things that are
105 merely a Very Good Idea, Really.
106
107
108 --%-@#@-%--
109
110
111 1) Display all essential header information
112
113 When displaying a news article, it MUST by default show the user certain
114 information that is found in the article's header. The information need
115 not be displayed as actual RFC-1036 header lines, but it MUST be shown
116 to the user in some form.
117
118 a) The author of the article (its "From: " header line)
119
120 b) The article's Subject. At least the first 70 characters
121 following the "Subject: " string MUST be displayed.
122
123 c) The list of newsgroups the article was posted to. This list MUST
124 be displayed in full, never truncated. This list need not be
125 displayed if it has only one element, provided that the software
126 displays the name of the newsgroup that the user is currently
127 reading.
128
129 d) The article's Followup-To list, if this is different from the
130 Newsgroups list. This MUST be displayed in full, never
131 truncated.
132
133 e) The article's Reply-To, if this is different from the From
134 specification.
135
136 If the required information does not fit fully on the display, the
137 software MAY display only the initial part of the information, provided
138 that it offers the user a scrollbar or equivalent means of viewing the
139 remainder.
140
141 The software MAY allow the user to re-configure it so as to turn off
142 these displays, but if the user has not done this, all of the required
143 information MUST be displayed.
144
145 Rationale: Without having to make any special effort the user should see
146 who sent the article she is reading, how to reply to it via e-mail, what
147 discussion groups it was posted to, and whether the author of the
148 message wants to narrow or redirect the location of future discussion.
149
150
151 2) Provide clear, separate commands for new posting, followup, and
152 e-mail reply
153
154 The software MUST provide separate, clearly distinguished commands to do
155 each of the following:
156
157 a) Post a new article, unrelated to any existing one, whose Subject
158 is to be supplied by the user, and which has an empty or missing
159 References: header line.
160
161 b) Post a followup article, with Subject, Newsgroups, and References
162 header lines derived appropriately from the original article.
163 (see #5, #6, and #7 below)
164
165 c) Reply by e-mail, with "Subject: " and "To: " headers derived
166 appropriately from the original article. (see #5 and #8 below)
167
168 Software that uses the English language is strongly encouraged to
169 include the phrases "Post to newsgroup", "Followup to newsgroup", and
170 "Reply by e-mail" (or "Reply to sender" or "Reply to author") -- in
171 menus, on-line help, and written documentation. It SHOULD avoid using
172 other verbs such as "Send" or "Respond" whose meaning is not evident to
173 the user. An ordinary, untrained user SHOULD be able to easily pick the
174 correct command.
175
176 Rationale: Users who post followups when they should send e-mail
177 replies, or vice versa, seem to be an endemic problem. They are almost
178 always using software that doesn't make the difference clear, or doesn't
179 even provide both commands.
180
181
182 3) Provide cross-posting functionality
183
184 When creating either a new article or a followup, the user MUST be
185 allowed to specify multiple newsgroups, and the software MUST cross-post
186 (not multi-post) to them if more than one is specified.
187
188 Posting software SHOULD prevent the user from excessive cross-posting,
189 or at least warn against it. If posting to a very large number of
190 groups, the user SHOULD either be forced or strongly suggested to set a
191 "Followup-To" header. Such a header must be subjected to restrictions
192 that are at least as strict as those imposed on "Newsgroups: ".
193
194 Rationale: Cross-posting is an essential feature of Usenet. If the
195 software cannot cross-post, then its users will multi-post instead. A
196 reasonable attempt should be made, however, to protect the user against
197 (usually inadvertent; if not, often considered net-abuse) excessive
198 cross-postings that will only lead to canceling and flame warfare.
199
200
201 4) Allow users to change essential headers
202
203 When creating either a new article or a followup, the software MUST
204 allow the user to edit the Subject, Newsgroups, Followup-To, and
205 Reply-To specifications. The user MUST be able to edit these at any
206 time during composition of the article; she MUST NOT be limited to
207 specifying them only before, or after, editing the article's text.
208
209 The software MUST allow the user to specify a new Subject field of at
210 least 70 characters, not including the string "Subject: " itself. It is
211 better not to impose any limit at all, other than the overall
212 son-of-1036 limit of 998 characters (see #7) per header line.
213
214 The software MUST allow the user to specify "Followup-To: poster", which
215 tells readers of the article that the user prefers e-mail replies rather
216 than followups to the newsgroup.
217
218 This does not mean that the software must present raw RFC-1036 headers
219 to the user, or that the headers and body must be an indivisible unit of
220 editable text. A graphical user interface that presents each of these
221 as an editable field in a form will meet the requirement.
222
223 Rationale: Topics drift as a discussion progresses, and users need the
224 ability to change the Subject header to reflect the drift. Similarly, a
225 user may determine that the discussion no longer belongs in some of the
226 places that it started, or that its continuation needs to go elsewhere.
227 The software must not impede the user's ability to make these
228 judgments, possibly during the composition of her followup article.
229 It's not acceptable to have users who respond to "Please direct
230 followups appropriately" with "I can't; the software won't let me."
231
232
233 5) Ensure followups and e-mail replies contain a correct Subject
234
235 When creating either a followup article or an e-mail reply, the software
236 MUST create an initial "Subject: " header which
237
238 a) Prepends the four characters "Re: " to the Subject if and only if
239 "Re: " is not already present. Note that this contains an
240 upper-case "R", a lower-case "e", and a trailing space. DO NOT
241 prepend non-standard prefixes such as "Re^2: " .
242
243 b) Preserves the *entire* Subject of the original article. DO NOT
244 chop it off at 20 or 25 or even 80 characters. DO NOT append
245 spaces or any other characters to the end. DO NOT change the
246 case of any character in the original Subject; in particular, DO
247 NOT change the Subject to all-upper-case or all-lower-case.
248
249 (The user may later change the Subject, of course; see #4 above.)
250
251 Exception: The software MAY try to compensate for other people's broken
252 software by replacing non-standard prefixes (such as "Re^2: ", "Re(2):
253 ", "Re:" (no space), "RE: ", "re: " , or "Re: Re: ") by the standard
254 prefix "Re: ".
255
256 Rationale: These things should be obvious, but many authors of news
257 software don't seem to understand the relevant sections of RFC 1036.
258 Truncated "Subject: " headers, especially when gratuitous non-ASCII
259 characters are also thrown in, are a major annoyance for users and can
260 make threading difficult or impossible.
261
262
263 6) Direct followups to the correct newsgroups
264
265 When creating a followup article, the software MUST create an initial
266 header in which the Newsgroups field is initialized to the original
267 article's Followup-To, if one was provided, or Newsgroups, if it wasn't.
268 (The user may later change this field, of course; see #4 above.)
269
270 If the original article's "Followup-To: " header is set to "poster", the
271 software MUST warn the user that the original poster requested an e-mail
272 reply, and generate an e-mail reply by default.
273
274 Rationale: This is basic RFC 1036 compliance. Software that fails to
275 meet this requirement makes its users look at best foolish or
276 incompetent, and at worst willfully unresponsive to the wishes of other
277 Usenet users.
278
279
280 7) Make sure followups contain valid References
281
282 When creating a followup, the software MUST create a "References: "
283 header line that contains, as its last element, the Message-ID of the
284 original article. An individual Message-ID MUST never be truncated.
285
286 The software MUST include at least three additional Message-IDs from
287 the original article's References header as well, if they are available.
288 Try to stay as close as possible to the spirit of "son-of-1036", which
289 states:
290
291 <<Followup agents SHOULD not shorten References headers. If
292 it is absolutely necessary to shorten the header, as a des-
293 perate last resort, a followup agent MAY do this by deleting
294 some of the message IDs. However, it MUST not delete the
295 first message ID, the last three message IDs (including that
296 of the immediate precursor), or any message ID mentioned in
297 the body of the followup.>>
298
299 However, it also says:
300
301 <<If it is absolutely necessary for an implementation to
302 impose a limit on the length of header lines, body lines, or
303 header logical lines, that limit shall be at least 1000
304 octets, including EOL representations.>>
305
306 So, bear in mind that news transports are not guaranteed to be able to
307 handle arbitrary long lines. Furthermore, keep in mind that some news
308 transports choke on continued (multi-line) "References: " headers.
309
310 Therefore, keep as many Message-IDs as will fit on a line starting with
311 "References: " with a maximum length of 998 characters. (An octet is a
312 byte of 8 bits, EOL representation takes two bytes.)
313
314 Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
315 Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by
316 a misguided user, maybe) but don't belong to the thread.
317
318 Rationale: Threaded news-readers depend on References to do their magic.
319 This too is basic RFC compliance. Be as complete as the line length
320 limit allows, but do not propagate errors.
321
322
323 8) Direct e-mail replies to the correct address
324
325 When creating an e-mail reply, the software MUST create an initial
326 header in which the "To: " header is initialized to the original
327 article's Reply-to, if one was provided, or From if it wasn't. (The
328 user may later change this field, of course; see #4 above.)
329
330 Rationale: See #6 above.
331
332
333 9) Allow the user to change her mind about whether to post or mail
334
335 With any followup or reply message, the software SHOULD offer the user
336 the option to change her mind about whether to post or to mail, and may
337 allow doing both.
338
339 If the software has the option to post as well as mail a single
340 response, that option MUST NOT be default behavior, neither by factory
341 default nor by user-configuration. Furthermore, when both posting and
342 mailing a message, the mailed message's body SHOULD be preceded by a
343 line clearly stating that the message is an email copy of a usenet
344 posting.
345
346 Rationale: People digress when writing, and may find themselves posting
347 a message that would have been more appropriate for private
348 communication, or mailing a message that would have been more
349 appropriately directed to the general audience. Unsolicited mail
350 messages are highly unwanted by many users (had they wanted e-mail
351 replies, they could, should and, for all a reader can assume would, have
352 requested them).
353
354
355 10) Provide adequate quotation and attribution facilities
356
357 When the user requests a followup or an e-mail reply, the software MUST
358 provide some method for including quoted text from the original article.
359 This quoted text MUST be clearly set off in some way -- either by
360 indenting it, or by prepending each line with one or more identifiable
361 characters. The quote prefix SHOULD be `>', with optionally a trailing
362 space (i.e. `> ').
363
364 Caveat: with `>', the level of quotation is clearly reflected in the
365 number of `>' characters at the start of the line. However,
366 whitespace between quote prefix and quoted material improves
367 readability, so it is good practice for newsreaders to use `> '
368 as the quote prefix for newly quoted, and `>' for repetitively
369 quoted text.
370
371 Included text SHOULD NOT contain the original article's signature,
372 unless by explicit request of the user (under the condition that the
373 signature can be determined of course, which is to say: if clearly
374 separated by the standard signature delimiter). (see also #15 below).
375
376 As a direct counterpart to this requirement, the software SHOULD offer
377 the user some means of selecting exactly which part of a Usenet posting
378 she wishes to followup to, and quote only that part initially. (A
379 special case of this is when a user wishes to react to what's in a
380 signature.)
381
382 If it concerns a followup (as opposed to an e-mail reply), the quoted
383 text MUST be preceded by an "attribution line" identifying the author of
384 the text that is being quoted. (The user may decide to delete this
385 attribution line or to configure it away, but it MUST be there by
386 default.)
387
388 Rationale: The ability to easily quote text is essential for users who
389 want to provide a proper context for their followups and e-mail replies.
390 Software that provides attribution lines without quoting ability, or
391 that fails to distinctively set off quoted text from original text, is a
392 major cause of "I didn't say that!" misunderstandings. By convention,
393 quoted lines start with `>', and much software depends on this do
394 distinguish quoted material from original lines, for presentation
395 purposes. Users can be careless or forgetful occasionally (or often,
396 even) and neglect to edit out spurious quoted material; the signature,
397 typically, is such material. In general, facilitating good quoting
398 behaviour -- by quoting only a part indicated by the user, for example
399 - - -- is an area in which software can help users substantially to create
400 better articles.
401
402
403 11) Provide a user-specified "Subject: " header
404
405 When creating a new article, the software MUST require the user to
406 provide a non-empty Subject. It MUST NOT post an article without a
407 "Subject: " header or with an empty "Subject: " header. It MUST NOT
408 silently add a default Subject (like "Subject: <None>") if the user
409 didn't specify one. It MUST allow the user to change the Subject at any
410 time while editing the main text of the article (see #4 above).
411
412 Rationale: An article without a Subject provides no clues for deciding
413 to read it or not. For that reason, it's likely to be widely ignored,
414 and it's no service to the user to allow posting of such an article;
415 while other readers may read it, only to find out they needn't have
416 bothered when it annoyingly turns out to be of no interest.
417
418
419 12) Provide a valid "From: " header
420
421 When creating either a new article or a followup, the software MUST
422 initialize the "From: " header to a syntactically valid e-mail address,
423 which includes a fully-qualified domain name (FQDN).
424
425 This requirement must be met regardless of whether the software
426
427 (a) creates the "From: " header when it first creates the article to
428 be edited by the user, or
429
430 (b) adds the "From: " header automatically after the user finishes
431 editing the article and requests that it be submitted.
432
433 If the software allows the user to edit the "From: " header, it SHOULD
434 check that the user supplied a syntactically valid address.
435
436 If the software is unable to create such an address -- maybe because it
437 was built with incorrect configuration parameters, or some essential
438 parameter is unavailable at runtime -- then it MUST NOT allow posting at
439 all, unless it can obtain a syntactically valid e-mail address from the
440 user.
441
442 If feasible, the software SHOULD try to guarantee that this address
443 actually belongs to the person using the software, and actually accepts
444 e-mail.
445
446 Rationale: Mail and news transport systems and user agents, gateways and
447 processing software may choke on syntactically invalid headers. Invalid
448 e-mail addresses make e-mail replies impossible; see Greg Byshank's
449 "Help! I've been spammed!" document for an excellent discussion of the
450 issues involved.
451
452
453 13) Allow users to both cancel and supersede their own articles (and
454 _no_ others!)
455
456 Any software that posts news SHOULD provide a command that the user can
457 invoke to cancel her own articles. It SHOULD also provide the option to
458 supersede the user's own articles. The software MUST guarantee that
459 the user cannot cancel or supersede other people's articles, as far as
460 possible.
461
462 Caveat: since completely reliable authentication can be infeasible, the
463 best the software can do is to make a good-faith effort to
464 determine whether or not cancelling or superseding is valid:
465 i.e. by trusting upon its user configuration and checking it
466 against the relevant header(s) in the target article.
467
468 If the software uses the English language, the text of the cancel
469 command SHOULD include the word "cancel", rather than non-standard verbs
470 such as "delete". Similarly, in English software, the text of the
471 supersede command SHOULD include the word "supersede".
472
473 Rationale: People make mistakes and need the ability to revoke or
474 correct them; both `cancel' and `supersede' exist for good reasons.
475 However, software should not encourage users to abuse the net, either
476 intentionally or accidentally, by sending unauthorized (`rogue') cancels
477 or supersedes. The supersede option is essential: due (a.o.) to
478 sometimes unpredictable usenet propagation, a "cancel-cum-repost" may
479 behave very different from a "supersede". News servers might also have
480 different acceptance policies for both.
481
482
483 14) Try to respect the 80-character line-length conventions
484
485 Any line breaks shown to the user while she is editing her article
486 SHOULD still be present when the article is actually posted to the Net.
487 The software SHOULD NOT show the user four 75-character lines while
488 actually posting a single 300-character line. Nor should it show the
489 user a series of 100-character lines while actually posting alternating
490 lines of 80 and 20 characters each.
491
492 It's also a good idea to warn the user if the article she is about to
493 post contains non-header lines longer than 80 characters. The software
494 SHOULD NOT prevent the posting, but SHOULD ask whether the user wants to
495 re-edit or post anyway.
496
497 Caveat: Occasionally, there are very good reasons for posting long lines
498 (for example, when posting a source code snippet containing
499 something that will break when wrapped, or when there's a need
500 to post something "as is", unreformatted -- unaltered and
501 completely intact). For that reason (re)wrapping cannot be a
502 MUST: a SHOULD is all it can be.
503
504 To get well-readable articles, the user SHOULD be provided with the
505 possibility to rewrap excessively long lines of quoted text, respecting
506 quotation -- i.e. have the option to correct `inherited' bad formatting.
507 Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that
508 may occur when someone reading your article uses a different tab size.
509
510 Caveat: Due to the immense variety in quoting styles, quoted text
511 reformatting can be extremely hard, practically impossible even.
512 No software can be expected to deal with everything; still,
513 since the overwhelming majority can be dealt relatively easily,
514 it is not unreasonable to expect it from software, if it is to
515 be well-equipped for the task of editing Usenet articles.
516
517 If the news software uses an external editor, the default editor SHOULD
518 conform to the above.
519
520 Rationale: Articles with long lines are unreadable to many users.
521 Articles with alternating 80/20 lines aren't any better.
522
523
524 15) Separate signatures correctly, and don't use excessive ones
525
526 Posting software SHOULD separate any signature appended to outgoing
527 articles from the main text with a line containing only `-- ' ("dash
528 dash space"). To quote son-of-rfc1036:
529
530 <<If a poster or posting agent does append a signature to an
531 article, the signature SHOULD be preceded with a delimiter
532 line containing (only) two hyphens (ASCII 45) followed by
533 one blank (ASCII 32). Posting agents SHOULD limit the
534 length of signatures, since verbose excess bordering on
535 abuse is common if no restraint is imposed; 4 lines is a
536 common limit.>>
537
538 Hence, posting software SHOULD prevent the user from using excessively
539 long signatures, or at least warn the user against it. A widely
540 accepted standard is the so-called McQuary limit: up to 4 lines, each up
541 to a maximum of 80 characters.
542
543 Rationale: Being confronted with (possibly excessively long) signatures
544 repetitively is, or can be, annoying to many. Being able to separate
545 the main text and the signature clearly is important, not only to
546 prevent the possible mistake of misinterpreting a signature, but also to
547 enable automatic signature suppression for those who wish to do so.
548
549
550 16) Try to prevent obvious user errors
551
552 * Posting software MUST warn the user for posting empty articles, and
553 SHOULD prevent doing so entirely.
554
555 * Posting software MUST warn the user about posting articles consisting
556 entirely of quoted text, and SHOULD prevent doing so entirely.
557
558 * Posting software MUST warn the user severely when attempting to post
559 an article over and over again, and SHOULD do everything it can to
560 prevent doing so entirely.
561
562 - When posting `asynchronously' (i.e. when sacrificing knowledge
563 about progress, success or failure by handing over the task
564 completely to some separate process) it SHOULD NOT allow the user
565 to post articles again, once the user issued the final "post"
566 command.
567
568 - When posting `synchronously', the software has at least partial
569 knowledge about progress, and full knowledge about success or
570 failure of an attempt to post. In this case, it SHOULD inform the
571 user clearly that the article is being posted while attempting to
572 post it; after the attempt, it MUST unequivocally inform the user
573 that posting succeeded if it did, and that it failed otherwise.
574
575 Note: So-called `online' newsreaders usually (but not necessarily)
576 post synchronously, while a number so-called `offline' newsreading
577 methods (especially the scheduled, batch-oriented ones) usually
578 employ asynchronous posting. However, offline newsreaders using
579 NNTP for news transport usually post synchronously, i.e. are in
580 direct interaction with the newsserver, hence get immediate
581 results, when posting.
582
583 Rationale: Users who do any of these things almost never do them on
584 purpose. They are usually confused by unfamiliar new software, and
585 should be offered basic protection.
586
587
588 17) Post human-readable articles unless ordered otherwise
589
590 Posting software MUST by default post only legible usenet articles. In
591 a different formulation: it MUST NOT encode or encrypt articles, unless
592 by explicit user demand. Hence, it MUST NOT even have the option to
593 encode or encrypt by default. Whenever some encoding/encryption will be
594 used, clear feedback showing that it's in effect MUST be provided to the
595 user, so she is permanently reminded of the fact that her article will
596 not be posted as composed. The worst DO NOT is the combination of
597 allowing default encoding without even taking the trouble of telling
598 (warning) the user about it.
599
600 Note: Common occurrences of this kind of content maiming unasked for,
601 and untold to, the user, are HTML- and MIME multi-part
602 and/or base64 encodings, as found in newsreaders integrated in
603 WWW-browsers better not mentioned.
604
605 Rationale: Many users may not be able to read (particular) encoded or
606 encrypted articles at all, or only at the expense of a considerable
607 effort: such articles ask to be widely ignored. Encouraging posting
608 maimed messages is a service neither to the user herself, nor to her
609 audience. Keep in mind that not everyone shares your particular setup
610 (newsreader, configuration, operating system), nor should (and can)
611 anyone be forced to do so, in order to be able to read your articles.
612
613
614 18) Provide self-protection
615
616 News readers SHOULD allow the user to protect herself by filtering out
617 articles she really does not want to read. These filtering facilities
618 SHOULD be sufficiently powerful to enable ignoring postings by
619 particular persons, about particular subjects, and particular
620 cross-posts.
621
622 Rationale: While it looks as if not having filtering only affects the
623 user herself, people tend to take it out on the net if they are
624 repetitively (structurally) annoyed by a particular class of postings,
625 and will be inclined to start canceling, advocate posting restriction or
626 engage in flame warfare, all of which is harmful to other users.
627
628
629 19) Be kind to servers, leave room for others
630
631 Reading or posting software MUST NOT put excessive demands on news
632 servers unnecessarily. The software MUST limit itself to 4 simultaneous
633 connections to a given server. Spurious connects and unnecessary
634 traffic MUST be avoided; the software MUST use as few as possible
635 connections, reusing existing connections whenever possible.
636
637 Rationale: News systems are big, resources are scarce, and every
638 resource claimed is provided at the expense of other users.
639
640
641 --%-@#@-%--
642
643
644 Please remember that this is a set of _minimum_ guidelines to guarantee
645 that a given piece of software interacts properly with the rest of the
646 Usenet world. It is not a general "wish list" of everyone's favorite
647 features. I have deliberately avoided taking a position on certain
648 controversial issues -- for example, whether the user should be allowed
649 to edit the "Sender: " header, whether news software should prohibit
650 posting an article that has more quoted text than new text, or whether
651 posting with certain particular Subjects should be prohibited.
652
653
654 My hope is that a voluntary committee can be formed, respected by many
655 people on the Net, that reviews Usenet software and decides whether it
656 deserves the "Good Net-Keeping Seal of Approval." People who use broken
657 software that does not have the Seal should then be strongly encouraged
658 to switch to software that does.
659
660
661 References and additional reading
662 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
663
664 The current GNKSA, an evaluation form and an archive of software
665 evaluations can be found at:
666
667 <http://www.xs4all.nl/%7Ejs/gnksa/>
668 <http://newsreaders.com/gnksa/> (Mirror)
669 <http://newsreaders.com/misc/twpierce/news/> (GNKSA 1.2)
670
671 The GNKSA page also contains a pointer to a library that newsreader
672 developers can freely make use of, providing basic `sanitary' functions.
673
674 In addition to the Seal, anyone writing Usenet software should pay
675 careful attention to the following documents:
676
677 RFC 977, "Network News Transfer Protocol -- A Proposed Standard for
678 the Stream-Based Transmission of News", by Brian Kantor and Phil
679 Lapsley.
680 <ftp://ftp.internic.net/rfc/rfc977.txt>
681
682 RFC 1036, "Standard for Interchange of USENET Messages", by
683 M. Horton and R. Adams.
684 <ftp://ftp.internic.net/rfc/rfc1036.txt>
685
686 The proposed "Son of 1036", "News Article Format and Transmission",
687 by Henry Spencer.
688 <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z> (also news.ps.Z)
689
690 "The UseFor Working Group Documents" (under development: Internet
691 Drafts describing the minimal standards for a Usenet article, and
692 the minimum features all Usenet software should have), by Simon
693 Lyall (et al.).
694 <http://www.landfield.com/usefor/>
695
696 "Read This Before You Write a Newsreader, News Transport
697 System, etc.", by Tom Limoncelli.
698 <http://www.xs4all.nl/%7Ejs/gnksa/read-before.txt>
699
700 "The "Good Net-Keeping Seal of Approval", revision 1.2, by Ron
701 Newman; the previous version of this document, published in
702 January, 1995.
703 <http://www2.thecia.net/users/rnewman/Good-Netkeeping-Seal>
704
705 Excellent collections of things well worth reading in this context can
706 be found at:
707
708 "News Hacking", by Tim Pierce.
709 <http://newsreaders.com/misc/twpierce/news/>
710
711 "Notes on News", by Lars Magne Ingebrigtsen.
712 <http://quimby.gnus.org/notes/notes.html>
713
714 A very informative overview of the issues concerning some forms of net
715 abuse, and how and how not to deal with it, is:
716
717 "Help! I've been Spammed! What do I do?", by Greg Byshenk, based in
718 part on an original by Chris Lewis, Posted weekly to news.answers,
719 news.newusers.questions, and news.admin.net-abuse.misc.
720 <http://www.byshenk.net/ive.been.spammed.html>
721 The part that explicitly deals with the issues of messing up
722 "From: "-headers is:
723 <http://www.byshenk.net/ive.been.spammed.html#2.3>
724
725 Of related interest -- if you're willing to contribute, or are just
726 interested in the way things are developing -- could also be the IETF
727 NNTP Working Group's "attempt to revise NNTP and bring it into the
728 1990s".
729 <http://www.academ.com/academ/nntp/ietf.html>
730
731
732 Acknowledgements
733 ~~~~~~~~~~~~~~~~
734
735 Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working
736 Group initiative (and its derivatives).
737
738 Ron Newman <rnewman@theCIA.net>, of course, for writing the first
739 version of the GNKSA, of which this document descends, and for
740 fruitful discussions during revision.
741
742 Sven Guckes <guckes@math.fu-berlin.de> for providing mailing list
743 resources (among other things).
744
745 Tim Pierce <twpierce@midway.uchicago.edu> for scrutinous examination,
746 useful hints, and previous GNKSA support.
747
748 Larry Wall <lwall@netlabs.com>, Stefan Haller <stk@berlin.snafu.de>,
749 John E. Davis <davis@space.mit.edu>, John Norstad <j-norstad@nwu.edu>,
750 Karl-Johan Johnsson <su95-kjo@nada.kth.se>, Brian Clark <baclark@nwu.edu>,
751 Simon Fraser <smfr@best.com> for showing inspiring examples of the spirit
752 of good net keeping in the form of exceptionally well-designed usenet
753 reading programs.
754
755 The kind folks of news.software.readers (you know who you are) that
756 have helped discussing the issues that pertain to the GNSKA cause.
757
758 -----BEGIN PGP SIGNATURE-----
759 Version: PGP 6.5.8
760
761 iQCVAwUBP59sFihIY6bIQPMpAQGv2QQAhD1M2vo6ASncrrVitDfVuyLY4WuFc607
762 24G73/uxY41/6PdzLkTe3+9Lb8RUjHhgNZvMJDc42H3veV177jHkOMOnkAHL3Nvl
763 936CzXPxAsnn3YSmrCFT+cRrepvdYVoxPKu3wbhpJNTDcoyI5OcUFyOYhwKRpg31
764 sVBe/csBC9g=
765 =Typt
766 -----END PGP SIGNATURE-----