Subject: Minimally Adequate Net-Keeping Seal of Approval (MANKSA) for Usenet Software
Date: 7 Sep 1997 00:00:03 +0200
X-Trace: moe.serv.phil.ruu.nl 873583203 12836 (None) 131.211.140.150
X-Complaints-To: newsmaster@phil.ruu.nl
Summary: Guidelines for writers of Usenet reading and posting programs.
  If you follow these guidelines,  you'll  make your users and the rest
  of the Usenet community much happier.

Archive-name: usenet/software/minimal-netkeeping
Posting-Frequency: monthly (first Sunday)
Last-modified: 1997/09/02
Version: 1.0
URL: <http://www.xs4all.nl/%7Ejs/manksa/>
Maintainer: Jeroen Scheerder <js@xs4all.nl>

-----BEGIN PGP SIGNED MESSAGE-----

      MANKSA * The Minimally Adequate Net-Keeping Seal of Approval
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There's a general perception that  Usenet is becoming "noisier" the more
people join  it.  There are  more blank articles, more  mangled headers,
more  "me  too"  responses  accompanying  many  lines  of  quoted  text,
more followup  postings to inappropriate newsgroups,  more misattributed
quotes,  more followups  that really  should have  been e-mail  replies,
more  excessive cross-  and multi-postings,  more unreadibly  encoded or
otherwise maimed articles.

This is  often blamed  on the  new users themselves  -- they  are called
"clueless newbies",  unqualified to  participate in Usenet  because they
don't know Unix, or use a misdesigned graphical user interface (GUI), or
use an off-line news reader, or use a commercial service such as America
Online or Delphi.

I  believe most  of this  anger is  misdirected.  The  new users  aren't
really that different from the  old-timers.  What _is_ different is that
many  of  the old-timers  are  using  relatively well-behaved  software,
typically  `rn' or  one  of its  offspring, while  many  of the  newbies
are  using `tin',  `uqwk', `AOL',  or  various PC  and Mac  newsreaders.
Unfortunately, these  programs frequently violate assumptions  that come
naturally to people used to well-behaved readers:

  - The  user can  see all header  fields, including  "Newsgroups" and
    "Followup-To".
  - The user can edit all header fields when composing a followup.
  - There's a clear difference between `followup' and `reply'.
  - Followups preserve  the Subject  and References  of  the  original
    article, unless the user explicitly changes them.
  - News   software    respects    "Followup-To"     and    "Reply-To"
    specifications.
  - What the user writes is what gets posted, as is.

