"Fossies" - the Fresh Open Source Software Archive
Member "tin-2.4.1/doc/good-netkeeping-seal" (28 Aug 2013, 35305 Bytes) of archive /linux/misc/tin-2.4.1.tar.gz:
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
the uninterpreted source code file.
1 From: Jeroen Scheerder <email@example.com>
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
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 <firstname.lastname@example.org>
18 -----BEGIN PGP SIGNED MESSAGE-----
20 GNKSA * The Good Net-Keeping Seal of Approval
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.
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.
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
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"
52 - What the user writes is what gets posted, as is.
54 Newer software should be an improvement over an ancient program like
55 `rn'. Instead, much of it is crippled or broken in comparison.
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.
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.
76 These are the proposed standards a Usenet news program should meet to
77 deserve the "Good Net-Keeping Seal":
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
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.
111 1) Display all essential header information
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.
118 a) The author of the article (its "From: " header line)
120 b) The article's Subject. At least the first 70 characters
121 following the "Subject: " string MUST be displayed.
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
129 d) The article's Followup-To list, if this is different from the
130 Newsgroups list. This MUST be displayed in full, never
133 e) The article's Reply-To, if this is different from the From
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
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.
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.
151 2) Provide clear, separate commands for new posting, followup, and
152 e-mail reply
154 The software MUST provide separate, clearly distinguished commands to do
155 each of the following:
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.
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)
165 c) Reply by e-mail, with "Subject: " and "To: " headers derived
166 appropriately from the original article. (see #5 and #8 below)
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.
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.
182 3) Provide cross-posting functionality
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.
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: ".
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.
201 4) Allow users to change essential headers
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.
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.
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.
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.
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."
233 5) Ensure followups and e-mail replies contain a correct Subject
235 When creating either a followup article or an e-mail reply, the software
236 MUST create an initial "Subject: " header which
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: " .
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.
249 (The user may later change the Subject, of course; see #4 above.)
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: ".
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.
263 6) Direct followups to the correct newsgroups
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.)
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.
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.
280 7) Make sure followups contain valid References
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.
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
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.>>
299 However, it also says:
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.>>
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.
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.)
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.
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.
323 8) Direct e-mail replies to the correct address
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.)
330 Rationale: See #6 above.
333 9) Allow the user to change her mind about whether to post or mail
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.
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
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).
355 10) Provide adequate quotation and attribution facilities
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. `> ').
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.
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).
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
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
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.
403 11) Provide a user-specified "Subject: " header
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).
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.
419 12) Provide a valid "From: " header
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).
425 This requirement must be met regardless of whether the software
427 (a) creates the "From: " header when it first creates the article to
428 be edited by the user, or
430 (b) adds the "From: " header automatically after the user finishes
431 editing the article and requests that it be submitted.
433 If the software allows the user to edit the "From: " header, it SHOULD
434 check that the user supplied a syntactically valid address.
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
442 If feasible, the software SHOULD try to guarantee that this address
443 actually belongs to the person using the software, and actually accepts
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.
453 13) Allow users to both cancel and supersede their own articles (and
454 _no_ others!)
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
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.
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".
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.
483 14) Try to respect the 80-character line-length conventions
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.
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.
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.
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.
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.
517 If the news software uses an external editor, the default editor SHOULD
518 conform to the above.
520 Rationale: Articles with long lines are unreadable to many users.
521 Articles with alternating 80/20 lines aren't any better.
524 15) Separate signatures correctly, and don't use excessive ones
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:
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.>>
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.
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.
550 16) Try to prevent obvious user errors
552 * Posting software MUST warn the user for posting empty articles, and
553 SHOULD prevent doing so entirely.
555 * Posting software MUST warn the user about posting articles consisting
556 entirely of quoted text, and SHOULD prevent doing so entirely.
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.
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"
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.
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.
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.
588 17) Post human-readable articles unless ordered otherwise
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.
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.
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.
614 18) Provide self-protection
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
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.
629 19) Be kind to servers, leave room for others
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.
637 Rationale: News systems are big, resources are scarce, and every
638 resource claimed is provided at the expense of other users.
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.
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.
661 References and additional reading
664 The current GNKSA, an evaluation form and an archive of software
665 evaluations can be found at:
668 <http://newsreaders.com/gnksa/> (Mirror)
669 <http://newsreaders.com/misc/twpierce/news/> (GNKSA 1.2)
671 The GNKSA page also contains a pointer to a library that newsreader
672 developers can freely make use of, providing basic `sanitary' functions.
674 In addition to the Seal, anyone writing Usenet software should pay
675 careful attention to the following documents:
677 RFC 977, "Network News Transfer Protocol -- A Proposed Standard for
678 the Stream-Based Transmission of News", by Brian Kantor and Phil
682 RFC 1036, "Standard for Interchange of USENET Messages", by
683 M. Horton and R. Adams.
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)
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.).
696 "Read This Before You Write a Newsreader, News Transport
697 System, etc.", by Tom Limoncelli.
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.
705 Excellent collections of things well worth reading in this context can
706 be found at:
708 "News Hacking", by Tim Pierce.
711 "Notes on News", by Lars Magne Ingebrigtsen.
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:
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.
721 The part that explicitly deals with the issues of messing up
722 "From: "-headers is:
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
735 Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working
736 Group initiative (and its derivatives).
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.
742 Sven Guckes <email@example.com> for providing mailing list
743 resources (among other things).
745 Tim Pierce <firstname.lastname@example.org> for scrutinous examination,
746 useful hints, and previous GNKSA support.
748 Larry Wall <email@example.com>, Stefan Haller <firstname.lastname@example.org>,
749 John E. Davis <email@example.com>, John Norstad <firstname.lastname@example.org>,
750 Karl-Johan Johnsson <email@example.com>, Brian Clark <firstname.lastname@example.org>,
751 Simon Fraser <email@example.com> for showing inspiring examples of the spirit
752 of good net keeping in the form of exceptionally well-designed usenet
753 reading programs.
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.
758 -----BEGIN PGP SIGNATURE-----
759 Version: PGP 6.5.8
766 -----END PGP SIGNATURE-----