comp.os.os2.mail-news (Usenet) Saturday, 06-Nov-1999 to Friday, 12-Nov-1999 +----------------------------------------------------------------------------+ From: none@none.net 06-Nov-99 08:44:26 To: All 06-Nov-99 05:25:28 Subj: EARN $1000 TO $5000 WEEKLY!!! 620 From: none@none.net FINALLY!!! A SIMPLE ONLINE SYSTEM FOR MAKING FAST, EASY, MONEY THAT LASTS !!! A TOTAL NO-BRAINER THAT ANYONE IN THE WORLD CAN DO !!! Go to: http://opportunity.valuenetusa.com/JL2836/ AND GET STARTED TODAY !!! gmjcfpcqljkfqlptqsfbcxhpbhrefjxfbksshpmjtd --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: AT&T WorldNet Services (1:109/42) +----------------------------------------------------------------------------+ From: dwparsons@t-online.de 06-Nov-99 09:13:07 To: All 06-Nov-99 05:25:28 Subj: Re: Whats the free best News server for OS/2? From: dwparsons@t-online.de (Dave Parsons) On Thu, 4 Nov 1999 00:23:09, nospam@savebandwidth.invalid (John Thompson) wrote: > In <381FCF08.9B1B3CFF@connect.net.au>, Greg Thomas writes: > > >I've got a bit of a LAN at home and wanting to setup a News Server. I > >have had a bit of a look at Changi (though not deeply yet), but was > >wondering if those in the know could tell me if I should be looking at > >something else instead. > > I've been using changi here for several years. Never > even bothered looking further; I'm not even sure there are other > free OS/2 news server packages. > > -John (John.Thompson@attglobal.net) > There is another one called KNM which is available on LEO which I have just found and started to assess. It is an NNTP, SMTP and POP3 server/relay which is written in JAVA. So far it seems to work OK but the GUI is a bit slow on my Pentium 133. I havn't tried it on my faster machine yet. -- Dave --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: CDL (1:109/42) +----------------------------------------------------------------------------+ From: bvermo@powertech.no 06-Nov-99 22:24:03 To: All 06-Nov-99 20:02:24 Subj: Re: Need help with Ultimail on OS/2 WSeB From: =?iso-8859-1?Q?Bj=F8rn?= Vermo hamei@pacbell.net wrote: > > since it is only possible to even HAVE two codepages on a system > your complaint isn't the half of it The limit of two codepages applies to what the user can switch between in VIO sessions. There is no limit to the number of codepages a PM application program may read, write, convert between or display. IBM have always supplied the tools, and programmers have neglected to use them. There is even a place for the codepage in the standard EAs of a file, but it is poorly documented and never used. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Norbionics (1:109/42) +----------------------------------------------------------------------------+ From: bobmcl@ibm.net 04-Nov-99 08:48:28 To: All 06-Nov-99 20:02:24 Subj: Re: Need help with Ultimail on OS/2 WSeB From: Bob McLellan Robert Basler wrote: > I'm trying to get Ultimail 2.10.004 to work on OS/2 WSeB, I couldn't > find any way to install just ultimail from the Warp 4 CD's, so I copied > my UMAIL directory and mailstor over wholesale from my working Warp 4 > system, then put the SENDMAIL.UML file into the MPTN directory. Note > that all paths are the same on both systems. > > It will send and recieve mail as long as you are connected to the > internet. > > If you are not connected and send a message, it says that it was queued > successfully, but there is no message in the MQUEUE directory and the > message text can be found in a file called DEADLET.TER in the MPTN\ETC > directory. > > I have the ETC dir set to MPTN\ETC > > When I connect to the internet, it does not do the sendmail thing in the > status window, but I suspect that this has more to do with there being > no files in the MQUEUE directory, rather than some problem with that > program feature. > > Suggestions??? I really want to stick to Ultimail since I have > thousands of archived messages that I access regularly and have been > very happy with the app in general to date. > > This is what I got when I ran UMCHECK.CMD > > The key "AURORASW /MAIL_GW" in D:\MPTN\ETC\TCPOS2.INI was not found! > No "Mlocal" line was found in D:\MPTN\ETC\SENDMAIL.CF! > > Installation information: > The UltiMail provider is ADVANTIS > TMP = D:\TCPIP\TMP > ETC = D:\MPTN\ETC > SRV = D:\TCPIP\UMAIL\SERVER > CONNECTION = AURORASW > POPSRVR = mail.direct.ca > REPLY_DOMAIN = direct.ca > MQueue from SENDMAIL.CF: D:\MPTN\ETC\MQUEUE > DD from SENDMAIL.CF: Your.Domain > MQueue from SENDMAIL.UML: D:\MPTN\ETC\MQUEUE > Mlocal from SENDMAIL.UML: Mlocal P=d:\tcpip\umail\umailer.exe > F=lsmDFP > S=10 R=0 A=-dest d:\tcpip\umail\server\inbox -to $u > > FYI my email address above is bogus, send email to: aurorasw direct ca > after inserting appropriate ats and dots, thanks. Look up the INSTALL command in the TCPIP command reference. It tells you how to set up a response file to select components of TCPIP for installation. One of the components is Ultimail. Just run INSTALL with a reponse file that selects only Ultimail. However, unless there is a specific need for Ultimail, I wouldn't use it. -- ------------------------------------------------------ Bob McLellan The Little Blue Kiwi OS/2 Solutions for New Zeland --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Global Network Services - Remote Access Mail & Ne (1:109/42) +----------------------------------------------------------------------------+ From: js@cwi.nl 07-Nov-99 00:00:01 To: All 06-Nov-99 21:41:10 Subj: (1/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft From: Jeroen Scheerder Archive-name: usenet/software/good-netkeeping-seal Posting-Frequency: monthly (first Sunday) Last-modified: Oct 4 1999 Version: 2.08 URL: Maintainer: Jeroen Scheerder -----BEGIN PGP SIGNED MESSAGE----- GNKSA * The Good 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 newsreaders. Unfortunately, these programs frequently violate assumptions that come naturally to people used to well-behaved readers: - The user can see the essential 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 "Good 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 "Good Net-Keeping Seal" standards, eventually. --%-@#@-%-- These are the proposed standards a Usenet news program should meet to deserve the "Good 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 conventions 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 MUST 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: <> However, it also says: <> So, bear 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 on a line starting with "References: " with a maximum length of 998 characters. (An octet is a byte of 8 bits, EOL representation takes two bytes.) 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. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: NAKA (1:109/42) +----------------------------------------------------------------------------+ From: js@cwi.nl 07-Nov-99 00:00:01 To: All 06-Nov-99 21:41:10 Subj: (2/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft 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 SHOULD 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 user 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 be `>', with optionally a trailing space (i.e. `> '). Caveat: with `>', the level of quotation is clearly reflected in the number of `>' characters at the start of the line. However, whitespace between quote prefix and quoted material improves readability, so it is good practice for newsreaders to use `> ' as the quote prefix for newly quoted, and `>' for repetitively quoted text. Included text SHOULD NOT contain the original article's signature, unless by explicit request of the user (under the condition that the signature can be determined of course, which is to say: if clearly separated by the standard signature delimiter). (see also #15 below). As a direct counterpart to this requirement, the software SHOULD offer the user some means of selecting exactly which part of a Usenet posting she wishes to followup to, and quote only that part initially. (A special case of this is when a user wishes to react to what's in a signature.) If it concerns 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. (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. Users can be careless or forgetful occasionally (or often, even) and neglect to edit out spurious quoted material; the signature, typically, is such material. In general, facilitating good quoting behaviour -- by quoting only a part indicated by the user, for example - - -- is an area in which software can help users substantially to create better articles. 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: ") 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 the user's 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 conventions 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 posting 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: <> 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. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: NAKA (1:109/42) +----------------------------------------------------------------------------+ From: js@cwi.nl 07-Nov-99 00:00:01 To: All 06-Nov-99 21:41:10 Subj: (3/3) Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Soft 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 servers unnecessarily. The sofware MUST limit itself to 4 simultaneous connections to a given server. Spurious connects and unnecessary traffic MUST be avoided; the software MUST use as few as possible connections, reusing existing connections whenever possible. 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 "Good 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current GNKSA, an evaluation form and an archive of software evaluations can be found at: (Mirror) (GNKSA 1.2) The GNKSA page also contains a pointer to a library that newsreader developers can freely make use of, providing basic `sanitary' functions. In addition to the Seal, anyone writing Usenet software should pay careful attention to the following documents: RFC 977, "Network News Transfer Protocol -- A Proposed Standard for the Stream-Based Transmission of News", by Brian Kantor and Phil Lapsley. RFC 1036, "Standard for Interchange of USENET Messages", by M. Horton and R. Adams. The proposed "Son of 1036", "News Article Format and Transmission", by Henry Spencer. (also news.ps.Z) "The UseFor Working Group Documents" (under development: Internet Drafts describing the minimal standards for a Usenet article, and the minimum features all Usenet software should have), by Simon Lyall (et al.). "Read This Before You Write a Newsreader, News Transport System, etc.", by Tom Limoncelli. "The "Good Net-Keeping Seal of Approval", revision 1.2, by Ron Newman; the previous version of this document, published in January, 1995. Excellent collections of things well worth reading in this context can be found at: "News Hacking", by Tim Pierce. "Notes on News", by Lars Magne Ingebrigtsen. 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. The part that explicitly deals with the issues of messing up "From: "-headers is: 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". Acknowledgements ~~~~~~~~~~~~~~~~ Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working Group initiative (and its derivatives). Ron Newman , of course, for writing the first version of the GNKSA, of which this document descends, and for fruitful discussions during revision. Sven Guckes for providing mailing list resources (among other things). Tim Pierce for scrutinous examination, useful hints, and previous GNKSA support. Larry Wall , Stefan Haller , John E. Davis , John Norstad , Karl-Johan Johnsson , Brian Clark , Simon Fraser for showing inspiring examples of the spirit of good net keeping in the form of exceptionally well-designed usenet reading programs. The kind folks of news.software.readers (you know who you are) that have helped discussing the issues that pertain to the GNSKA cause. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBN/iQ9ChIY6bIQPMpAQGljQP+MQwVaoE9FXCsE+ewpUAmWo58UrGlQwKk bpJ0ruTZ7CZs7rK1OHmJqr/H6FrBC5ll8y676LAEQQ1bTJR0viD+q/UEEpgTc0Wn b8aPn2F+DuhqelAvs2OkYHl0sv/LYXa7KvgsN+SLxWW2NhR7V0Iv99zQiTufFXKE BOG1YFh+bd0= =QL37 -----END PGP SIGNATURE----- --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: NAKA (1:109/42) +----------------------------------------------------------------------------+ From: sctvguy@netcenter.net 06-Nov-99 22:44:19 To: All 07-Nov-99 03:28:17 Subj: Ultimail Question From: Bob Grimes Just fooling around with Warp Connect's Ultimail program. I can get it to receive mail from Earthlink, but I cannot send it. It comes back with a message, " Message file not found". I really don't use it (only used it on ibm.net), but I would like to know why it will not send the letters. Thanks, Bob Grimes --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: EarthLink Network, Inc. (1:109/42) +----------------------------------------------------------------------------+ From: nospam@savebandwidth.invalid 07-Nov-99 13:05:27 To: All 07-Nov-99 15:15:21 Subj: Re: Ultimail Question From: nospam@savebandwidth.invalid (John Thompson) In <3824F5A6.FD425A7B@netcenter.net>, Bob Grimes writes: >Just fooling around with Warp Connect's Ultimail program. I can get it >to receive mail from Earthlink, but I cannot send it. It comes back >with a message, " Message file not found". I really don't use it (only >used it on ibm.net), but I would like to know why it will not send the >letters. UltiMail uses OS/2 sendmail for mail delivery. Do you have sendmail running in daemon mode so it will spool your mail until you connect? Do you invoke "sendmail -q" to send the queued messages after you connect to Earthlink? -John (John.Thompson@attglobal.net) --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: The Crimson Permanent Assurance (1:109/42) +----------------------------------------------------------------------------+ From: say@sfu.ca 08-Nov-99 02:39:17 To: All 08-Nov-99 03:40:17 Subj: ProNews2 trouble; Memory leak? From: Daniel Say I've had a recent problem with ProNews2, which is why I'm not using it here. When pulling in the newsgroups and messages, near the end of the task it crashes giving me a Trap E error, and a previous message about Newserver swapfile is full. I've moved my OS/2 swapfile address to a volume with 270 megabytes; it used to be at the \os2\system with about 70 megabytes free. The program is fine until the end when there is a rush of RAM (62 megabytes) deletion or outflow. That is my PmPatrol monitor line shows that RAM is dropping fast and going to zero from about 50 megabytes. This is a sudden change. Has there been a memory leak problem documented before? Daniel Say say@sfu.ca --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Simon Fraser University (1:109/42) +----------------------------------------------------------------------------+ From: auofaq@locutus.ofB.ORG 08-Nov-99 06:00:00 To: All 10-Nov-99 05:30:18 Subj: FAQ: pointer to alt.usenet.offline-reader FAQs From: auofaq@locutus.ofB.ORG (a.u.o FAQ) Archive-name: offline-reader/usenet/pointer Alt-usenet-offline-reader-archive-name: pointer Posting-Frequency: weekly Last-modified: 1998-Jul-12 Intro-Last-modified: 1998-Nov-21 Software-Last-modified: 1999-Oct-30 [ Please note that this message has a Followup-To: alt.usenet.offline-reader which directs all followups to that one group only. If you see a response directly to this post which spams all the groups on the list, that user is either extremely rude or using very broken software. In either case, they might benefit from you mailing them, and asking them to correct it. Also note that there are no opinions in this pointer -- it merely contains unrefutable facts about the *.answers newsgroups. ] Alt.Usenet.Offline-Reader is about reading mail and news available to your normal login account, but while you're not actually logged in. The alt.usenet.offline-reader FAQ lists can be obtained via all news.answers access methods: quoting the news.answers FAQ: `` Where are *.answers archived? All of the *.answers newsgroups are archived in the periodic posting archive on rtfm.mit.edu [18.181.0.24]. Postings are located in the anonymous ftp directories /pub/usenet/alt.answers, /pub/usenet/comp.answers, etc., and are archived by "Archive-name". Other subdirectories of /pub/usenet contain periodic postings that may not appear in *.answers (as well as most of the *.answers postings), saved by Subject line rather than by Archive-name. If you do not have anonymous ftp access, you can access the archives by mail server as well. Send an E-mail message to mail-server@rtfm.mit.edu with "help" and "index" in the body on separate lines for more information. '' The FAQ lists for alt.usenet.offline-reader can be found on the Internet: Note that, despite the name including `usenet' and not `mail', discussion of mail as well as news is welcomed (and common) in alt.usenet.offline-reader. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Private System, Edmonton, AB, Canada (1:109/42) +----------------------------------------------------------------------------+ From: commafaq@locutus.ofB.ORG 07-Nov-99 06:00:00 To: All 10-Nov-99 05:30:18 Subj: FAQ: News and Mail: pointer to comp.os.msdos.mail-news FAQs From: commafaq@locutus.ofB.ORG Archive-name: msdos-mail-news/pointer Comp-os-msdos-mail-news-archive-name: pointer Posting-Frequency: weekly Last-modified: 1998-Jul-12 Intro-Last-modified: 1998-Sep-27 Software-Last-modified: 1999-Oct-30 Comp.Os.Msdos.MAil-news == c.o.m.ma == comma FAQ == Frequently Asked Questions comma is about uucp, mail, and news for msdos or ms-windows or os2. The comp.os.msdos.mail-news FAQ lists can be obtained via all news.answers access methods: quoting the news.answers FAQ: `` Where are *.answers archived? All of the *.answers newsgroups are archived in the periodic posting archive on rtfm.mit.edu [18.181.0.24]. Postings are located in the anonymous ftp directories /pub/usenet/alt.answers, /pub/usenet/comp.answers, etc., and are archived by "Archive-name". Other subdirectories of /pub/usenet contain periodic postings that may not appear in *.answers (as well as most of the *.answers postings), saved by Subject line rather than by Archive-name. If you do not have anonymous ftp access, you can access the archives by mail server as well. Send an E-mail message to mail-server@rtfm.mit.edu with "help" and "index" in the body on separate lines for more information. '' The FAQ lists for comp.os.msdos.mail-news can be found on the Internet: Note that the charter of comp.os.msdos.mail-news _explicitly_ covers mail, news, and uucp under msdos and compatibles, and used to cover ms-windows and os2 until they got their own groups (although uucp under ms-windows didn't, so it can stay). the FAQs still list information for os2 users and ms-windows users. --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: Private System, Edmonton, AB, Canada (1:109/42) +----------------------------------------------------------------------------+ From: internet@messelink.tmfweb.nl 11-Nov-99 17:19:18 To: All 11-Nov-99 14:39:02 Subj: www.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nl From: "Elco Messelink" www.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nlwww.mes selink.tmfweb.nlwww.messelink.tmfweb.nlwww.messelink.tmfweb.nl --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: FreeSurf (1:109/42) +----------------------------------------------------------------------------+ From: frank@consol.de 12-Nov-99 09:11:01 To: All 12-Nov-99 05:21:02 Subj: PMMail 2.1 - bugs and features From: "Frank Winkler @home" Hi there ! I already posted the following article on Oct 30th, but due to a news server problem, it doesn't seem to have been propagated :( ... ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< ===== 8< ===== I include some parts of the list of changes for PMMail 2.1 which I received from the new team. Of course, I couldn't test all the mentioned things but I'll tell you my new experiences ... -Fixed a crash on printing -Fixed a crash when printing messages with *really* long lines Sorry to disappoint you. When I try to print an arbitrary message, this still causes a crash: ------------------------------------------------------------ 10-30-1999 11:25:15 SYS3175 PID 002d TID 0002 Slot 0075 F:\SOUTHSOFT\PMMAIL\PMMAIL-2.10.1999.EXE c0000005 000651ea P1=00000002 P2=01f8f59c P3=XXXXXXXX P4=XXXXXXXX EAX=01f9d2c0 EBX=01f9d2c0 ECX=ffff76e0 EDX=000df7c4 ESI=00000000 EDI=01f9fb88 DS=0053 DSACC=d0f3 DSLIM=1fffffff ES=0053 ESACC=d0f3 ESLIM=1fffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:000651ea CSACC=d0df CSLIM=1fffffff SS:ESP=0053:01f97ebc SSACC=d0f3 SSLIM=1fffffff EBP=01f97ecc FLG=00012206 PMMAIL-2.10.1999.EXE 0001:000551ea ------------------------------------------------------------ 10-30-1999 11:25:16 SYS3170 PID 002d TID 0001 Slot 005c F:\SOUTHSOFT\PMMAIL\PMMAIL-2.10.1999.EXE ec8391ec 8957000f EAX=00000000 EBX=00000000 ECX=02290000 EDX=00000000 ESI=00000000 EDI=00000000 DS=0053 DSACC=d0f3 DSLIM=1fffffff ES=0053 ESACC=d0f3 ESLIM=1fffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1e9719e9 CSACC=d0df CSLIM=1fffffff SS:ESP=0053:001befb0 SSACC=d0f3 SSLIM=1fffffff EBP=00000000 FLG=00012206 ------------------------------------------------------------ This problem occurs since 2.0 :( ... and several test versions didn't cure it yet. -Changed the behavior of opening a body in the outbox...when doing this, PMMail now defaults the message to NO SIG...this removes the double sig problem Right. But PMMail still adds several blank lines after the signature. -Added some RMB cut, copy, and paste options This does not seem to work in combination with Xit - didn't we hear that in earlier versions? -Added the option to use the spacebar to page through messages -Fixed a bug with account where turing off "Leave on server" would tell you there were messages up on the server when there weren't Other bugs: - The attachment indicator in the Remote Control still doesn't work - The attachment area in outbox windows is invisible again after reopening it; even after performing "Save window position". At least, I have some proposals for new features which I already sent to SouthSoft several times. Perhaps the new maintainers also think that they'd be useful :) ... - Add a "Reply-To" input field behind "To" the same way as it is for "CC" and "BCC" - Allow address book entries for combinations of "To" and "[B]CC" - perhaps even with an option to specify a certain signature to use - If I forward a message, currently the full header is included and quoted. IMO it would be better to default to skipping everything but "From", "To", "Date" and "Subject" and not to quote this in the same manner as the body text. And let's add a switch to be able to include the complete header. - Also add a "find" feature in the compose window (see read window) - Add IMAP support - Enable saving search options as a template so that we get some kind of message views (show all messages from Mister X.) - Allow other actions than "read" for search results and also for more than one result in the same action Any comments? BTW: Will BluePrint also continue the work on PMINews? TIA -- ---------------------------------------------------------------------------- Frank Winkler frank@consol.de ConSol GmbH Franziskanerstr. 38 Voice +49 89 45841.180 81669 Munich - Germany Fax +49 89 45841.199 --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: private OS/2 site (1:109/42) +----------------------------------------------------------------------------+ From: raphaelt@netnews.worldnet.att.net 12-Nov-99 08:17:08 To: All 12-Nov-99 14:25:26 Subj: Re: PMMail 2.1 - bugs and features From: raphaelt@netnews.worldnet.att.net (Raphael Tennenbaum) "Frank Winkler @home" wrote: >Hi there ! > >I already posted the following article on Oct 30th, but due to a news server >problem, it doesn't seem to have been propagated :( ... Frank -- Probably the best place to bring up your concerns is the PMMail listserv: to subscribe, send a message to with the command "subscribe pmmail" in the body of the message. There are some annoying things about the list but on the whole it's useful. -- Ray Tennenbaum '99 YZF-R6 readme@ http://www.ray-field.com --- WtrGate+ v0.93.p7 sn 165 * Origin: Usenet: AT&T WorldNet Services (1:109/42) +----------------------------------------------------------------------------+ +============================================================================+