Newer software  should be  an improvement over  an ancient  program like
`rn'.  Instead, much of it is crippled or broken in comparison.

The  Usenet community  can  deal  with this  problem  by establishing  a
"Minimally Adequate Net-keeping Seal of Approval" for Usenet reading and
posting software. This  "Seal" would certify that  the software complies
with certain minimal standards, such as those listed below.

A  group   of  volunteers  will   test  all  putative   Usenet  software
to   determine  whether   it  qualifies   for  the   "Seal",  with   the
intention  to  periodically  post  a  list of  all  tested  software  to
news.software.readers, alt.usenet.offline-reader,  and other appropriate
newsgroups.   This  periodic  posting   will  list  both  compliant  and
non-compliant news programs; for non-compliant programs, it will include
a list of all  violations of the standards.  The hope  is that this will
encourage the authors of non-compliant  software to bring their programs
up to "Minimally Adequate Net-Keeping Seal" standards, eventually.


                              --%-@#@-%--


These are  the proposed standards a  Usenet news program should  meet to
deserve the "Minimally Adequate Net-Keeping Seal":

  1)  Display all essential header information
  2)  Provide clear, separate commands for new  posting, followup, and
      e-mail reply
  3)  Provide cross-posting functionality
  4)  Allow users to change essential headers
  5)  Ensure followups and e-mail replies contain a correct Subject
  6)  Direct followups to the correct newsgroups
  7)  Make sure followups contain valid References
  8)  Direct e-mail replies to the correct address
  9)  Allow the user to change her mind about whether to post or mail
  10) Provide adequate quotation and attribution facilities
  11) Provide a user-specified "Subject: " header
  12) Provide a valid "From: " header
  13) Allow users to both cancel and supersede their own articles (and
      _no_ others!)
  14) Try to respect the 80-character line-length convention
  15) Separate signatures correctly, and don't use excessive ones
  16) Try to prevent obvious user errors
  17) Post human-readable articles unless ordered otherwise
  18) Provide self-protection
  19) Be kind to servers, leave room for others

These requirements  are described in  more detail below.  In  the spirit
of  RFC 1123  and  Henry  Spencer's "son  of  RFC  1036" proposal,  I've
capitalized  the words  "MUST", "MUST  NOT",  and "DO  NOT" to  indicate
absolute requirements, while using the word "SHOULD" for things that are
merely a Very Good Idea, Really.


                              --%-@#@-%--


1)  Display all essential header information

When displaying a news article, it MUST by default show the user certain
information that is found in the article's header.  The information need
not be displayed  as actual RFC-1036 header lines, but  it MUST be shown
to the user in some form.

  a) The author of the article (its "From: " header line)

  b) The  article's  Subject.   At  least   the  first  70  characters
     following the "Subject: " string MUST be displayed.

  c) The list of newsgroups the article was posted to.  This list MUST
     be displayed  in full,  never truncated.  This  list need  not be
     displayed if it has only  one element, provided that the software
     displays the  name of  the newsgroup that  the user  is currently
     reading.

  d) The  article's Followup-To  list, if this  is different  from the
     Newsgroups  list.    This  MUST  be  displayed   in  full,  never
     truncated.

  e) The article's  Reply-To,  if  this  is  different  from the  From
     specification.

If  the required  information does  not fit  fully on  the display,  the
software MAY display only the  initial part of the information, provided
that it offers  the user a scrollbar or equivalent  means of viewing the
remainder.

The software  MAY allow the  user to re-configure it  so as to  turn off
these displays, but if  the user has not done this,  all of the required
information MUST be displayed.

Rationale: Without having to make any special effort the user should see
           who sent the  article she is reading, how to  reply to it via
e-mail, what discussion groups it was  posted to, and whether the author
of  the message  wants  to narrow  or redirect  the  location of  future
discussion.


2)  Provide clear,  separate  commands for  new  posting, followup,  and
    e-mail reply

The software MUST provide separate, clearly distinguished commands to do
each of the following:

  a) Post a new article, unrelated  to any existing one, whose Subject
     is to be supplied by the user,  and which has an empty or missing
     References: header line.

  b) Post a followup article, with Subject, Newsgroups, and References
     header lines derived appropriately from the original article.
                                             (see #5, #6, and #7 below)

  c) Reply  by e-mail,  with "Subject: "  and  "To: "  headers derived
     appropriately from the original article.    (see #5 and #8 below)

Software  that  uses the  English  language  is strongly  encouraged  to
include the  phrases "Post to  newsgroup", "Followup to  newsgroup", and
"Reply by  e-mail" (or  "Reply to  sender" or "Reply  to author")  -- in
menus, on-line help,  and written documentation.  It  SHOULD avoid using
other verbs such as "Send" or  "Respond" whose meaning is not evident to
the user.  An ordinary, untrained user SHOULD be able to easily pick the
correct command.

Rationale: Users  who  post  followups  when  they  should  send  e-mail
           replies, or vice versa, seem  to be an endemic problem.  They
are almost always using software that doesn't make the difference clear,
or doesn't even provide both commands.


3)  Provide cross-posting functionality

When  creating either  a new  article or  a followup,  the user  MUST be
allowed to specify multiple newsgroups, and the software MUST cross-post
(not multi-post) to them if more than one is specified.

Posting software  SHOULD prevent the user  from excessive cross-posting,
or at  least warn  against it.   If posting  to a  very large  number of
groups, the user SHOULD either be  forced or strongly suggested to set a
"Followup-To" header.  Such  a header must be  subjected to restrictions
that are at least as strict as those imposed on "Newsgroups: ".

Rationale: Cross-posting  is an  essential  feature of  Usenet.  If  the
           software  cannot cross-post,  then its users  will multi-post
instead.  A reasonable  attempt should be made, however,  to protect the
user against  (usually inadvertent; if not,  often considered net-abuse)
excessive  cross-postings that  will only  lead to  canceling and  flame
warfare.


4) Allow users to change essential headers

When creating  either a  new article  or a  followup, the  software MUST
allow  the  user  to  edit the  Subject,  Newsgroups,  Followup-To,  and
Reply-To specifications.   The user MUST  be able  to edit these  at any
time  during composition  of the  article; she  MUST NOT  be limited  to
specifying them only before, or after, editing the article's text.

The software MUST  allow the user to  specify a new Subject  field of at
least 70 characters, not including the string "Subject: " itself.  It is
better  not  to  impose  any  limit  at  all,  other  than  the  overall
son-of-1036 limit of 998 characters (see #7) per header line.

The software MUST allow the user to specify "Followup-To: poster", which
tells readers of the article that the user prefers e-mail replies rather
than followups to the newsgroup.

This does not  mean that the software must present  raw RFC-1036 headers
to the user, or that the headers and body must be an indivisible unit of
editable text.  A  graphical user interface that presents  each of these
as an editable field in a form will meet the requirement.

Rationale: Topics drift as  a discussion progresses, and  users need the
           ability  to change the  Subject header to reflect  the drift.
Similarly, a user may determine that the discussion no longer belongs in
some of the places that it started, or that its continuation needs to go
elsewhere.   The software  must not  impede the  user's ability  to make
these  judgments,  possibly  during  the  composition  of  her  followup
article.   It's not  acceptable to  have  users who  respond to  "Please
direct followups  appropriately" with "I  can't; the software  won't let
me."


5) Ensure followups and e-mail replies contain a correct Subject

When creating either a followup article or an e-mail reply, the software
MUST create an initial "Subject: " header which

  a) Prepends the four characters "Re: " to the Subject if and only if
     "Re: "  is  not  already  present.  Note  that  this contains  an
     upper-case "R", a  lower-case "e", and a trailing  space.  DO NOT
     prepend non-standard prefixes such as "Re^2: " .

  b) Preserves  the *entire* Subject  of the original  article. DO NOT
     chop it  off at 20  or 25 or even  80 characters.  DO  NOT append
     spaces or  any other characters  to the  end.  DO NOT  change the
     case of any character in  the original Subject; in particular, DO
     NOT change the Subject to all-upper-case or all-lower-case.

  (The user may later change the Subject, of course; see #4 above.)

Exception: The software MAY try to  compensate for other people's broken
software by replacing  non-standard prefixes (such as  "Re^2: ", "Re(2):
", "Re:"  (no space),  "RE: ", "re: " , or "Re: Re: ")  by  the standard
prefix "Re: ".

Rationale: These  things should  be obvious,  but many  authors of  news
           software  don't seem to  understand the relevant  sections of
RFC  1036.  Truncated  "Subject: "  headers, especially  when gratuitous
non-ASCII characters are also thrown in, are a major annoyance for users
and can make threading difficult or impossible.


6) Direct followups to the correct newsgroups

When creating  a followup article,  the software MUST create  an initial
header  in which  the Newsgroups  field is  initialized to  the original
article's Followup-To, if one was provided, or Newsgroups, if it wasn't.
(The user may later change this field, of course; see #4 above.)

If the original article's "Followup-To: " header is set to "poster", the
software MUST warn the user that the original poster requested an e-mail
reply, and generate an e-mail reply by default.

Rationale: This  is  basic RFC  1036  compliance.   Software that  fails
           to meet this requirement makes its users look at best foolish
or incompetent,  and at  worst willfully unresponsive  to the  wishes of
other Usenet users.


7) Make sure followups contain valid References

When  creating a  followup, the  software MUST  create a  "References: "
header line  that contains, as its  last element, the Message-ID  of the
original article.  An individual Message-ID MUST never be truncated.

The software SHOULD  include at least three  additional Message-IDs from
the original article's References header as well, if they are available.
Try to stay  as close as possible to the  spirit of "son-of-1036", which
states:

        <<Followup agents SHOULD not shorten References  headers.   If
          it  is absolutely necessary to shorten the header, as a des-
          perate last resort, a followup agent MAY do this by deleting
          some  of  the  message IDs.  However, it MUST not delete the
          first message ID, the last three message IDs (including that
          of  the immediate precursor), or any message ID mentioned in
          the body of the followup.>>

However, it also says:

        <<If  it  is  absolutely  necessary  for  an implementation to
          impose a limit on the length of header lines, body lines, or
          header  logical  lines,  that  limit  shall be at least 1000
          octets, including EOL representations.>>

So, keep in mind  that news transports are not guaranteed  to be able to
handle arbitrary long  lines.  Furthermore, keep in mind  that some news
transports choke on continued (multi-line) "References: " headers.

Therefore, keep as many Message-IDs as will fit in under 998 characters,
unwrapped.  (An  octet is  a byte  of 8  bits, EOL  representation costs
two.)

Exception: Damaged  (truncated)  Message-IDs  SHOULD  NOT  be  included.
Neither should `bogus' Message-IDs --  IDs that somehow got inserted (by
a misguided user, maybe) but don't belong to the thread.

