home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 15 Message / 15-Message.zip / UU991113.zip / Ur991112.txt < prev    next >
Text File  |  1999-11-15  |  57KB  |  1,349 lines
  1.  
  2.                    comp.os.os2.mail-news            (Usenet)
  3.  
  4.                  Saturday, 06-Nov-1999 to Friday, 12-Nov-1999
  5.  
  6. +----------------------------------------------------------------------------+
  7.  
  8. From: none@none.net                                     06-Nov-99 08:44:26
  9.   To: All                                               06-Nov-99 05:25:28
  10. Subj: EARN $1000 TO $5000 WEEKLY!!!  620
  11.  
  12. From: none@none.net
  13.  
  14. FINALLY!!!
  15.  
  16. A SIMPLE ONLINE SYSTEM FOR MAKING FAST, EASY, MONEY THAT LASTS !!!
  17.  
  18. A TOTAL NO-BRAINER THAT ANYONE IN THE WORLD CAN DO !!!
  19.  
  20. Go to: http://opportunity.valuenetusa.com/JL2836/
  21.  
  22. AND GET STARTED TODAY !!!
  23.  
  24.  
  25.  
  26.   
  27.  
  28.  
  29.  
  30. gmjcfpcqljkfqlptqsfbcxhpbhrefjxfbksshpmjtd
  31.  
  32. --- WtrGate+ v0.93.p7 sn 165
  33.  * Origin: Usenet: AT&T WorldNet Services (1:109/42)
  34.  
  35. +----------------------------------------------------------------------------+
  36.  
  37. From: dwparsons@t-online.de                             06-Nov-99 09:13:07
  38.   To: All                                               06-Nov-99 05:25:28
  39. Subj: Re: Whats the free best News server for OS/2?
  40.  
  41. From: dwparsons@t-online.de (Dave Parsons)
  42.  
  43. On Thu, 4 Nov 1999 00:23:09, nospam@savebandwidth.invalid       (John
  44. Thompson) wrote:
  45.  
  46. > In <381FCF08.9B1B3CFF@connect.net.au>, Greg Thomas <greg_t@connect.net.au>
  47. writes:
  48. > 
  49. > >I've got a bit of a LAN at home and wanting to setup a News Server. I
  50. > >have had a bit of a look at Changi (though not deeply yet), but was
  51. > >wondering if those in the know could tell me if I should be looking at
  52. > >something else instead.
  53. > 
  54. > I've been using changi here for several years.  Never 
  55. > even bothered looking further; I'm not even sure there are other 
  56. > free OS/2 news server packages.
  57. > 
  58. > -John (John.Thompson@attglobal.net)
  59. > 
  60.  
  61. There is another one called KNM which is available on LEO which I have
  62. just found and started to assess.
  63. It is an NNTP, SMTP and POP3 server/relay which is written in JAVA.
  64. So far it seems to work OK but the GUI is a bit slow on my Pentium 133.
  65. I havn't tried it on my faster machine yet.
  66.  
  67. -- 
  68. Dave
  69.  
  70. --- WtrGate+ v0.93.p7 sn 165
  71.  * Origin: Usenet: CDL (1:109/42)
  72.  
  73. +----------------------------------------------------------------------------+
  74.  
  75. From: bvermo@powertech.no                               06-Nov-99 22:24:03
  76.   To: All                                               06-Nov-99 20:02:24
  77. Subj: Re: Need help with Ultimail on OS/2 WSeB
  78.  
  79. From: =?iso-8859-1?Q?Bj=F8rn?= Vermo <bvermo@powertech.no>
  80.  
  81. hamei@pacbell.net wrote:
  82.  
  83. >
  84. > since it is only possible to even HAVE two codepages on a system
  85. > your complaint isn't the half of it
  86.  
  87. The limit of two codepages applies to what the user can switch between in VIO
  88. sessions.
  89. There is no limit to the number of codepages a PM application program may
  90. read,
  91. write, convert between or display. IBM have always supplied the tools, and
  92. programmers have neglected to use them. There is even a place for the codepage 
  93. in
  94. the standard EAs of a file, but it is poorly documented and never used.
  95.  
  96.  
  97. --- WtrGate+ v0.93.p7 sn 165
  98.  * Origin: Usenet: Norbionics (1:109/42)
  99.  
  100. +----------------------------------------------------------------------------+
  101.  
  102. From: bobmcl@ibm.net                                    04-Nov-99 08:48:28
  103.   To: All                                               06-Nov-99 20:02:24
  104. Subj: Re: Need help with Ultimail on OS/2 WSeB
  105.  
  106. From: Bob McLellan <bobmcl@ibm.net>
  107.  
  108.  
  109. Robert Basler wrote:
  110.  
  111. > I'm trying to get Ultimail 2.10.004 to work on OS/2 WSeB, I couldn't
  112. > find any way to install just ultimail from the Warp 4 CD's, so I copied
  113. > my UMAIL directory and mailstor over wholesale from my working Warp 4
  114. > system, then put the SENDMAIL.UML file into the MPTN directory.  Note
  115. > that all paths are the same on both systems.
  116. >
  117. > It will send and recieve mail as long as you are connected to the
  118. > internet.
  119. >
  120. > If you are not connected and send a message, it says that it was queued
  121. > successfully, but there is no message in the MQUEUE directory and the
  122. > message text can be found in a file called DEADLET.TER in the MPTN\ETC
  123. > directory.
  124. >
  125. > I have the ETC dir set to MPTN\ETC
  126. >
  127. > When I connect to the internet, it does not do the sendmail thing in the
  128. > status window, but I suspect that this has more to do with there being
  129. > no files in the MQUEUE directory, rather than some problem with that
  130. > program feature.
  131. >
  132. > Suggestions???  I really want to stick to Ultimail since I have
  133. > thousands of archived messages that I access regularly and have been
  134. > very happy with the app in general to date.
  135. >
  136. > This is what I got when I ran UMCHECK.CMD
  137. >
  138. > The key "AURORASW /MAIL_GW" in D:\MPTN\ETC\TCPOS2.INI was not found!
  139. > No "Mlocal" line was found in D:\MPTN\ETC\SENDMAIL.CF!
  140. >
  141. > Installation information:
  142. >   The UltiMail provider is ADVANTIS
  143. >   TMP = D:\TCPIP\TMP
  144. >   ETC = D:\MPTN\ETC
  145. >   SRV = D:\TCPIP\UMAIL\SERVER
  146. >   CONNECTION = AURORASW
  147. >   POPSRVR = mail.direct.ca
  148. >   REPLY_DOMAIN = direct.ca
  149. >   MQueue from SENDMAIL.CF:  D:\MPTN\ETC\MQUEUE
  150. >   DD from SENDMAIL.CF:      Your.Domain
  151. >   MQueue from SENDMAIL.UML: D:\MPTN\ETC\MQUEUE
  152. >   Mlocal from SENDMAIL.UML: Mlocal  P=d:\tcpip\umail\umailer.exe
  153. > F=lsmDFP
  154. > S=10  R=0  A=-dest d:\tcpip\umail\server\inbox -to $u
  155. >
  156. > FYI my email address above is bogus, send email to: aurorasw direct ca
  157. > after inserting appropriate ats and dots, thanks.
  158.  
  159.  Look up the INSTALL command in the TCPIP command reference. It tells you
  160. how to set up a response file to select components of TCPIP for
  161. installation. One of the components is Ultimail. Just run INSTALL with a
  162. reponse file that selects only Ultimail. However, unless there is a specific
  163. need for Ultimail, I wouldn't use it.
  164.  
  165. --
  166. ------------------------------------------------------
  167. Bob McLellan
  168. The Little Blue Kiwi
  169. OS/2 Solutions for New Zeland
  170.  
  171.  
  172. --- WtrGate+ v0.93.p7 sn 165
  173.  * Origin: Usenet: Global Network Services - Remote Access Mail & Ne
  174. (1:109/42)
  175.  
  176. +----------------------------------------------------------------------------+
  177.  
  178. From: js@cwi.nl                                         07-Nov-99 00:00:01
  179.   To: All                                               06-Nov-99 21:41:10
  180. Subj: (1/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft
  181.  
  182. From: Jeroen Scheerder <js@cwi.nl>
  183.  
  184. Archive-name: usenet/software/good-netkeeping-seal
  185. Posting-Frequency: monthly (first Sunday)
  186. Last-modified: Oct 4 1999
  187. Version: 2.08
  188. URL: <http://www.xs4all.nl/%7Ejs/gnksa/>
  189. Maintainer: Jeroen Scheerder <js@cwi.nl>
  190.  
  191. -----BEGIN PGP SIGNED MESSAGE-----
  192.  
  193.             GNKSA * The Good Net-Keeping Seal of Approval
  194.             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  195.  
  196. There's a general perception that Usenet is becoming "noisier" the more
  197. people join it.  There are more blank articles, more mangled headers,
  198. more "me too" responses accompanying many lines of quoted text, more
  199. followup postings to inappropriate newsgroups, more misattributed
  200. quotes, more followups that really should have been e-mail replies, more
  201. excessive cross- and multi-postings, more unreadibly encoded or
  202. otherwise maimed articles.
  203.  
  204. This is often blamed on the new users themselves -- they are called
  205. "clueless newbies", unqualified to participate in Usenet because they
  206. don't know Unix, or use a misdesigned graphical user interface (GUI), or
  207. use an off-line news reader, or use a commercial service such as America
  208. Online or Delphi.
  209.  
  210. I believe most of this anger is misdirected.  The new users aren't
  211. really that different from the old-timers.  What _is_ different is that
  212. many of the old-timers are using relatively well-behaved software,
  213. typically `rn' or one of its offspring, while many of the newbies are
  214. using `tin', `uqwk', `AOL', or various PC newsreaders.  Unfortunately,
  215. these programs frequently violate assumptions that come naturally to
  216. people used to well-behaved readers:
  217.  
  218.   - The user can see the essential header fields, including "Newsgroups"
  219.     and "Followup-To".
  220.   - The user can edit all header fields when composing a followup.
  221.   - There's a clear difference between `followup' and `reply'.
  222.   - Followups preserve the Subject and References of the original
  223.     article, unless the user explicitly changes them.
  224.   - News software respects "Followup-To" and "Reply-To"
  225.     specifications.
  226.   - What the user writes is what gets posted, as is.
  227.  
  228. Newer software should be an improvement over an ancient program like
  229. `rn'.  Instead, much of it is crippled or broken in comparison.
  230.  
  231. The Usenet community can deal with this problem by establishing a "Good
  232. Net-keeping Seal of Approval" for Usenet reading and posting software.
  233. This "Seal" would certify that the software complies with certain
  234. minimal standards, such as those listed below.
  235.  
  236. A group of volunteers will test all putative Usenet software to
  237. determine whether it qualifies for the "Seal", with the intention to
  238. periodically post a list of all tested software to
  239. news.software.readers, alt.usenet.offline-reader, and other appropriate
  240. newsgroups.  This periodic posting will list both compliant and
  241. non-compliant news programs; for non-compliant programs, it will include
  242. a list of all violations of the standards.  The hope is that this will
  243. encourage the authors of non-compliant software to bring their programs
  244. up to "Good Net-Keeping Seal" standards, eventually.
  245.  
  246.  
  247.                               --%-@#@-%--
  248.  
  249.  
  250. These are the proposed standards a Usenet news program should meet to
  251. deserve the "Good Net-Keeping Seal":
  252.  
  253.   1)  Display all essential header information
  254.   2)  Provide clear, separate commands for new posting, followup, and
  255.       e-mail reply
  256.   3)  Provide cross-posting functionality
  257.   4)  Allow users to change essential headers
  258.   5)  Ensure followups and e-mail replies contain a correct Subject
  259.   6)  Direct followups to the correct newsgroups
  260.   7)  Make sure followups contain valid References
  261.   8)  Direct e-mail replies to the correct address
  262.   9)  Allow the user to change her mind about whether to post or mail
  263.   10) Provide adequate quotation and attribution facilities
  264.   11) Provide a user-specified "Subject: " header
  265.   12) Provide a valid "From: " header
  266.   13) Allow users to both cancel and supersede their own articles (and
  267.       _no_ others!)
  268.   14) Try to respect the 80-character line-length conventions
  269.   15) Separate signatures correctly, and don't use excessive ones
  270.   16) Try to prevent obvious user errors
  271.   17) Post human-readable articles unless ordered otherwise
  272.   18) Provide self-protection
  273.   19) Be kind to servers, leave room for others
  274.  
  275. These requirements are described in more detail below.  In the spirit of
  276. RFC 1123 and Henry Spencer's "son of RFC 1036" proposal, I've
  277. capitalized the words "MUST", "MUST NOT", and "DO NOT" to indicate
  278. absolute requirements, while using the word "SHOULD" for things that are
  279. merely a Very Good Idea, Really.
  280.  
  281.  
  282.                               --%-@#@-%--
  283.  
  284.  
  285. 1)  Display all essential header information
  286.  
  287. When displaying a news article, it MUST by default show the user certain
  288. information that is found in the article's header.  The information need
  289. not be displayed as actual RFC-1036 header lines, but it MUST be shown
  290. to the user in some form.
  291.  
  292.   a) The author of the article (its "From: " header line)
  293.  
  294.   b) The article's Subject.  At least the first 70 characters
  295.      following the "Subject: " string MUST be displayed.
  296.  
  297.   c) The list of newsgroups the article was posted to.  This list MUST
  298.      be displayed in full, never truncated.  This list need not be
  299.      displayed if it has only one element, provided that the software
  300.      displays the name of the newsgroup that the user is currently
  301.      reading.
  302.  
  303.   d) The article's Followup-To list, if this is different from the
  304.      Newsgroups list.  This MUST be displayed in full, never
  305.      truncated.
  306.  
  307.   e) The article's Reply-To, if this is different from the From
  308.      specification.
  309.  
  310. If the required information does not fit fully on the display, the
  311. software MAY display only the initial part of the information, provided
  312. that it offers the user a scrollbar or equivalent means of viewing the
  313. remainder.
  314.  
  315. The software MAY allow the user to re-configure it so as to turn off
  316. these displays, but if the user has not done this, all of the required
  317. information MUST be displayed.
  318.  
  319. Rationale: Without having to make any special effort the user should see
  320. who sent the article she is reading, how to reply to it via e-mail, what
  321. discussion groups it was posted to, and whether the author of the
  322. message wants to narrow or redirect the location of future discussion.
  323.  
  324.  
  325. 2)  Provide clear, separate commands for new posting, followup, and
  326.     e-mail reply
  327.  
  328. The software MUST provide separate, clearly distinguished commands to do
  329. each of the following:
  330.  
  331.   a) Post a new article, unrelated to any existing one, whose Subject
  332.      is to be supplied by the user, and which has an empty or missing
  333.      References: header line.
  334.  
  335.   b) Post a followup article, with Subject, Newsgroups, and References
  336.      header lines derived appropriately from the original article.
  337.                                              (see #5, #6, and #7 below)
  338.  
  339.   c) Reply by e-mail, with "Subject: " and "To: " headers derived
  340.      appropriately from the original article.     (see #5 and #8 below)
  341.  
  342. Software that uses the English language is strongly encouraged to
  343. include the phrases "Post to newsgroup", "Followup to newsgroup", and
  344. "Reply by e-mail" (or "Reply to sender" or "Reply to author") -- in
  345. menus, on-line help, and written documentation.  It SHOULD avoid using
  346. other verbs such as "Send" or "Respond" whose meaning is not evident to
  347. the user.  An ordinary, untrained user SHOULD be able to easily pick the
  348. correct command.
  349.  
  350. Rationale: Users who post followups when they should send e-mail
  351. replies, or vice versa, seem to be an endemic problem.  They are almost
  352. always using software that doesn't make the difference clear, or doesn't
  353. even provide both commands.
  354.  
  355.  
  356. 3)  Provide cross-posting functionality
  357.  
  358. When creating either a new article or a followup, the user MUST be
  359. allowed to specify multiple newsgroups, and the software MUST cross-post
  360. (not multi-post) to them if more than one is specified.
  361.  
  362. Posting software SHOULD prevent the user from excessive cross-posting,
  363. or at least warn against it.  If posting to a very large number of
  364. groups, the user SHOULD either be forced or strongly suggested to set a
  365. "Followup-To" header.  Such a header must be subjected to restrictions
  366. that are at least as strict as those imposed on "Newsgroups: ".
  367.  
  368. Rationale: Cross-posting is an essential feature of Usenet.  If the
  369. software cannot cross-post, then its users will multi-post instead.  A
  370. reasonable attempt should be made, however, to protect the user against
  371. (usually inadvertent; if not, often considered net-abuse) excessive
  372. cross-postings that will only lead to canceling and flame warfare.
  373.  
  374.  
  375. 4) Allow users to change essential headers
  376.  
  377. When creating either a new article or a followup, the software MUST
  378. allow the user to edit the Subject, Newsgroups, Followup-To, and
  379. Reply-To specifications.  The user MUST be able to edit these at any
  380. time during composition of the article; she MUST NOT be limited to
  381. specifying them only before, or after, editing the article's text.
  382.  
  383. The software MUST allow the user to specify a new Subject field of at
  384. least 70 characters, not including the string "Subject: " itself.  It is
  385. better not to impose any limit at all, other than the overall
  386. son-of-1036 limit of 998 characters (see #7) per header line.
  387.  
  388. The software MUST allow the user to specify "Followup-To: poster", which
  389. tells readers of the article that the user prefers e-mail replies rather
  390. than followups to the newsgroup.
  391.  
  392. This does not mean that the software must present raw RFC-1036 headers
  393. to the user, or that the headers and body must be an indivisible unit of
  394. editable text.  A graphical user interface that presents each of these
  395. as an editable field in a form will meet the requirement.
  396.  
  397. Rationale: Topics drift as a discussion progresses, and users need the
  398. ability to change the Subject header to reflect the drift. Similarly, a
  399. user may determine that the discussion no longer belongs in some of the
  400. places that it started, or that its continuation needs to go elsewhere. 
  401. The software must not impede the user's ability to make these
  402. judgments, possibly during the composition of her followup article.  
  403. It's not acceptable to have users who respond to "Please direct
  404. followups appropriately" with "I can't; the software won't let me."
  405.  
  406.  
  407. 5) Ensure followups and e-mail replies contain a correct Subject
  408.  
  409. When creating either a followup article or an e-mail reply, the software
  410. MUST create an initial "Subject: " header which
  411.  
  412.   a) Prepends the four characters "Re: " to the Subject if and only if
  413.      "Re: " is not already present.  Note that this contains an
  414.      upper-case "R", a lower-case "e", and a trailing space.  DO NOT
  415.      prepend non-standard prefixes such as "Re^2: " .
  416.  
  417.   b) Preserves the *entire* Subject of the original article. DO NOT
  418.      chop it off at 20 or 25 or even 80 characters.  DO NOT append
  419.      spaces or any other characters to the end.  DO NOT change the
  420.      case of any character in the original Subject; in particular, DO
  421.      NOT change the Subject to all-upper-case or all-lower-case.
  422.  
  423.   (The user may later change the Subject, of course; see #4 above.)
  424.  
  425. Exception: The software MAY try to compensate for other people's broken
  426. software by replacing non-standard prefixes (such as "Re^2: ", "Re(2):
  427. ", "Re:" (no space), "RE: ", "re: " , or "Re: Re: ")  by the standard
  428. prefix "Re: ".
  429.  
  430. Rationale: These things should be obvious, but many authors of news
  431. software don't seem to understand the relevant sections of RFC 1036. 
  432. Truncated "Subject: " headers, especially when gratuitous non-ASCII
  433. characters are also thrown in, are a major annoyance for users and can
  434. make threading difficult or impossible.
  435.  
  436.  
  437. 6) Direct followups to the correct newsgroups
  438.  
  439. When creating a followup article, the software MUST create an initial
  440. header in which the Newsgroups field is initialized to the original
  441. article's Followup-To, if one was provided, or Newsgroups, if it wasn't.
  442. (The user may later change this field, of course; see #4 above.)
  443.  
  444. If the original article's "Followup-To: " header is set to "poster", the
  445. software MUST warn the user that the original poster requested an e-mail
  446. reply, and generate an e-mail reply by default.
  447.  
  448. Rationale: This is basic RFC 1036 compliance.  Software that fails to
  449. meet this requirement makes its users look at best foolish or
  450. incompetent, and at worst willfully unresponsive to the wishes of other
  451. Usenet users.
  452.  
  453.  
  454. 7) Make sure followups contain valid References
  455.  
  456. When creating a followup, the software MUST create a "References: "
  457. header line that contains, as its last element, the Message-ID of the
  458. original article.  An individual Message-ID MUST never be truncated.
  459.  
  460. The software MUST include at least three additional Message-IDs from
  461. the original article's References header as well, if they are available.
  462. Try to stay as close as possible to the spirit of "son-of-1036", which
  463. states:
  464.  
  465.         <<Followup agents SHOULD not shorten References  headers.   If
  466.           it  is absolutely necessary to shorten the header, as a des-
  467.           perate last resort, a followup agent MAY do this by deleting
  468.           some  of  the  message IDs.  However, it MUST not delete the
  469.           first message ID, the last three message IDs (including that
  470.           of  the immediate precursor), or any message ID mentioned in
  471.           the body of the followup.>>
  472.  
  473. However, it also says:
  474.  
  475.         <<If  it  is  absolutely  necessary  for  an implementation to
  476.           impose a limit on the length of header lines, body lines, or
  477.           header  logical  lines,  that  limit  shall be at least 1000
  478.           octets, including EOL representations.>>
  479.  
  480. So, bear in mind that news transports are not guaranteed to be able to
  481. handle arbitrary long lines.  Furthermore, keep in mind that some news
  482. transports choke on continued (multi-line) "References: " headers.
  483.  
  484. Therefore, keep as many Message-IDs as will fit on a line starting with
  485. "References: " with a maximum length of 998 characters.  (An octet is a
  486. byte of 8 bits, EOL representation takes two bytes.)
  487.  
  488. Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
  489. Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by
  490. a misguided user, maybe) but don't belong to the thread.
  491.  
  492. Rationale: Threaded news-readers depend on References to do their magic.
  493. This too is basic RFC compliance.  Be as complete as the line length
  494. limit allows, but do not propagate errors.
  495.  
  496.  
  497. --- WtrGate+ v0.93.p7 sn 165
  498.  * Origin: Usenet: NAKA (1:109/42)
  499.  
  500. +----------------------------------------------------------------------------+
  501.  
  502. From: js@cwi.nl                                         07-Nov-99 00:00:01
  503.   To: All                                               06-Nov-99 21:41:10
  504. Subj: (2/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft
  505.  
  506. 8) Direct e-mail replies to the correct address
  507.  
  508. When creating an e-mail reply, the software MUST create an initial
  509. header in which the "To: " header is initialized to the original
  510. article's Reply-to, if one was provided, or From if it wasn't.  (The
  511. user may later change this field, of course; see #4 above.)
  512.  
  513. Rationale: See #6 above.
  514.  
  515.  
  516. 9) Allow the user to change her mind about whether to post or mail
  517.  
  518. With any followup or reply message, the software SHOULD offer the user
  519. the option to change her mind about whether to post or to mail, and may
  520. allow doing both.
  521.  
  522. If the software has the option to post as well as mail a single
  523. response, that option MUST NOT be default behavior, neither by factory
  524. default nor by user-configuration.  Furthermore, when both posting and
  525. mailing a message, the mailed message's body SHOULD be preceded by a
  526. line clearly stating that the message is an email copy of a usenet
  527. posting.
  528.  
  529. Rationale: People digress when writing, and may find themselves posting
  530. a message that would have been more appropriate for private
  531. communication, or mailing a message that would have been more
  532. appropriately directed to the general audience.  Unsolicited mail
  533. messages are highly unwanted by many users (had they wanted e-mail
  534. replies, they could, should and, for all a reader can assume would, have
  535. requested them).
  536.  
  537.  
  538. 10) Provide adequate quotation and attribution facilities
  539.  
  540. When the user requests a followup or an e-mail reply, the software MUST
  541. provide some method for including quoted text from the original article.
  542. This quoted text MUST be clearly set off in some way -- either by
  543. indenting it, or by prepending each line with one or more identifiable
  544. characters.  The quote prefix SHOULD be `>', with optionally a trailing
  545. space (i.e. `> ').
  546.  
  547. Caveat: with `>', the level of quotation is clearly reflected in the
  548.         number of `>' characters at the start of the line.   However,
  549.         whitespace between quote prefix and quoted material improves
  550.         readability, so it is good practice for newsreaders to use `> '
  551.         as the quote prefix for newly quoted, and `>' for repetitively
  552.         quoted text.
  553.  
  554. Included text SHOULD NOT contain the original article's signature,
  555. unless by explicit request of the user (under the condition that the
  556. signature can be determined of course, which is to say: if clearly
  557. separated by the standard signature delimiter). (see also #15 below).
  558.  
  559. As a direct counterpart to this requirement, the software SHOULD offer
  560. the user some means of selecting exactly which part of a Usenet posting
  561. she wishes to followup to, and quote only that part initially.  (A
  562. special case of this is when a user wishes to react to what's in a
  563. signature.)
  564.  
  565. If it concerns a followup (as opposed to an e-mail reply), the quoted
  566. text MUST be preceded by an "attribution line" identifying the author of
  567. the text that is being quoted.  (The user may decide to delete this
  568. attribution line or to configure it away, but it MUST be there by
  569. default.)
  570.  
  571. Rationale: The ability to easily quote text is essential for users who
  572. want to provide a proper context for their followups and e-mail replies.
  573. Software that provides attribution lines without quoting ability, or
  574. that fails to distinctively set off quoted text from original text, is a
  575. major cause of "I didn't say that!" misunderstandings.  By convention,
  576. quoted lines start with `>', and much software depends on this do
  577. distinguish quoted material from original lines, for presentation
  578. purposes.  Users can be careless or forgetful occasionally (or often,
  579. even) and neglect to edit out spurious quoted material; the signature,
  580. typically, is such material.  In general, facilitating good quoting
  581. behaviour -- by quoting only a part indicated by the user, for example
  582. - - -- is an area in which software can help users substantially to create
  583. better articles.
  584.  
  585.  
  586. 11) Provide a user-specified "Subject: " header
  587.  
  588. When creating a new article, the software MUST require the user to
  589. provide a non-empty Subject.  It MUST NOT post an article without a
  590. "Subject: " header or with an empty "Subject: " header.  It MUST NOT
  591. silently add a default Subject (like "Subject: <None>") if the user
  592. didn't specify one.  It MUST allow the user to change the Subject at any
  593. time while editing the main text of the article (see #4 above).
  594.  
  595. Rationale: An article without a Subject provides no clues for deciding
  596. to read it or not.  For that reason, it's likely to be widely ignored,
  597. and it's no service to the user to allow posting of such an article;
  598. while other readers may read it, only to find out they needn't have
  599. bothered when it annoyingly turns out to be of no interest.
  600.  
  601.  
  602. 12) Provide a valid "From: " header
  603.  
  604. When creating either a new article or a followup, the software MUST
  605. initialize the "From: " header to a syntactically valid e-mail address,
  606. which includes a fully-qualified domain name (FQDN).
  607.  
  608. This requirement must be met regardless of whether the software
  609.  
  610.   (a) creates the "From: " header when it first creates the article to
  611.       be edited by the user, or
  612.  
  613.   (b) adds the "From: " header automatically after the user finishes
  614.       editing the article and requests that it be submitted.
  615.  
  616. If the software allows the user to edit the "From: " header, it SHOULD
  617. check that the user supplied a syntactically valid address.
  618.  
  619. If the software is unable to create such an address -- maybe because it
  620. was built with incorrect configuration parameters, or some essential
  621. parameter is unavailable at runtime -- then it MUST NOT allow posting at
  622. all, unless it can obtain a syntactically valid e-mail address from the
  623. user.
  624.  
  625. If feasible, the software SHOULD try to guarantee that this address
  626. actually belongs to the person using the software, and actually accepts
  627. e-mail.
  628.  
  629. Rationale: Mail and news transport systems and user agents, gateways and
  630. processing software may choke on syntactically invalid headers.  Invalid
  631. e-mail addresses make e-mail replies impossible; see Greg Byshank's
  632. "Help! I've been spammed!" document for an excellent discussion of the
  633. issues involved.
  634.  
  635.  
  636. 13) Allow users to both cancel and supersede their own articles (and
  637.     _no_ others!)
  638.  
  639. Any software that posts news SHOULD provide a command that the user can
  640. invoke to cancel her own articles.  It SHOULD also provide the option to
  641. supersede the user's own articles.  The software MUST guarantee that
  642. the user cannot cancel or supersede other people's articles, as far as
  643. possible.
  644.  
  645. Caveat: since completely reliable authentication can be infeasible, the
  646.         best the software can do is to make a good-faith effort to
  647.         determine whether or not cancelling or superseding is valid:
  648.         i.e. by trusting upon its user configuration and checking it
  649.         against the relevant header(s) in the target article.
  650.  
  651. If the software uses the English language, the text of the cancel
  652. command SHOULD include the word "cancel", rather than non-standard verbs
  653. such as "delete".  Similarly, in English software, the text of the
  654. supersede command SHOULD include the word "supersede".
  655.  
  656. Rationale: People make mistakes and need the ability to revoke or
  657. correct them; both `cancel' and `supersede' exist for good reasons. 
  658. However, software should not encourage users to abuse the net, either
  659. intentionally or accidentally, by sending unauthorized (`rogue') cancels
  660. or supersedes.  The supersede option is essential: due (a.o.) to
  661. sometimes unpredictable usenet propagation, a "cancel-cum-repost" may
  662. behave very different from a "supersede".  News servers might also have
  663. different acceptance policies for both.
  664.  
  665.  
  666. 14) Try to respect the 80-character line-length conventions
  667.  
  668. Any line breaks shown to the user while she is editing her article
  669. SHOULD still be present when the article is actually posted to the Net.
  670. The software SHOULD NOT show the user four 75-character lines while
  671. actually posting a single 300-character line.  Nor should it show the
  672. user a series of 100-character lines while actually posting alternating
  673. lines of 80 and 20 characters each.
  674.  
  675. It's also a good idea to warn the user if the article she is about to
  676. post contains non-header lines longer than 80 characters.  The software
  677. SHOULD NOT prevent the posting, but SHOULD ask whether the user wants to
  678. re-edit or post anyway.
  679.  
  680. Caveat: Occasionally, there are very good reasons for posting long lines
  681.         (for example, when posting a source code snippet containing
  682.         something that will break when wrapped, or when there's a need
  683.         to post something "as is", unreformatted -- unaltered and
  684.         completely intact).  For that reason (re)wrapping cannot be a
  685.         MUST: a SHOULD is all it can be.
  686.  
  687. To get well-readable articles, the user SHOULD be provided with the
  688. possibility to rewrap excessively long lines of quoted text, respecting
  689. quotation -- i.e. have the option to correct `inherited' bad formatting.
  690. Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that
  691. may occur when someone reading your article uses a different tab size.
  692.  
  693. Caveat: Due to the immense variety in quoting styles, quoted text
  694.         reformatting can be extremely hard, practically impossible even.
  695.         No software can be expected to deal with everything; still,
  696.         since the overwhelming majority can be dealt relatively easily,
  697.         it is not unreasonable to expect it from software, if it is to
  698.         be well-equipped for the task of editing Usenet articles.
  699.  
  700. If the news software uses an external editor, the default editor SHOULD
  701. conform to the above.
  702.  
  703. Rationale: Articles with long lines are unreadable to many users.
  704.            Articles with alternating 80/20 lines aren't any better.
  705.  
  706.  
  707. 15) Separate signatures correctly, and don't use excessive ones
  708.  
  709. Posting software SHOULD separate any signature appended to outgoing
  710. articles from the main text with a line containing only `-- ' ("dash
  711. dash space"). To quote son-of-rfc1036:
  712.  
  713.         <<If  a  poster or posting agent does append a signature to an
  714.           article, the signature SHOULD be preceded with  a  delimiter
  715.           line  containing  (only)  two hyphens (ASCII 45) followed by
  716.           one blank (ASCII  32).   Posting  agents  SHOULD  limit  the
  717.           length  of  signatures,  since  verbose  excess bordering on
  718.           abuse is common if no restraint is imposed;  4  lines  is  a
  719.           common limit.>>
  720.  
  721. Hence, posting software MUST prevent the user from using excessively
  722. long signatures, or at least warn the user against it.  A widely
  723. accepted standard is the so-called McQuary limit: up to 4 lines, each up
  724. to a maximum of 80 characters.
  725.  
  726. Rationale: Being confronted with (possibly excessively long) signatures
  727. repetitively is, or can be, annoying to many.  Being able to separate
  728. the main text and the signature clearly is important, not only to
  729. prevent the possible mistake of misinterpreting a signature, but also to
  730. enable automatic signature suppression for those who wish to do so.
  731.  
  732.  
  733. 16) Try to prevent obvious user errors
  734.  
  735. * Posting software MUST warn the user for posting empty articles, and
  736.   SHOULD prevent doing so entirely.
  737.  
  738. * Posting software MUST warn the user about posting articles consisting
  739.   entirely of quoted text, and SHOULD prevent doing so entirely.
  740.  
  741. * Posting software MUST warn the user severely when attempting to post
  742.   an article over and over again, and SHOULD do everything it can to
  743.   prevent doing so entirely.
  744.  
  745.   - When posting `asynchronously' (i.e.  when sacrificing knowledge
  746.     about progress, success or failure by handing over the task
  747.     completely to some separate process) it SHOULD NOT allow the user
  748.     to post articles again, once the user issued the final "post"
  749.     command.
  750.  
  751.   - When posting `synchronously', the software has at least partial
  752.     knowledge about progress, and full knowledge about success or
  753.     failure of an attempt to post.  In this case, it SHOULD inform the
  754.     user clearly that the article is being posted while attempting to
  755.     post it; after the attempt, it MUST unequivocally inform the user
  756.     that posting succeeded if it did, and that it failed otherwise.
  757.  
  758. Note: So-called `online' newsreaders usually (but not necessarily)
  759.       post synchronously, while a number so-called `offline' newsreading
  760.       methods (especially the scheduled, batch-oriented ones) usually
  761.       employ asynchronous posting.  However, offline newsreaders using
  762.       NNTP for news transport usually post synchronously, i.e.  are in
  763.       direct interaction with the newsserver, hence get immediate
  764.       results, when posting.
  765.  
  766. Rationale: Users who do any of these things almost never do them on
  767. purpose.  They are usually confused by unfamiliar new software, and
  768. should be offered basic protection.
  769.  
  770.  
  771. 17) Post human-readable articles unless ordered otherwise
  772.  
  773. Posting software MUST by default post only legible usenet articles.  In
  774. a different formulation: it MUST NOT encode or encrypt articles, unless
  775. by explicit user demand.  Hence, it MUST NOT even have the option to
  776. encode or encrypt by default.  Whenever some encoding/encryption will be
  777. used, clear feedback showing that it's in effect MUST be provided to the
  778. user, so she is permanently reminded of the fact that her article will
  779. not be posted as composed.  The worst DO NOT is the combination of
  780. allowing default encoding without even taking the trouble of telling
  781. (warning) the user about it.
  782.  
  783. Note: Common occurrences of this kind of content maiming unasked for,
  784.       and untold to, the user, are HTML- and MIME multi-part
  785.       and/or base64 encodings, as found in newsreaders integrated in
  786.       WWW-browsers better not mentioned.
  787.  
  788. Rationale: Many users may not be able to read (particular) encoded or
  789. encrypted articles at all, or only at the expense of a considerable
  790. effort: such articles ask to be widely ignored. Encouraging posting
  791. maimed messages is a service neither to the user herself, nor to her
  792. audience.  Keep in mind that not everyone shares your particular setup
  793. (newsreader, configuration, operating system), nor should (and can)
  794. anyone be forced to do so, in order to be able to read your articles.
  795.  
  796.  
  797. 18) Provide self-protection
  798.  
  799. News readers SHOULD allow the user to protect herself by filtering out
  800. articles she really does not want to read.  These filtering facilities
  801. SHOULD be sufficiently powerful to enable ignoring postings by
  802. particular persons, about particular subjects, and particular
  803. cross-posts.
  804.  
  805. --- WtrGate+ v0.93.p7 sn 165
  806.  * Origin: Usenet: NAKA (1:109/42)
  807.  
  808. +----------------------------------------------------------------------------+
  809.  
  810. From: js@cwi.nl                                         07-Nov-99 00:00:01
  811.   To: All                                               06-Nov-99 21:41:10
  812. Subj: (3/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft
  813.  
  814. Rationale: While it looks as if not having filtering only affects the
  815. user herself, people tend to take it out on the net if they are
  816. repetitively (structurally) annoyed by a particular class of postings,
  817. and will be inclined to start canceling, advocate posting restriction or
  818. engage in flame warfare, all of which is harmful to other users.
  819.  
  820.  
  821. 19) Be kind to servers, leave room for others
  822.  
  823. Reading or posting software MUST NOT put excessive demands on news
  824. servers unnecessarily.  The sofware MUST limit itself to 4 simultaneous
  825. connections to a given server.  Spurious connects and unnecessary
  826. traffic MUST be avoided; the software MUST use as few as possible
  827. connections, reusing existing connections whenever possible.
  828.  
  829. Rationale: News systems are big, resources are scarce, and every
  830. resource claimed is provided at the expense of other users.
  831.  
  832.  
  833.                               --%-@#@-%--
  834.  
  835.  
  836. Please remember that this is a set of _minimum_ guidelines to guarantee
  837. that a given piece of software interacts properly with the rest of the
  838. Usenet world.  It is not a general "wish list" of everyone's favorite
  839. features.  I have deliberately avoided taking a position on certain
  840. controversial issues -- for example, whether the user should be allowed
  841. to edit the "Sender: " header, whether news software should prohibit
  842. posting an article that has more quoted text than new text, or whether
  843. posting with certain particular Subjects should be prohibited.
  844.  
  845.  
  846. My hope is that a voluntary committee can be formed, respected by many
  847. people on the Net, that reviews Usenet software and decides whether it
  848. deserves the "Good Net-Keeping Seal of Approval." People who use broken
  849. software that does not have the Seal should then be strongly encouraged
  850. to switch to software that does.
  851.  
  852.  
  853. References and additional reading
  854. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  855.  
  856. The current GNKSA, an evaluation form and an archive of software
  857. evaluations can be found at:
  858.  
  859.   <http://www.xs4all.nl/%7Ejs/gnksa/>
  860.   <http://newsreaders.com/gnksa/> (Mirror)
  861.   <http://newsreaders.com/misc/twpierce/news/> (GNKSA 1.2)
  862.  
  863. The GNKSA page also contains a pointer to a library that newsreader
  864. developers can freely make use of, providing basic `sanitary' functions.
  865.  
  866. In addition to the Seal, anyone writing Usenet software should pay
  867. careful attention to the following documents:
  868.  
  869.   RFC 977, "Network News Transfer Protocol -- A Proposed Standard for
  870.   the Stream-Based Transmission of News", by Brian Kantor and Phil
  871.   Lapsley.
  872.         <ftp://ftp.internic.net/rfc/rfc977.txt>
  873.  
  874.   RFC 1036, "Standard for Interchange of USENET Messages", by
  875.   M. Horton and R. Adams.
  876.         <ftp://ftp.internic.net/rfc/rfc1036.txt>
  877.  
  878.   The proposed "Son of 1036", "News Article Format and Transmission",
  879.   by Henry Spencer.
  880.         <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>    (also news.ps.Z)
  881.  
  882.   "The UseFor Working Group Documents" (under development: Internet
  883.   Drafts describing the minimal standards for a Usenet article, and
  884.   the minimum features all Usenet software should have), by Simon
  885.   Lyall (et al.).
  886.         <http://www.landfield.com/usefor/>
  887.  
  888.   "Read This Before You Write a Newsreader, News Transport
  889.   System, etc.", by Tom Limoncelli.
  890.         <http://www.xs4all.nl/%7Ejs/gnksa/read-before.txt>
  891.  
  892.   "The "Good Net-Keeping Seal of Approval", revision 1.2, by Ron
  893.   Newman; the previous version of this document, published in
  894.   January, 1995.
  895.         <http://www2.thecia.net/users/rnewman/Good-Netkeeping-Seal>
  896.  
  897. Excellent collections of things well worth reading in this context can
  898. be found at:
  899.  
  900.   "News Hacking", by Tim Pierce.
  901.         <http://newsreaders.com/misc/twpierce/news/>
  902.  
  903.   "Notes on News", by Lars Magne Ingebrigtsen.
  904.         <http://quimby.gnus.org/notes/notes.html>
  905.  
  906. A very informative overview of the issues concerning some forms of net
  907. abuse, and how and how not to deal with it, is:
  908.  
  909.   "Help! I've been Spammed! What do I do?", by Greg Byshenk, based in
  910.   part on an original by Chris Lewis, Posted weekly to news.answers,
  911.   news.newusers.questions, and news.admin.net-abuse.misc.
  912.         <http://www.byshenk.net/ive.been.spammed.html>
  913.   The part that explicitly deals with the issues of messing up
  914.   "From: "-headers is:
  915.         <http://www.byshenk.net/ive.been.spammed.html#2.3>
  916.  
  917. Of related interest -- if you're willing to contribute, or are just
  918. interested in the way things are developing -- could also be the IETF
  919. NNTP Working Group's "attempt to revise NNTP and bring it into the
  920. 1990s".
  921.         <http://www.academ.com/academ/nntp/ietf.html>
  922.  
  923.  
  924. Acknowledgements
  925. ~~~~~~~~~~~~~~~~
  926.  
  927. Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working
  928. Group initiative (and its derivatives).
  929.  
  930. Ron Newman <rnewman@theCIA.net>, of course, for writing the first
  931. version of the GNKSA, of which this document descends, and for
  932. fruitful discussions during revision.
  933.  
  934. Sven Guckes <guckes@math.fu-berlin.de> for providing mailing list
  935. resources (among other things).
  936.  
  937. Tim Pierce <twpierce@midway.uchicago.edu> for scrutinous examination,
  938. useful hints, and previous GNKSA support.
  939.  
  940. Larry Wall <lwall@netlabs.com>, Stefan Haller <stk@berlin.snafu.de>,
  941. John E. Davis <davis@space.mit.edu>, John Norstad <j-norstad@nwu.edu>,
  942. Karl-Johan Johnsson <su95-kjo@nada.kth.se>, Brian Clark <baclark@nwu.edu>,
  943. Simon Fraser <smfr@best.com> for showing inspiring examples of the spirit
  944. of good net keeping in the form of exceptionally well-designed usenet
  945. reading programs.
  946.  
  947. The kind folks of news.software.readers (you know who you are) that
  948. have helped discussing the issues that pertain to the GNSKA cause.
  949.  
  950. -----BEGIN PGP SIGNATURE-----
  951. Version: PGPfreeware 5.0i for non-commercial use
  952. Charset: noconv
  953.  
  954. iQCVAwUBN/iQ9ChIY6bIQPMpAQGljQP+MQwVaoE9FXCsE+ewpUAmWo58UrGlQwKk
  955. bpJ0ruTZ7CZs7rK1OHmJqr/H6FrBC5ll8y676LAEQQ1bTJR0viD+q/UEEpgTc0Wn
  956. b8aPn2F+DuhqelAvs2OkYHl0sv/LYXa7KvgsN+SLxWW2NhR7V0Iv99zQiTufFXKE
  957. BOG1YFh+bd0=
  958. =QL37
  959. -----END PGP SIGNATURE-----
  960.  
  961. --- WtrGate+ v0.93.p7 sn 165
  962.  * Origin: Usenet: NAKA (1:109/42)
  963.  
  964. +----------------------------------------------------------------------------+
  965.  
  966. From: sctvguy@netcenter.net                             06-Nov-99 22:44:19
  967.   To: All                                               07-Nov-99 03:28:17
  968. Subj: Ultimail Question
  969.  
  970. From: Bob Grimes <sctvguy@netcenter.net>
  971.  
  972. Just fooling around with Warp Connect's Ultimail program.  I can get it
  973. to receive mail from Earthlink, but I cannot send it.  It comes back
  974. with a message, " Message file not found".  I really don't use it (only
  975. used it on ibm.net), but I would like to know why it will not send the
  976. letters.
  977. Thanks,
  978. Bob Grimes
  979.  
  980. --- WtrGate+ v0.93.p7 sn 165
  981.  * Origin: Usenet: EarthLink Network, Inc. (1:109/42)
  982.  
  983. +----------------------------------------------------------------------------+
  984.  
  985. From: nospam@savebandwidth.invalid                      07-Nov-99 13:05:27
  986.   To: All                                               07-Nov-99 15:15:21
  987. Subj: Re: Ultimail Question
  988.  
  989. From: nospam@savebandwidth.invalid       (John Thompson)
  990.  
  991. In <3824F5A6.FD425A7B@netcenter.net>, Bob Grimes <sctvguy@netcenter.net>
  992. writes:
  993.  
  994. >Just fooling around with Warp Connect's Ultimail program.  I can get it
  995. >to receive mail from Earthlink, but I cannot send it.  It comes back
  996. >with a message, " Message file not found".  I really don't use it (only
  997. >used it on ibm.net), but I would like to know why it will not send the
  998. >letters.
  999.  
  1000. UltiMail uses OS/2 sendmail for mail delivery.  Do you have 
  1001. sendmail running in daemon mode so it will spool your mail until 
  1002. you connect?  Do you invoke "sendmail -q" to send the queued 
  1003. messages after you connect to Earthlink?
  1004.  
  1005. -John (John.Thompson@attglobal.net)
  1006.  
  1007. --- WtrGate+ v0.93.p7 sn 165
  1008.  * Origin: Usenet: The Crimson Permanent Assurance (1:109/42)
  1009.  
  1010. +----------------------------------------------------------------------------+
  1011.  
  1012. From: say@sfu.ca                                        08-Nov-99 02:39:17
  1013.   To: All                                               08-Nov-99 03:40:17
  1014. Subj: ProNews2 trouble; Memory leak?
  1015.  
  1016. From: Daniel Say <say@sfu.ca>
  1017.  
  1018.   I've had a recent problem with ProNews2, 
  1019. which is why I'm not using it here.
  1020.  
  1021.   When pulling in the newsgroups and messages,
  1022. near the end of the task it crashes giving me
  1023. a Trap E error, and a previous message about
  1024. Newserver swapfile is full.
  1025.   I've moved my OS/2 swapfile address to 
  1026. a volume with 270 megabytes; it used to be
  1027. at the \os2\system with about 70 megabytes
  1028. free.
  1029.  
  1030.   The program is fine until the end when
  1031. there is a rush of RAM (62 megabytes) deletion
  1032. or outflow.  That is my PmPatrol monitor line
  1033. shows that RAM is dropping fast and going to 
  1034. zero from about 50 megabytes.  This is a 
  1035. sudden change.
  1036.  
  1037.   Has there been a memory leak problem documented
  1038. before?
  1039.  
  1040.                 Daniel Say
  1041.                 say@sfu.ca
  1042.  
  1043. --- WtrGate+ v0.93.p7 sn 165
  1044.  * Origin: Usenet: Simon Fraser University (1:109/42)
  1045.  
  1046. +----------------------------------------------------------------------------+
  1047.  
  1048. From: auofaq@locutus.ofB.ORG                            08-Nov-99 06:00:00
  1049.   To: All                                               10-Nov-99 05:30:18
  1050. Subj: FAQ: pointer to alt.usenet.offline-reader FAQs
  1051.  
  1052. From: auofaq@locutus.ofB.ORG (a.u.o FAQ)
  1053.  
  1054. Archive-name: offline-reader/usenet/pointer
  1055. Alt-usenet-offline-reader-archive-name: pointer
  1056. Posting-Frequency: weekly
  1057. Last-modified: 1998-Jul-12
  1058. Intro-Last-modified: 1998-Nov-21
  1059. Software-Last-modified: 1999-Oct-30
  1060.  
  1061. [
  1062.   Please note that this message has a Followup-To: alt.usenet.offline-reader
  1063.   which directs all followups to that one group only.  If you see a response
  1064.   directly to this post which spams all the groups on the list, that user is
  1065.   either extremely rude or using very broken software.  In either case, they
  1066.   might benefit from you mailing them, and asking them to correct it.
  1067.  
  1068.   Also note that there are no opinions in this pointer -- it merely contains
  1069.   unrefutable facts about the *.answers newsgroups.
  1070. ]
  1071.  
  1072. Alt.Usenet.Offline-Reader is about reading mail and news available to
  1073. your normal login account, but while you're not actually logged in.
  1074.  
  1075. The alt.usenet.offline-reader FAQ lists can be obtained via all
  1076. news.answers access methods:
  1077.  
  1078. quoting the news.answers FAQ:
  1079.  
  1080. ``
  1081.             Where are *.answers archived?
  1082.  
  1083.   All of the *.answers newsgroups are archived in the periodic posting
  1084. archive on rtfm.mit.edu [18.181.0.24].  Postings are located in the
  1085. anonymous ftp directories /pub/usenet/alt.answers,
  1086. /pub/usenet/comp.answers, etc., and are archived by "Archive-name".
  1087. Other subdirectories of /pub/usenet contain periodic postings that may
  1088. not appear in *.answers (as well as most of the *.answers postings),
  1089. saved by Subject line rather than by Archive-name.
  1090.  
  1091.   If you do not have anonymous ftp access, you can access the archives
  1092. by mail server as well.  Send an E-mail message to
  1093. mail-server@rtfm.mit.edu with "help" and "index" in the body on
  1094. separate lines for more information.
  1095. ''
  1096.  
  1097. The FAQ lists for alt.usenet.offline-reader can be found on the Internet:
  1098.   <ftp://rtfm.mit.edu/pub/usenet/alt.usenet.offline-reader/intro>
  1099.   <ftp://rtfm.mit.edu/pub/usenet/alt.usenet.offline-reader/software>
  1100.   <http://www.faqs.org/faqs/off-line-readers/usenet/intro/>
  1101.   <http://www.faqs.org/faqs/off-line-readers/usenet/software/>
  1102.  
  1103. Note that, despite the name including `usenet' and not `mail', discussion of
  1104. mail as well as news is welcomed (and common) in alt.usenet.offline-reader.
  1105.  
  1106. --- WtrGate+ v0.93.p7 sn 165
  1107.  * Origin: Usenet: Private System, Edmonton, AB, Canada (1:109/42)
  1108.  
  1109. +----------------------------------------------------------------------------+
  1110.  
  1111. From: commafaq@locutus.ofB.ORG                          07-Nov-99 06:00:00
  1112.   To: All                                               10-Nov-99 05:30:18
  1113. Subj: FAQ: News and Mail: pointer to comp.os.msdos.mail-news FAQs
  1114.  
  1115. From: commafaq@locutus.ofB.ORG
  1116.  
  1117. Archive-name: msdos-mail-news/pointer
  1118. Comp-os-msdos-mail-news-archive-name: pointer
  1119. Posting-Frequency: weekly
  1120. Last-modified: 1998-Jul-12
  1121. Intro-Last-modified: 1998-Sep-27
  1122. Software-Last-modified: 1999-Oct-30
  1123.  
  1124. Comp.Os.Msdos.MAil-news == c.o.m.ma == comma
  1125. FAQ == Frequently Asked Questions
  1126.  
  1127. comma is about uucp, mail, and news for msdos or ms-windows or os2.
  1128.  
  1129. The comp.os.msdos.mail-news FAQ lists can be obtained via all
  1130. news.answers access methods:
  1131.  
  1132. quoting the news.answers FAQ:
  1133.  
  1134. ``
  1135.             Where are *.answers archived?
  1136.  
  1137.   All of the *.answers newsgroups are archived in the periodic posting
  1138. archive on rtfm.mit.edu [18.181.0.24].  Postings are located in the
  1139. anonymous ftp directories /pub/usenet/alt.answers,
  1140. /pub/usenet/comp.answers, etc., and are archived by "Archive-name".
  1141. Other subdirectories of /pub/usenet contain periodic postings that may
  1142. not appear in *.answers (as well as most of the *.answers postings),
  1143. saved by Subject line rather than by Archive-name.
  1144.  
  1145.   If you do not have anonymous ftp access, you can access the archives
  1146. by mail server as well.  Send an E-mail message to
  1147. mail-server@rtfm.mit.edu with "help" and "index" in the body on
  1148. separate lines for more information.
  1149. ''
  1150.  
  1151. The FAQ lists for comp.os.msdos.mail-news can be found on the Internet:
  1152.   <ftp://rtfm.mit.edu/pub/usenet/comp.os.msdos.mail-news/intro>
  1153.   <ftp://rtfm.mit.edu/pub/usenet/comp.os.msdos.mail-news/software>
  1154.   <http://www.faqs.org/faqs/msdos-mail-news/intro/>
  1155.   <http://www.faqs.org/faqs/msdos-mail-news/software/>
  1156.  
  1157. Note that the charter of comp.os.msdos.mail-news _explicitly_ covers
  1158. mail, news, and uucp under msdos and compatibles, and used to cover
  1159. ms-windows and os2 until they got their own groups (although uucp
  1160. under ms-windows didn't, so it can stay).  the FAQs still list
  1161. information for os2 users and ms-windows users.
  1162.  
  1163. --- WtrGate+ v0.93.p7 sn 165
  1164.  * Origin: Usenet: Private System, Edmonton, AB, Canada (1:109/42)
  1165.  
  1166. +----------------------------------------------------------------------------+
  1167.  
  1168. From: internet@messelink.tmfweb.nl                      11-Nov-99 17:19:18
  1169.   To: All                                               11-Nov-99 14:39:02
  1170. Subj: www.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nl
  1171.  
  1172. From: "Elco Messelink" <internet@messelink.tmfweb.nl>
  1173.  
  1174. www.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.mes
  1175. selink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nl
  1176.  
  1177.  
  1178. --- WtrGate+ v0.93.p7 sn 165
  1179.  * Origin: Usenet: FreeSurf (1:109/42)
  1180.  
  1181. +----------------------------------------------------------------------------+
  1182.  
  1183. From: frank@consol.de                                   12-Nov-99 09:11:01
  1184.   To: All                                               12-Nov-99 05:21:02
  1185. Subj: PMMail 2.1 - bugs and features
  1186.  
  1187. From: "Frank Winkler @home" <frank@consol.de>
  1188.  
  1189. Hi there !
  1190.  
  1191. I already posted the following article on Oct 30th, but due to a news server 
  1192. problem, it doesn't seem to have been propagated :( ...
  1193.  
  1194.  ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< =====
  1195.  
  1196. I include some parts of the list of changes for PMMail 2.1 which I received 
  1197. from the new team. Of course, I couldn't test all the mentioned things but 
  1198. I'll tell you my new experiences ...
  1199.  
  1200.  
  1201.   -Fixed a crash on printing
  1202.   -Fixed a crash when printing messages with *really* long lines
  1203.  
  1204. Sorry to disappoint you. When I try to print an arbitrary message, this still 
  1205. causes a crash:
  1206.  
  1207. ------------------------------------------------------------
  1208.  
  1209. 10-30-1999  11:25:15  SYS3175  PID 002d  TID 0002  Slot 0075
  1210. F:\SOUTHSOFT\PMMAIL\PMMAIL-2.10.1999.EXE
  1211. c0000005
  1212. 000651ea
  1213. P1=00000002  P2=01f8f59c  P3=XXXXXXXX  P4=XXXXXXXX  
  1214. EAX=01f9d2c0  EBX=01f9d2c0  ECX=ffff76e0  EDX=000df7c4
  1215. ESI=00000000  EDI=01f9fb88  
  1216. DS=0053  DSACC=d0f3  DSLIM=1fffffff  
  1217. ES=0053  ESACC=d0f3  ESLIM=1fffffff  
  1218. FS=150b  FSACC=00f3  FSLIM=00000030
  1219. GS=0000  GSACC=****  GSLIM=********
  1220. CS:EIP=005b:000651ea  CSACC=d0df  CSLIM=1fffffff
  1221. SS:ESP=0053:01f97ebc  SSACC=d0f3  SSLIM=1fffffff
  1222. EBP=01f97ecc  FLG=00012206
  1223.  
  1224. PMMAIL-2.10.1999.EXE 0001:000551ea
  1225.  
  1226. ------------------------------------------------------------
  1227.  
  1228. 10-30-1999  11:25:16  SYS3170  PID 002d  TID 0001  Slot 005c
  1229. F:\SOUTHSOFT\PMMAIL\PMMAIL-2.10.1999.EXE
  1230. ec8391ec
  1231. 8957000f
  1232. EAX=00000000  EBX=00000000  ECX=02290000  EDX=00000000
  1233. ESI=00000000  EDI=00000000  
  1234. DS=0053  DSACC=d0f3  DSLIM=1fffffff  
  1235. ES=0053  ESACC=d0f3  ESLIM=1fffffff  
  1236. FS=150b  FSACC=00f3  FSLIM=00000030
  1237. GS=0000  GSACC=****  GSLIM=********
  1238. CS:EIP=005b:1e9719e9  CSACC=d0df  CSLIM=1fffffff
  1239. SS:ESP=0053:001befb0  SSACC=d0f3  SSLIM=1fffffff
  1240. EBP=00000000  FLG=00012206
  1241.  
  1242. ------------------------------------------------------------
  1243.  
  1244. This problem occurs since 2.0 :( ... and several test versions didn't cure it 
  1245. yet.
  1246.  
  1247.   -Changed the behavior of opening a body in the outbox...when doing
  1248.    this, PMMail now defaults the message to NO SIG...this removes the
  1249.    double sig problem
  1250.  
  1251. Right. But PMMail still adds several blank lines after the signature.
  1252.  
  1253.   -Added some RMB cut, copy, and paste options
  1254.  
  1255. This does not seem to work in combination with Xit - didn't we hear that in 
  1256. earlier versions?
  1257.  
  1258.  
  1259. -Added the option to use the spacebar to page through messages
  1260.  
  1261.  
  1262. -Fixed a bug with account where turing off "Leave on server" would
  1263.  tell you there were messages up on the server when there weren't
  1264.  
  1265.  
  1266. Other bugs:
  1267.  
  1268. - The attachment indicator in the Remote Control still doesn't work
  1269. - The attachment area in outbox windows is invisible again after reopening it;
  1270.   even after performing "Save window position".
  1271.  
  1272.  
  1273. At least, I have some proposals for new features which I already sent to 
  1274. SouthSoft several times. Perhaps the new maintainers also think that they'd be 
  1275.  
  1276. useful :) ...
  1277.  
  1278. - Add a "Reply-To" input field behind "To" the same way as it is for "CC" and
  1279.   "BCC"
  1280. - Allow address book entries for combinations of "To" and "[B]CC"
  1281. - perhaps even with an option to specify a certain signature to use
  1282. - If I forward a message, currently the full header is included and quoted.
  1283.   IMO it would be better to default to skipping everything but "From", "To",
  1284.   "Date" and "Subject" and not to quote this in the same manner as the body
  1285.   text. And let's add a switch to be able to include  the complete header.
  1286. - Also add a "find" feature in the compose window (see read window)
  1287. - Add IMAP support
  1288. - Enable saving search options as a template so that we get some kind of
  1289.   message views (show all messages from Mister X.)
  1290. - Allow other actions than "read" for search results and also for more than
  1291.   one result in the same action
  1292.  
  1293. Any comments?
  1294.  
  1295. BTW: Will BluePrint also continue the work on PMINews?
  1296.  
  1297. TIA
  1298.  
  1299. -- 
  1300. ----------------------------------------------------------------------------
  1301. Frank Winkler                                                frank@consol.de
  1302. ConSol GmbH
  1303. Franziskanerstr. 38                                   Voice +49 89 45841.180
  1304. 81669 Munich - Germany                                  Fax +49 89 45841.199
  1305.  
  1306.  
  1307.  
  1308.  
  1309. --- WtrGate+ v0.93.p7 sn 165
  1310.  * Origin: Usenet: private OS/2 site (1:109/42)
  1311.  
  1312. +----------------------------------------------------------------------------+
  1313.  
  1314. From: raphaelt@netnews.worldnet.att.net                 12-Nov-99 08:17:08
  1315.   To: All                                               12-Nov-99 14:25:26
  1316. Subj: Re: PMMail 2.1 - bugs and features
  1317.  
  1318. From: raphaelt@netnews.worldnet.att.net (Raphael Tennenbaum)
  1319.  
  1320. "Frank Winkler @home" <frank@consol.de> wrote:
  1321.  
  1322. >Hi there !
  1323. >
  1324. >I already posted the following article on Oct 30th, but due to a news server 
  1325. >problem, it doesn't seem to have been propagated :( ...
  1326.  
  1327.  
  1328. Frank -- 
  1329.  
  1330. Probably the best place to bring up your concerns is the
  1331. PMMail listserv: to subscribe, send a message to
  1332. <listar@rpglink.com> with the command "subscribe pmmail" in
  1333. the body of the message.
  1334.  
  1335. There are some annoying things about the list but on the
  1336. whole it's useful.
  1337.  
  1338.  
  1339. -- 
  1340. Ray Tennenbaum        '99 YZF-R6
  1341. readme@ http://www.ray-field.com
  1342.  
  1343. --- WtrGate+ v0.93.p7 sn 165
  1344.  * Origin: Usenet: AT&T WorldNet Services (1:109/42)
  1345.  
  1346. +----------------------------------------------------------------------------+
  1347.  
  1348. +============================================================================+
  1349.