"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 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-----