Rationale: Threaded news-readers depend on References to do their magic.
           This too is basic RFC compliance.  Be as complete as the line
length limit allows, but do not propagate errors.


8) Direct e-mail replies to the correct address

When  creating an  e-mail reply,  the  software MUST  create an  initial
header  in which  the  "To: "  header  is  initialized  to the  original
article's Reply-to,  if one was  provided, or  From if it  wasn't.  (The
user may later change this field, of course; see #4 above.)

Rationale: See #6 above.


9) Allow the user to change her mind about whether to post or mail

With any followup or reply message, the software MUST offer the user the
option to  change her  mind about whether  to post or  to mail,  and may
allow doing both.

If  the software  has  the option  to  post  as well  as  mail a  single
response, that option  MUST NOT be default behavior,  neither by factory
default nor  by user-configuration.  Furthermore, when  both posting and
mailing a  message, the mailed  message's body  SHOULD be preceded  by a
line  clearly stating  that the  message is  an email  copy of  a usenet
posting.

Rationale:   People  digress  when  writing,  and  may  find  themselves
posting  a message  that would  have been  more appropriate  for private
communication,  or  mailing   a  message  that  would   have  been  more
appropriately  directed  to  the  general  audience.   Unsolicited  mail
messages  are highly  unwanted by  many  users (had  they wanted  e-mail
replies, they could, should and, for all a reader can assume would, have
requested them).


