1From: Jeroen Scheerder <js@phil.uu.nl> 2Newsgroups: 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 3Subject: Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Software 4Approved: news-answers-request@MIT.EDU 5Followup-To: news.software.readers 6Summary: 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. 9X-Note: This is an updated and revised descendant of Ron Newman's GNKSA 1.2 10 11Archive-name: usenet/software/good-netkeeping-seal 12Posting-Frequency: monthly (first Sunday) 13Last-modified: Oct 29 2003 14X-Version: 2.09 ($Id: gnksa.hdr,v 1.8 2003/10/29 07:31:42 js Exp $) 15URL: <http://www.gnksa.org/> 16Maintainer: Jeroen Scheerder <js@gnksa.org> 17 18-----BEGIN PGP SIGNED MESSAGE----- 19 20 GNKSA * The Good Net-Keeping Seal of Approval 21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 23There's a general perception that Usenet is becoming "noisier" the more 24people join it. There are more blank articles, more mangled headers, 25more "me too" responses accompanying many lines of quoted text, more 26followup postings to inappropriate newsgroups, more misattributed 27quotes, more followups that really should have been e-mail replies, more 28excessive cross- and multi-postings, more unreadibly encoded or 29otherwise maimed articles. 30 31This is often blamed on the new users themselves -- they are called 32"clueless newbies", unqualified to participate in Usenet because they 33don't know Unix, or use a misdesigned graphical user interface (GUI), or 34use an off-line news reader, or use a commercial service such as America 35Online or Delphi. 36 37I believe most of this anger is misdirected. The new users aren't 38really that different from the old-timers. What _is_ different is that 39many of the old-timers are using relatively well-behaved software, 40while many of the newbies are using various PC newsreaders that frequently 41violate assumptions that come naturally to people used to well-behaved 42readers: 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 54Newer software should be an improvement over an ancient program like 55`rn'. Instead, much of it is crippled or broken in comparison. 56 57The Usenet community can deal with this problem by establishing a "Good 58Net-keeping Seal of Approval" for Usenet reading and posting software. 59This "Seal" would certify that the software complies with certain 60minimal standards, such as those listed below. 61 62A group of volunteers will test all putative Usenet software to 63determine whether it qualifies for the "Seal", with the intention to 64periodically post a list of all tested software to 65news.software.readers, alt.usenet.offline-reader, and other appropriate 66newsgroups. This periodic posting will list both compliant and 67non-compliant news programs; for non-compliant programs, it will include 68a list of all violations of the standards. The hope is that this will 69encourage the authors of non-compliant software to bring their programs 70up to "Good Net-Keeping Seal" standards, eventually. 71 72 73 --%-@#@-%-- 74 75 76These are the proposed standards a Usenet news program should meet to 77deserve 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 101These requirements are described in more detail below. In the spirit of 102RFC 1123 and Henry Spencer's "son of RFC 1036" proposal, I've 103capitalized the words "MUST", "MUST NOT", and "DO NOT" to indicate 104absolute requirements, while using the word "SHOULD" for things that are 105merely a Very Good Idea, Really. 106 107 108 --%-@#@-%-- 109 110 1111) Display all essential header information 112 113When displaying a news article, it MUST by default show the user certain 114information that is found in the article's header. The information need 115not be displayed as actual RFC-1036 header lines, but it MUST be shown 116to 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 136If the required information does not fit fully on the display, the 137software MAY display only the initial part of the information, provided 138that it offers the user a scrollbar or equivalent means of viewing the 139remainder. 140 141The software MAY allow the user to re-configure it so as to turn off 142these displays, but if the user has not done this, all of the required 143information MUST be displayed. 144 145Rationale: Without having to make any special effort the user should see 146who sent the article she is reading, how to reply to it via e-mail, what 147discussion groups it was posted to, and whether the author of the 148message wants to narrow or redirect the location of future discussion. 149 150 1512) Provide clear, separate commands for new posting, followup, and 152 e-mail reply 153 154The software MUST provide separate, clearly distinguished commands to do 155each 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 168Software that uses the English language is strongly encouraged to 169include the phrases "Post to newsgroup", "Followup to newsgroup", and 170"Reply by e-mail" (or "Reply to sender" or "Reply to author") -- in 171menus, on-line help, and written documentation. It SHOULD avoid using 172other verbs such as "Send" or "Respond" whose meaning is not evident to 173the user. An ordinary, untrained user SHOULD be able to easily pick the 174correct command. 175 176Rationale: Users who post followups when they should send e-mail 177replies, or vice versa, seem to be an endemic problem. They are almost 178always using software that doesn't make the difference clear, or doesn't 179even provide both commands. 180 181 1823) Provide cross-posting functionality 183 184When creating either a new article or a followup, the user MUST be 185allowed to specify multiple newsgroups, and the software MUST cross-post 186(not multi-post) to them if more than one is specified. 187 188Posting software SHOULD prevent the user from excessive cross-posting, 189or at least warn against it. If posting to a very large number of 190groups, the user SHOULD either be forced or strongly suggested to set a 191"Followup-To" header. Such a header must be subjected to restrictions 192that are at least as strict as those imposed on "Newsgroups: ". 193 194Rationale: Cross-posting is an essential feature of Usenet. If the 195software cannot cross-post, then its users will multi-post instead. A 196reasonable attempt should be made, however, to protect the user against 197(usually inadvertent; if not, often considered net-abuse) excessive 198cross-postings that will only lead to canceling and flame warfare. 199 200 2014) Allow users to change essential headers 202 203When creating either a new article or a followup, the software MUST 204allow the user to edit the Subject, Newsgroups, Followup-To, and 205Reply-To specifications. The user MUST be able to edit these at any 206time during composition of the article; she MUST NOT be limited to 207specifying them only before, or after, editing the article's text. 208 209The software MUST allow the user to specify a new Subject field of at 210least 70 characters, not including the string "Subject: " itself. It is 211better not to impose any limit at all, other than the overall 212son-of-1036 limit of 998 characters (see #7) per header line. 213 214The software MUST allow the user to specify "Followup-To: poster", which 215tells readers of the article that the user prefers e-mail replies rather 216than followups to the newsgroup. 217 218This does not mean that the software must present raw RFC-1036 headers 219to the user, or that the headers and body must be an indivisible unit of 220editable text. A graphical user interface that presents each of these 221as an editable field in a form will meet the requirement. 222 223Rationale: Topics drift as a discussion progresses, and users need the 224ability to change the Subject header to reflect the drift. Similarly, a 225user may determine that the discussion no longer belongs in some of the 226places that it started, or that its continuation needs to go elsewhere. 227The software must not impede the user's ability to make these 228judgments, possibly during the composition of her followup article. 229It's not acceptable to have users who respond to "Please direct 230followups appropriately" with "I can't; the software won't let me." 231 232 2335) Ensure followups and e-mail replies contain a correct Subject 234 235When creating either a followup article or an e-mail reply, the software 236MUST 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 251Exception: The software MAY try to compensate for other people's broken 252software by replacing non-standard prefixes (such as "Re^2: ", "Re(2): 253", "Re:" (no space), "RE: ", "re: " , or "Re: Re: ") by the standard 254prefix "Re: ". 255 256Rationale: These things should be obvious, but many authors of news 257software don't seem to understand the relevant sections of RFC 1036. 258Truncated "Subject: " headers, especially when gratuitous non-ASCII 259characters are also thrown in, are a major annoyance for users and can 260make threading difficult or impossible. 261 262 2636) Direct followups to the correct newsgroups 264 265When creating a followup article, the software MUST create an initial 266header in which the Newsgroups field is initialized to the original 267article'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 270If the original article's "Followup-To: " header is set to "poster", the 271software MUST warn the user that the original poster requested an e-mail 272reply, and generate an e-mail reply by default. 273 274Rationale: This is basic RFC 1036 compliance. Software that fails to 275meet this requirement makes its users look at best foolish or 276incompetent, and at worst willfully unresponsive to the wishes of other 277Usenet users. 278 279 2807) Make sure followups contain valid References 281 282When creating a followup, the software MUST create a "References: " 283header line that contains, as its last element, the Message-ID of the 284original article. An individual Message-ID MUST never be truncated. 285 286The software MUST include at least three additional Message-IDs from 287the original article's References header as well, if they are available. 288Try to stay as close as possible to the spirit of "son-of-1036", which 289states: 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 299However, 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 306So, bear in mind that news transports are not guaranteed to be able to 307handle arbitrary long lines. Furthermore, keep in mind that some news 308transports choke on continued (multi-line) "References: " headers. 309 310Therefore, 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 312byte of 8 bits, EOL representation takes two bytes.) 313 314Exception: Damaged (truncated) Message-IDs SHOULD NOT be included. 315Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by 316a misguided user, maybe) but don't belong to the thread. 317 318Rationale: Threaded news-readers depend on References to do their magic. 319This too is basic RFC compliance. Be as complete as the line length 320limit allows, but do not propagate errors. 321 322 3238) Direct e-mail replies to the correct address 324 325When creating an e-mail reply, the software MUST create an initial 326header in which the "To: " header is initialized to the original 327article's Reply-to, if one was provided, or From if it wasn't. (The 328user may later change this field, of course; see #4 above.) 329 330Rationale: See #6 above. 331 332 3339) Allow the user to change her mind about whether to post or mail 334 335With any followup or reply message, the software SHOULD offer the user 336the option to change her mind about whether to post or to mail, and may 337allow doing both. 338 339If the software has the option to post as well as mail a single 340response, that option MUST NOT be default behavior, neither by factory 341default nor by user-configuration. Furthermore, when both posting and 342mailing a message, the mailed message's body SHOULD be preceded by a 343line clearly stating that the message is an email copy of a usenet 344posting. 345 346Rationale: People digress when writing, and may find themselves posting 347a message that would have been more appropriate for private 348communication, or mailing a message that would have been more 349appropriately directed to the general audience. Unsolicited mail 350messages are highly unwanted by many users (had they wanted e-mail 351replies, they could, should and, for all a reader can assume would, have 352requested them). 353 354 35510) Provide adequate quotation and attribution facilities 356 357When the user requests a followup or an e-mail reply, the software MUST 358provide some method for including quoted text from the original article. 359This quoted text MUST be clearly set off in some way -- either by 360indenting it, or by prepending each line with one or more identifiable 361characters. The quote prefix SHOULD be `>', with optionally a trailing 362space (i.e. `> '). 363 364Caveat: 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 371Included text SHOULD NOT contain the original article's signature, 372unless by explicit request of the user (under the condition that the 373signature can be determined of course, which is to say: if clearly 374separated by the standard signature delimiter). (see also #15 below). 375 376As a direct counterpart to this requirement, the software SHOULD offer 377the user some means of selecting exactly which part of a Usenet posting 378she wishes to followup to, and quote only that part initially. (A 379special case of this is when a user wishes to react to what's in a 380signature.) 381 382If it concerns a followup (as opposed to an e-mail reply), the quoted 383text MUST be preceded by an "attribution line" identifying the author of 384the text that is being quoted. (The user may decide to delete this 385attribution line or to configure it away, but it MUST be there by 386default.) 387 388Rationale: The ability to easily quote text is essential for users who 389want to provide a proper context for their followups and e-mail replies. 390Software that provides attribution lines without quoting ability, or 391that fails to distinctively set off quoted text from original text, is a 392major cause of "I didn't say that!" misunderstandings. By convention, 393quoted lines start with `>', and much software depends on this do 394distinguish quoted material from original lines, for presentation 395purposes. Users can be careless or forgetful occasionally (or often, 396even) and neglect to edit out spurious quoted material; the signature, 397typically, is such material. In general, facilitating good quoting 398behaviour -- by quoting only a part indicated by the user, for example 399- - -- is an area in which software can help users substantially to create 400better articles. 401 402 40311) Provide a user-specified "Subject: " header 404 405When creating a new article, the software MUST require the user to 406provide a non-empty Subject. It MUST NOT post an article without a 407"Subject: " header or with an empty "Subject: " header. It MUST NOT 408silently add a default Subject (like "Subject: <None>") if the user 409didn't specify one. It MUST allow the user to change the Subject at any 410time while editing the main text of the article (see #4 above). 411 412Rationale: An article without a Subject provides no clues for deciding 413to read it or not. For that reason, it's likely to be widely ignored, 414and it's no service to the user to allow posting of such an article; 415while other readers may read it, only to find out they needn't have 416bothered when it annoyingly turns out to be of no interest. 417 418 41912) Provide a valid "From: " header 420 421When creating either a new article or a followup, the software MUST 422initialize the "From: " header to a syntactically valid e-mail address, 423which includes a fully-qualified domain name (FQDN). 424 425This 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 433If the software allows the user to edit the "From: " header, it SHOULD 434check that the user supplied a syntactically valid address. 435 436If the software is unable to create such an address -- maybe because it 437was built with incorrect configuration parameters, or some essential 438parameter is unavailable at runtime -- then it MUST NOT allow posting at 439all, unless it can obtain a syntactically valid e-mail address from the 440user. 441 442If feasible, the software SHOULD try to guarantee that this address 443actually belongs to the person using the software, and actually accepts 444e-mail. 445 446Rationale: Mail and news transport systems and user agents, gateways and 447processing software may choke on syntactically invalid headers. Invalid 448e-mail addresses make e-mail replies impossible; see Greg Byshank's 449"Help! I've been spammed!" document for an excellent discussion of the 450issues involved. 451 452 45313) Allow users to both cancel and supersede their own articles (and 454 _no_ others!) 455 456Any software that posts news SHOULD provide a command that the user can 457invoke to cancel her own articles. It SHOULD also provide the option to 458supersede the user's own articles. The software MUST guarantee that 459the user cannot cancel or supersede other people's articles, as far as 460possible. 461 462Caveat: 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 468If the software uses the English language, the text of the cancel 469command SHOULD include the word "cancel", rather than non-standard verbs 470such as "delete". Similarly, in English software, the text of the 471supersede command SHOULD include the word "supersede". 472 473Rationale: People make mistakes and need the ability to revoke or 474correct them; both `cancel' and `supersede' exist for good reasons. 475However, software should not encourage users to abuse the net, either 476intentionally or accidentally, by sending unauthorized (`rogue') cancels 477or supersedes. The supersede option is essential: due (a.o.) to 478sometimes unpredictable usenet propagation, a "cancel-cum-repost" may 479behave very different from a "supersede". News servers might also have 480different acceptance policies for both. 481 482 48314) Try to respect the 80-character line-length conventions 484 485Any line breaks shown to the user while she is editing her article 486SHOULD still be present when the article is actually posted to the Net. 487The software SHOULD NOT show the user four 75-character lines while 488actually posting a single 300-character line. Nor should it show the 489user a series of 100-character lines while actually posting alternating 490lines of 80 and 20 characters each. 491 492It's also a good idea to warn the user if the article she is about to 493post contains non-header lines longer than 80 characters. The software 494SHOULD NOT prevent the posting, but SHOULD ask whether the user wants to 495re-edit or post anyway. 496 497Caveat: 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 504To get well-readable articles, the user SHOULD be provided with the 505possibility to rewrap excessively long lines of quoted text, respecting 506quotation -- i.e. have the option to correct `inherited' bad formatting. 507Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that 508may occur when someone reading your article uses a different tab size. 509 510Caveat: 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 517If the news software uses an external editor, the default editor SHOULD 518conform to the above. 519 520Rationale: Articles with long lines are unreadable to many users. 521 Articles with alternating 80/20 lines aren't any better. 522 523 52415) Separate signatures correctly, and don't use excessive ones 525 526Posting software SHOULD separate any signature appended to outgoing 527articles from the main text with a line containing only `-- ' ("dash 528dash 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 538Hence, posting software SHOULD prevent the user from using excessively 539long signatures, or at least warn the user against it. A widely 540accepted standard is the so-called McQuary limit: up to 4 lines, each up 541to a maximum of 80 characters. 542 543Rationale: Being confronted with (possibly excessively long) signatures 544repetitively is, or can be, annoying to many. Being able to separate 545the main text and the signature clearly is important, not only to 546prevent the possible mistake of misinterpreting a signature, but also to 547enable automatic signature suppression for those who wish to do so. 548 549 55016) 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 575Note: 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 583Rationale: Users who do any of these things almost never do them on 584purpose. They are usually confused by unfamiliar new software, and 585should be offered basic protection. 586 587 58817) Post human-readable articles unless ordered otherwise 589 590Posting software MUST by default post only legible usenet articles. In 591a different formulation: it MUST NOT encode or encrypt articles, unless 592by explicit user demand. Hence, it MUST NOT even have the option to 593encode or encrypt by default. Whenever some encoding/encryption will be 594used, clear feedback showing that it's in effect MUST be provided to the 595user, so she is permanently reminded of the fact that her article will 596not be posted as composed. The worst DO NOT is the combination of 597allowing default encoding without even taking the trouble of telling 598(warning) the user about it. 599 600Note: 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 605Rationale: Many users may not be able to read (particular) encoded or 606encrypted articles at all, or only at the expense of a considerable 607effort: such articles ask to be widely ignored. Encouraging posting 608maimed messages is a service neither to the user herself, nor to her 609audience. Keep in mind that not everyone shares your particular setup 610(newsreader, configuration, operating system), nor should (and can) 611anyone be forced to do so, in order to be able to read your articles. 612 613 61418) Provide self-protection 615 616News readers SHOULD allow the user to protect herself by filtering out 617articles she really does not want to read. These filtering facilities 618SHOULD be sufficiently powerful to enable ignoring postings by 619particular persons, about particular subjects, and particular 620cross-posts. 621 622Rationale: While it looks as if not having filtering only affects the 623user herself, people tend to take it out on the net if they are 624repetitively (structurally) annoyed by a particular class of postings, 625and will be inclined to start canceling, advocate posting restriction or 626engage in flame warfare, all of which is harmful to other users. 627 628 62919) Be kind to servers, leave room for others 630 631Reading or posting software MUST NOT put excessive demands on news 632servers unnecessarily. The software MUST limit itself to 4 simultaneous 633connections to a given server. Spurious connects and unnecessary 634traffic MUST be avoided; the software MUST use as few as possible 635connections, reusing existing connections whenever possible. 636 637Rationale: News systems are big, resources are scarce, and every 638resource claimed is provided at the expense of other users. 639 640 641 --%-@#@-%-- 642 643 644Please remember that this is a set of _minimum_ guidelines to guarantee 645that a given piece of software interacts properly with the rest of the 646Usenet world. It is not a general "wish list" of everyone's favorite 647features. I have deliberately avoided taking a position on certain 648controversial issues -- for example, whether the user should be allowed 649to edit the "Sender: " header, whether news software should prohibit 650posting an article that has more quoted text than new text, or whether 651posting with certain particular Subjects should be prohibited. 652 653 654My hope is that a voluntary committee can be formed, respected by many 655people on the Net, that reviews Usenet software and decides whether it 656deserves the "Good Net-Keeping Seal of Approval." People who use broken 657software that does not have the Seal should then be strongly encouraged 658to switch to software that does. 659 660 661References and additional reading 662~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 663 664The current GNKSA, an evaluation form and an archive of software 665evaluations 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 671The GNKSA page also contains a pointer to a library that newsreader 672developers can freely make use of, providing basic `sanitary' functions. 673 674In addition to the Seal, anyone writing Usenet software should pay 675careful 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 705Excellent collections of things well worth reading in this context can 706be 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 714A very informative overview of the issues concerning some forms of net 715abuse, 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 725Of related interest -- if you're willing to contribute, or are just 726interested in the way things are developing -- could also be the IETF 727NNTP Working Group's "attempt to revise NNTP and bring it into the 7281990s". 729 <http://www.academ.com/academ/nntp/ietf.html> 730 731 732Acknowledgements 733~~~~~~~~~~~~~~~~ 734 735Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working 736Group initiative (and its derivatives). 737 738Ron Newman <rnewman@theCIA.net>, of course, for writing the first 739version of the GNKSA, of which this document descends, and for 740fruitful discussions during revision. 741 742Sven Guckes <guckes@math.fu-berlin.de> for providing mailing list 743resources (among other things). 744 745Tim Pierce <twpierce@midway.uchicago.edu> for scrutinous examination, 746useful hints, and previous GNKSA support. 747 748Larry Wall <lwall@netlabs.com>, Stefan Haller <stk@berlin.snafu.de>, 749John E. Davis <davis@space.mit.edu>, John Norstad <j-norstad@nwu.edu>, 750Karl-Johan Johnsson <su95-kjo@nada.kth.se>, Brian Clark <baclark@nwu.edu>, 751Simon Fraser <smfr@best.com> for showing inspiring examples of the spirit 752of good net keeping in the form of exceptionally well-designed usenet 753reading programs. 754 755The kind folks of news.software.readers (you know who you are) that 756have helped discussing the issues that pertain to the GNSKA cause. 757 758-----BEGIN PGP SIGNATURE----- 759Version: PGP 6.5.8 760 761iQCVAwUBP59sFihIY6bIQPMpAQGv2QQAhD1M2vo6ASncrrVitDfVuyLY4WuFc607 76224G73/uxY41/6PdzLkTe3+9Lb8RUjHhgNZvMJDc42H3veV177jHkOMOnkAHL3Nvl 763936CzXPxAsnn3YSmrCFT+cRrepvdYVoxPKu3wbhpJNTDcoyI5OcUFyOYhwKRpg31 764sVBe/csBC9g= 765=Typt 766-----END PGP SIGNATURE----- 767