10) Provide adequate quotation and attribution facilities

When the users requests a followup or an e-mail reply, the software MUST
provide some method for including quoted text from the original article.
This  quoted text  MUST be  clearly set  off in  some way  -- either  by
indenting it, or  by prepending each line with one  or more identifiable
characters.  The quote prefix SHOULD start with `>'.

Included text SHOULD NOT contain the original article's signature, if it
can --  i.e. if  it can tell  which part is  the signature,  because the
signature  was clearly  separated by  the standard  signature delimiter.
(see also #15 below).

If this is a  followup (as opposed to an e-mail  reply), the quoted text
MUST be preceded by an "attribution  line" identifying the author of the
text that  is being quoted,  and preferably  also the Message-ID  of the
article  containing that  text.  (The  user  may decide  to delete  this
attribution  line or  to configure  it  away, but  it MUST  be there  by
default.)

Rationale: The ability to  easily quote text is essential  for users who
            want to  provide a  proper context  for their  followups and
e-mail  replies.   Software  that  provides  attribution  lines  without
quoting  ability, or  that fails  to distinctively  set off  quoted text
from  original  text,  is  a  major   cause  of  "I  didn't  say  that!"
misunderstandings.  By convention, quoted lines start with `>', and much
software depends  on this do  distinguish quoted material  from original
lines, for presentation purposes.


11) Provide a user-specified "Subject: " header

When  creating a  new article,  the software  MUST require  the user  to
provide a  non-empty Subject.   It MUST  NOT post  an article  without a
"Subject: "  header or with  an empty "Subject: "  header.  It  MUST NOT
silently  add a  default Subject  (like "Subject: <None>")  if the  user
didn't specify one.  It MUST allow the user to change the Subject at any
time while editing the main text of the article (see #4 above).

Rationale: An  article without a  Subject provides no clues for deciding
           to read it or not.  For that reason, it's likely to be widely
ignored, and  it's no service  to the user to  allow posting of  such an
article; while other readers may read  it, only to find out they needn't
have bothered when it annoyingly turns out to be of no interest.


12) Provide a valid "From: " header

When creating  either a  new article  or a  followup, the  software MUST
initialize the "From: " header  to a syntactically valid e-mail address,
which includes a fully-qualified domain name (FQDN).

This requirement must be met regardless of whether the software

  (a) creates the "From: " header when it first creates the article to
      be edited by the user, or

  (b) adds the  "From: " header automatically after  the user finishes
      editing the article and requests that it be submitted.

If the software allows  the user to edit the "From: "  header, it SHOULD
check that the user supplied a syntactically valid address.

If the software is unable to create  such an address -- maybe because it
was  built with  incorrect configuration  parameters, or  some essential
parameter is unavailable at runtime -- then it MUST NOT allow posting at
all, unless it can obtain a  syntactically valid e-mail address from the
user.

If  feasible, the  software SHOULD  try to  guarantee that  this address
actually belongs to the person  using the software, and actually accepts
e-mail.

Rationale: Mail  and news  transport systems  and user  agents, gateways
           and  processing software may choke  on syntactically  invalid
headers.  Invalid  e-mail addresses make e-mail  replies impossible; see
Greg  Byshank's "Help! I've  been  spammed!" document  for an  excellent
discussion of the issues involved.


13) Allow  users to both  cancel and  supersede their own  articles (and
    _no_ others!)

Any software that posts news SHOULD  provide a command that the user can
invoke to cancel her own articles.  It SHOULD also provide the option to
supersede  own articles.   The  software MUST  guarantee  that the  user
cannot cancel or supersede other people's articles, as far as possible.

Caveat: since completely reliable  authentication can be infeasible, the
        best  the software  can do  is to  make a  good-faith effort  to
        determine  whether or  not cancelling  or superseding  is valid:
        i.e. by  trusting upon  its user  configuration and  checking it
        against the relevant header(s) in the target article.

If  the software  uses  the English  language, the  text  of the  cancel
command SHOULD include the word "cancel", rather than non-standard verbs
such  as "delete".   Similarly, in  English  software, the  text of  the
supersede command SHOULD include the word "supersede".

Rationale: People  make  mistakes and  need  the  ability to  revoke  or
           correct  them; both `cancel'  and `supersede' exist  for good
reasons.  However, software should not encourage users to abuse the net,
either intentionally or accidentally,  by sending unauthorized (`rogue')
cancels or supersedes.  The supersede option is essential: due (a.o.) to
sometimes  unpredictable usenet  propagation, a  "cancel-cum-repost" may
behave very different from a  "supersede".  News servers might also have
different acceptance policies for both.


14) Try to respect the 80-character line-length convention

Any  line breaks  shown to  the user  while she  is editing  her article
SHOULD still be present when the  article is actually posted to the Net.
The  software SHOULD  NOT show  the user  four 75-character  lines while
actually posting  a single 300-character  line.  Nor should it  show the
user a series of 100-character  lines while actually posting alternating
lines of 80 and 20 characters each.

It's also a  good idea to warn the  user if the article she  is about to
post contains non-header lines longer  than 80 characters.  The software
SHOULD NOT prevent the posting, but SHOULD ask whether the user wants to
re-edit or post anyway.

Caveat: Occasionally, there are very good  reasons for posing long lines
        (for  example, when  posting  a source  code snippet  containing
        something that will  break when wrapped, or when  there's a need
        to  post  something  "as  is", unreformatted  --  unaltered  and
        completely intact).   For that  reason (re)wrapping cannot  be a
        MUST: a SHOULD is all it can be.

To  get well-readable  articles, the  user SHOULD  be provided  with the
possibility to rewrap excessively long  lines of quoted text, respecting
quotation -- i.e. have the option to correct `inherited' bad formatting.
Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that
may occur when someone reading your article uses a different tab size.

Caveat: Due  to  the immense  variety  in  quoting styles,  quoted  text
        reformatting can be extremely hard, practically impossible even.
        No  software can  be expected  to deal  with everything;  still,
        since the overwhelming majority  can be dealt relatively easily,
        it is not  unreasonable to expect it from software,  if it is to
        be well-equipped for the task of editing Usenet articles.

If the news software uses an  external editor, the default editor SHOULD
conform to the above.

Rationale: Articles  with  long  lines  are unreadable  to  many  users.
           Articles with alternating 80/20 lines aren't any better.


15) Separate signatures correctly, and don't use excessive ones

Posting  software  SHOULD separate  any signature  appended to  outgoing
articles from  the main text  with a line  containing only `-- '  ("dash
dash space"). To quote son-of-rfc1036:

        <<If  a  poster or posting agent does append a signature to an
          article, the signature SHOULD be preceded with  a  delimiter
          line  containing  (only)  two hyphens (ASCII 45) followed by
          one blank (ASCII  32).   Posting  agents  SHOULD  limit  the
          length  of  signatures,  since  verbose  excess bordering on
          abuse is common if no restraint is imposed;  4  lines  is  a
          common limit.>>

Hence, posting  software MUST  prevent the  user from  using excessively
long  signatures, or  at  least  warn the  user  against  it.  A  widely
accepted standard is the so-called McQuary limit: up to 4 lines, each up
to a maximum of 80 characters.

Rationale: Being confronted with  (possibly excessively long) signatures
           repetitively is, or can be,  annoying to many.  Being able to
separate the main text and the  signature clearly is important, not only
to prevent the possible mistake of misinterpreting a signature, but also
to enable automatic signature suppression for those who wish to do so.


16) Try to prevent obvious user errors

* Posting  software MUST warn the  user for posting empty  articles, and
  SHOULD prevent doing so entirely.

* Posting software MUST warn  the user about posting articles consisting
  entirely of quoted text, and SHOULD prevent doing so entirely.

* Posting software  MUST warn the user severely when  attempting to post
  an article  over and over  again, and SHOULD  do everything it  can to
  prevent doing so entirely.

  - When posting  `asynchronously'  (i.e.  when sacrificing  knowledge
    about  progress,  success or  failure  by  handing over  the  task
    completely to some separate process)  it SHOULD NOT allow the user
    to  post articles  again, once  the user  issued the  final "post"
    command.

  - When  posting `synchronously', the  software has at  least partial
    knowledge  about progress,  and  full knowledge  about success  or
    failure of an attempt to post.  In this case, it SHOULD inform the
    user clearly that the article  is being posted while attempting to
    post it; after the attempt,  it MUST unequivocally inform the user
    that posting succeeded if it did, and that it failed otherwise.

Note: So-called  `online'  newsreaders  usually  (but  not  necessarily)
      post synchronously, while a number so-called `offline' newsreading
      methods  (especially the  scheduled, batch-oriented  ones) usually
      employ asynchronous  posting.  However, offline  newsreaders using
      NNTP for  news transport usually  post synchronously, i.e.  are in
      direct  interaction  with  the  newsserver,  hence  get  immediate
      results, when posting.

Rationale: Users who  do any  of these  things almost  never do  them on
           purpose.   They  are   usually  confused  by  unfamiliar  new
software, and should be offered basic protection.


17) Post human-readable articles unless ordered otherwise

Posting software MUST by default  post only legible usenet articles.  In
a different formulation: it MUST  NOT encode or encrypt articles, unless
by explicit  user demand.  Hence,  it MUST NOT  even have the  option to
encode or encrypt by default.  Whenever some encoding/encryption will be
used, clear feedback showing that it's in effect MUST be provided to the
user, so she  is permanently reminded of the fact  that her article will
not  be posted  as composed.   The worst  DO NOT  is the  combination of
allowing default  encoding without  even taking  the trouble  of telling
(warning) the user about it.

Note: Common occurrences  of this kind  of content maiming  unasked for,
      and  untold   to,  the  user,   are  HTML-  and   MIME  multi-part
      and/or  base64 encodings,  as found  in newsreaders  integrated in
      WWW-browsers better not mentioned.

Rationale: Many users  may not be  able to read (particular)  encoded or
           encrypted  articles  at  all,  or  only  at  the  expense  of
a  considerable  effort:  such  articles   ask  to  be  widely  ignored.
Encouraging posting  maimed messages  is a service  neither to  the user
herself, nor  to her audience.   Keep in  mind that not  everyone shares
your particular setup (newsreader, configuration, operating system), nor
should (and can) anyone be forced to do  so, in order to be able to read
your articles.


18) Provide self-protection

News  readers SHOULD  allow the  user  to protect  herself by  filtering
out  articles  she  really  does  not want  to  read.   These  filtering
facilities SHOULD  be sufficiently powerful to  enable ignoring postings
by  particular  persons,  about   particular  subjects,  and  particular
cross-posts.

Rationale: While it  looks as if  not having filtering only  affects the
           user herself, people  tend to take it out on  the net if they
are  repetitively  (structurally)  annoyed  by  a  particular  class  of
postings,  and will  be inclined  to start  canceling, advocate  posting
restriction or engage in flame warfare, all of which is harmful to other
users.


19) Be kind to servers, leave room for others

Reading  or posting  software MUST  NOT  put excessive  demands on  news
server unnecessarily.  Spurious connects and unnecessary traffic MUST be
avoided.

Rationale: News  systems  are  big,  resources  are  scarce,  and  every
           resource claimed is provided at the expense of other users.


                              --%-@#@-%--


Please remember that this is a  set of _minimum_ guidelines to guarantee
that a given  piece of software interacts properly with  the rest of the
Usenet world.   It is not a  general "wish list" of  everyone's favorite
features.   I have  deliberately avoided  taking a  position on  certain
controversial issues -- for example,  whether the user should be allowed
to edit  the "Sender: "  header, whether  news software  should prohibit
posting an article  that has more quoted text than  new text, or whether
posting with certain particular Subjects should be prohibited.


My hope is  that a voluntary committee can be  formed, respected by many
people on the  Net, that reviews Usenet software and  decides whether it
deserves the "Minimally Adequate  Net-Keeping Seal of Approval."  People
who  use broken  software that  does not  have the  Seal should  then be
strongly encouraged to switch to software that does.


References and additional reading
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MANKSA, an evaluation form and an archive of software evaluations can be
found at:

  <http://www.xs4all.nl/%7Ejs/manksa/>
  <http://http.bsd.uchicago.edu/%7Etwpierce/news/> (GNKSA)

In  addition to  the Seal,  anyone  writing Usenet  software should  pay
careful attention to these two documents:

  RFC 977, "Network News Transfer  Protocol -- A Proposed Standard for
  the Stream-Based  Transmission of  News", by  Brian Kantor  and Phil
  Lapsley.
        <ftp://ftp.internic.net/rfc/rfc977.txt>

  RFC  1036,  "Standard  for   Interchange  of  USENET  Messages",  by
  M. Horton and R. Adams.
        <ftp://ftp.internic.net/rfc/rfc1036.txt>

  The proposed "Son of 1036",  "News Article Format and Transmission",
  by Henry Spencer.
        <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>    (also news.ps.Z)

  "Read This Before You Write a Newsreader, News Transport
  System, etc.", by Tom Limoncelli.
        <http://http.bsd.uchicago.edu/%7Etwpierce/news/newsreader-manifesto.html>

  "The  "Good  Net-Keeping  Seal  of Approval",  by  Ron  Newman;  the
  document this document leans heavily upon.
        <http://www2.thecia.net/users/rnewman/Good-Netkeeping-Seal>

Excellent collections of  things well worth reading in  this context can
be found at:

  "News Hacking", by Tim Pierce.
        <http://http.bsd.uchicago.edu/%7Etwpierce/news/>

  "Notes on News", by Lars Magne Ingebrigtsen.
        <http://www.ifi.uio.no/%7Elarsi/notes/notes.html>

A very informative  overview of the issues concerning some  forms of net
abuse, and how and how not to deal with it, is:

  "Help! I've been Spammed! What do I  do?", by Greg Byshenk, based in
  part on an  original by Chris Lewis, Posted  weekly to news.answers,
  news.newusers.questions, and news.admin.net-abuse.misc.
        <http://www.tezcat.com/%7Egbyshenk/ive.been.spammed.html>
  The  part  that explicitly  deals  with  the  issues of  messing  up
  "From: "-headers is:
        <http://www.tezcat.com/%7Egbyshenk/ive.been.spammed.html#2.3>

Of related  interest --  if you're  willing to  contribute, or  are just
interested in  the way things are  developing -- could also  be the IETF
NNTP  Working Group's  "attempt to  revise NNTP  and bring  it into  the
1990s".
        <http://www.academ.com/academ/nntp/ietf.html>


Acknowledgements
~~~~~~~~~~~~~~~~

Ron Newman <rnewman@theCIA.net>, of course, for writing the GNKSA.

Sven  Guckes  <guckes@math.fu-berlin.de>   for  providing  mailing  list
resources (among other things).

Tim  Pierce <twpierce@midway.uchicago.edu>  for scrutinous  examination,
useful hints, and previous GNKSA support.

Larry  Wall  <lwall@netlabs.com>,  Stefan  Kurth  <stk@berlin.snafu.de>,
John     E. Davis     <davis@space.mit.edu>,     Karl-Johan     Johnsson
<su95-kjo@nada.kth.se> for  showing inspiring examples of  the spirit of
good net keeping in the form of well-designed usenet reading programs.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBNA/CyihIY6bIQPMpAQGhhQQAzBUAJ0BGU/1hPDP5BQYBVADK8aQHVeS8
gbV9VeDtOm1sYrhJNuPsU9ydewsQmKRoIXH5H44qRYCv+ShXhdHp056Fvh/EsLUB
bEuhSy9BoBYo+8tR1WfuiktPAP9hG6D5kO/2B1hqoxuMTLP41Y+6i3mUNhy/aVrr
7q2PTVieeyU=
=OiHh
-----END PGP SIGNATURE-----
