F I D O N E W S -- Volume 13, Number 46 11 November 1996 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ ONLY ONE GUEST HEADLINE RECEIVED SO FAR! IT APPEARS NEXT WEEK! Table of Contents 1. EDITORIAL ................................................ 1 Moving right along ....................................... 1 2. ARTICLES ................................................. 2 Boom, boom Bob! .......................................... 2 Everything in Moderation ................................. 2 What FTS-0004 should be like ............................. 6 The Future of FidoNet...and a correction ................. 14 Speaking of Atari-related echoes ......................... 15 3. GETTING TECHNICAL ........................................ 18 FTS-0004, The Echomail Specs ............................. 18 4. COORDINATORS CORNER ...................................... 26 Nodelist-statistics as seen from Zone-2 for day 313 ...... 26 5. ECHOING .................................................. 27 Backbone Echo Changes [Sep-Oct] .......................... 27 6. WE GET EMAIL ............................................. 29 _Policy Complaint_ ....................................... 29 7. NET HUMOR ................................................ 35 Hacker Purity Test ....................................... 35 Opus v51.1 ............................................... 50 8. NOTICES .................................................. 52 Future History ........................................... 52 PKZIP has a new version that is REAL! .................... 52 9. FIDONET SOFTWARE LISTING ................................. 56 Latest Greatest Software Versions ........................ 56 And more! FIDONEWS 13-46 Page 1 11 Nov 1996 ================================================================= EDITORIAL ================================================================= The second FidoNet Technical Standard appears today. FTS-0004 was lifted from the docs of ConfMail by Bob Hartman in the dim time of Echomail operations. FTS-0004 has a counter-point in FSC-0074 [which is way down the list for numerical publication in these spaces], the proposal for a new Echomail spec. Anticipating the FTS-0004 publication today, I have also received an adjusted version of FSC-0074 which also appears in this Issue. It should make an interesting comparison for those of you technically inclined. Next week's Headline was the first and only entry to-date in the Headline submission contest posed as a Question of the Week a couple Issues back. You'll have to ask the submitter [Damian Walker of 2:2502/666] what it means or pertains to, however. I haven't got a clue. [grin] C.B. ----------------------------------------------------------------- FIDONEWS 13-46 Page 2 11 Nov 1996 ================================================================= ARTICLES ================================================================= PC nonsense! by Lee Kindness, 2:259/7 Bob Morasvik writes in fnewsd45: > make it my business. By not filing a PC against me > it is your admission that I'm right and you are wrong. > My NC is Sean Aldrich 1:2606/0...the lines are open. Oh, please! Can we not have a *discussion* without reverting to this sort of rubbish! I will not waste any NC's time over a thread in *Fidonews*, nor will I continue a discussion when this is the view of one of the participants! ----------------------------------------------------------------- Everything in Moderation Damian Walker, 2:2502/666 With all this talk of echo policy which is flying around echoes and Fidonews itself, one of the subjects at the centre of conversation is, once again, echo moderators. These people are often the object of controversy in Fidonet. Who are they? What do they do? What should they do? Who gives them the right to tell me what to do?! When conversation does come around to moderators, it usually orbits even more closely closely around the matter of feed cuts. But why should it? Feed cuts are not the only thing a moderator can do with their echo. In this article, I will take a look at some of the duties of moderators, some of the issues generating criticism levelled at them, and suggest for those who are interested what more a moderator can do for his or her echo. So, first of all, what is a moderator? Most people who know enough about Fidonet to find this copy of Fidonews probably already know what a moderator is. The moderator, in general terms, is someone who takes the responsibility of making sure a particular echo maintains the purpose for which the echo was originally set up. This 'purpose' could cover a lot of things. Usually the most important is the topic, or subject, of the echo. Then comes its intended readership, as an echo should allow (or restrict) access to a certain group of people, whether this is 'sysops', 'everyone' or some other criterion. The other one which springs to mind from my own echoes is 'atmosphere'. Is it supposed to be a friendly, chatty echo? Or perhaps something more efficient and businesslike, particularly where the echo set up to get a job done, rather than existing solely for the amusement of its readers. There could be other aspects to the echo's purpose. As an aside, some people question the need for echo moderators. After all, many Internet newsgroups manage without them. Or do they? Another school of thought suggests that a lot of the meaningless noise FIDONEWS 13-46 Page 3 11 Nov 1996 in newsgroups (which I have witnessed in some newsgroups myself) comes about because there is no-one to oversee the newsgroup in the way that a moderator does in Fidonet. It seems there may be a place for both moderated and unmoderated echoes, after all. But back to the topic in hand... So how should the echo purpose be maintained? This varies from one echo to another, and there may be more than just one simple way to do the job, a fact that creates much of the controversy centred around moderators. The policies or requirements for some backbone structures state explicitly what a moderator's duties should be, and make suggestions or restrictions on how they should be carried out. Such policies often try to achieve a balance between absolute control for the moderator, and some form of comeback to protect genuine users from the effects of the overly dictatorial moderators who sometimes appear. Even then, the subject of such policies often settles immovably upon the question of unruly users and feed cuts. Where are the more positive aspects of moderation? Even if these should not be regulated, the lack of suggestions might put the new or less experienced moderator at a loss for ideas. In practice, moderators often exercise some of both the positive and negative aspects of moderation, although the balance is not consistent from one moderator to the next. Even among echoes moderated by a single person, the balance may not be the same. Firstly, what about the negative aspects of moderation? The rules, the warnings, the feed cuts? The first is hardly something which can be regulated, and it is difficult even to advise upon, given the wide range of purposes an echo may have. Usually, a moderator will use the rules of another echo they enjoy reading as a guideline for their own echo. Sometimes this is a good move, and sometimes it isn't. Many moderators adjust the rules as they find things which are undesirable or unenforceable. The issue of warnings is clear cut in many policies. A recurring theme is the requirement for three formal warnings before a feed cut can be made. Personally, I prefer not to give formal warnings, since these may alienate genuine users who have simply made a mistake in a friendly conference, but this is just a personal issue. Some moderators stick rigidly to the formal warning principle, where others might try other methods such as making polite requests to stay on topic or civil. One such moderator in an echo I used to read would also suggest echoes in which off-topic messages might be appropriate; such a helpful approach maintained a friendly atmosphere, even when he was giving as many 'warnings' as in some less friendly echoes. The final negative issue, that of feed cuts, is regularly the object of moderator-related controversy. Although a good moderator (or a moderator with an easy job) might have to make few of these, discussion about them takes up far more bandwidth than their frequency would suggest. There are a number of ways feed cuts may be implemented. A request to the user to stop writing is rarely going to work. A request to the sysop of the offending user is one approach, although many sysops will want more than a simple request before cutting a feed. Some will insist on the mandatory three warnings, others will be less rigid, but still want to see evidence of misbehaviour. Another approach sometimes used is to make a demand to the sysop for a feed cut, backed up by a backbone policy, but such an FIDONEWS 13-46 Page 4 11 Nov 1996 unfriendly way of doing things may work against the moderator, particularly when the fact that they are backed up by policy is open to interpretation. But now I've given these negative aspects of moderator duties more time than I wanted to, so lets move on to the more positive aspects of moderating echoes. What do moderators currently do? Firstly, the moderator is frequently the person who sets up an echo. This may be more work than it at first appears, depending upon the requirements of a local backbone or other distribution system. Some need a minimum traffic level, others have requirements upon existing distribution (e.g. the echo must be distributed to at least 3 nets). Some are more lucky, in my native region 25 all we have to do is send a copy of the echo rules (and the echo tag, description and moderator name/address) to our REC to get an echo on the regional backbone. But once an echo is on the backbone, or even beforehand, there are other things to be done. Most of this is down to promotion. The simplest way to promote an echo is to advertise it, particularly in other echoes which are set up for such advertising. This is the approach most often used in my own locality, with the ECHO-NEWS conference specifically set up for moderators (or other parties) to gain support for echoes. There are similar echoes available in some, but not all, parts of the network. An alternative way to advertise an echo is by including a bulletin on your own (or your sysop's) BBS, directing users to the echo. This is of more use on specialist BBS's, where an echo pertaining to that system's subject is more likely to attract users. Another common way of promoting echoes is to stimulate discussion within the echo itself. Once advertising has attracted a user to an echo, there should be something to read once they get there, or the user will just assume the echo is dead, and not give it a second look. There are a number of approaches to this. One is to forward information from other sources, such as books and magazines, other echoes, or conferences on different networks such as Compuserve or the Internet. Where direct crossposting is legal, it may be used in order to make the echo a good source of real information (as opposed to discussion on information available elsewhere). Another approach applicable to some echoes is merely to post large numbers of messages as and when inspiration occurs. My own approach is to try and post at least one message a day, a thread starter, in order to get people talking. This is especially useful when echo traffic drops off, and could even be a necessary procedure on backbones which require echoes to maintain a minimum amount of traffic. Sometimes I have no personal interest in the questions I ask in my own echoes, but hope that somebody else does. There are some less common activities a moderator can do in order to maintain the echo purpose (the purpose being something which should always be borne in mind by moderators going about their moderatorial duties-- forget politics or ego here). I will draw these from my own echoes and some of the other echoes I have participated in or read about. As for promotion, dare I raise the subject of document servers yet again? Yes, of course I dare, since these are a good way of distributing information about an echo, particularly more detailed information which is not appropriate for a general echo advertising conference or a log-on BBS bulletin. These can be particularly useful FIDONEWS 13-46 Page 5 11 Nov 1996 for directing users to related echoes as well. Within the echo, there are some things which can maintain users' interest. One which I have seen in an echo is a directory of echo users, users being added either with their permission or by using information sent by themselves. Either way prevents users appearing in a directory when they don't want their name listed. It may be interesting to offer this list externally (by FReq or netmail) as well as by regular post in the echo. A few echoes offer an echo-related file list. One echo I know of does this by gathering the files on one system, and maintaining mirror sites. One of my own echoes has a FReq list, which contains files available on all participating systems from which the sysop is prepared to send me their file list. These files are obviously restricted to those relevant to the echo, and the list contains by each file the address of the system which offers holds it. This prevents the expense of sending a large volume of files to mirror sites, but requires that the user call direct to the system offering the file they want. Broadly similar to this is the common procedure of allowing systems to post a new files list into the echo, for areas pertaining to the echo subject. Another idea is to offer some sort of brief journal or electronic magazine for echo users. A vast array of ideas for the content of this journal can be created by the imaginative mind, or it could merely be a collection of material related to other ideas already given, such as file lists, information and news from external sources, echo user directories, or just about anything related to the echo topic. Where echoes of limited distribution exist, or similar echoes in different languages, links could be established for the sharing of information and news. This is especially useful where international links for an echo itself cannot be found. Given suitable software at two designated systems, selected messages and announcments could be sent between the echoes via netmail, to be automatically posted as an echomail message. Obviously this should only be used for a limited amount of traffic in order that uplinks are not annoyed with excessive traffic in netmail. Some of these less widespread activities could be conducted by echo participants other than the moderator, but in most cases it is up to the moderator to instigate them, or to specifically designate someone else to do the job, or just to make it known that they would be welcome in the echo. Most of the material here I have written in order to highlight the lighter side of what moderating an echo is all about, or what it could be about if moderators are willing, and hopefully I have managed to convince someone of the fact that there is more to moderating echomail than warnings and feed cuts. Such considerations should not be forgotten when formulating a policy for an echomail distribution system such as an official or unofficial backbone, a large-scale cost share scheme or an entirely separate network. It is important not only that rules and regulations do not restrain moderators and users from making the most of their echoes, but also that the incentive is there for people to put the effort in to implement some of the more interesting ideas for attracting and retaining users in our echoes. FIDONEWS 13-46 Page 6 11 Nov 1996 (Note for those who are interested: the author is the moderator and creator of three echoes: STRATEGY, CLASSICAL_UK and INFOMAIL, and is the creator of a fourth echo BBS-GAMES). ----------------------------------------------------------------- FTS-0004 documents a fish more than it does Echomail... by Lee Kindness, 2:259/7, lkindnes@csl.co.uk In this issue of Fidonews Chris will be posting FTS-0004, the document that specifies Echomail. It is the FTSC's statement that they only document current practise - read thru FTS-0004 and my comments on it last week and you'll see this simply isn't true. The worse thing is that the FTSC were submitted a proposed replacement for fts-0004 (fsc-0074) by John Souvestre and in their great wisdom not only altered the document before accepting it as an FSC but also didn't replace fts-0004 with it. I mean, look at fts-0004 it isn't even a technical document! I have included a recent draft i have made of fsc-0074 below. Additions and changes from the current fsc-0074 are marked by a '|' in the first column. Deletions from the current version are discussed after the document. === Proposed FTS-0004 replacement, FSC-0074.002 (draft) ============== Document: FSC-0074 Version: 002 (draft) Author: John Souvestre, David Troendle, Bob Davis, George Peace, Lee Kindness FTS: FTS-0004.002 -- proposed replacement EchoMail Specification June, 1992 This document began as the Conference Mail System User Manual By Bob Hartman t/a Spark Software FidoNet(tm) node 132/101 (currently 1:104/501) Used with permission 06 Jun 1991 John Souvestre, David Troendle, Bob Davis 29 Oct 1991 John Souvestre, David Troendle 28 Jan 1992 George Peace 02 Jun 1992 George Peace Nov 1996 FIDONEWS 13-46 Page 7 11 Nov 1996 Lee Kindness (| marks changes) ECHOMAIL DEFINED EchoMail is a technique that permits several nodes on a network to share a message base. It is similar in concept to the conferences available on commercial information services but is most closely related to the Usenet system consisting of thousands of systems world wide. All systems sharing a given conference see any messages entered into the conference by any of the participating systems. This can be implemented in such a way as to be totally transparent to the users of a particular system. In fact, they may not even be aware of the network being used to move their messages about from node to node! Unfortunately, EchoMail has disadvantages as well. Many users who are not educated about EchoMail systems do not realize the messages transmitted cost MANY sysops (system operators) money, not just the local sysop. This is an important consideration in EchoMail and should not be taken lightly. In a conference with 100 systems participating the cost per message can be quite high. BRIEF HISTORY OF ECHOMAIL In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a convenient means of sharing ideas with the other Dallas sysops. He created a system of programs he called Echomail, and the Dallas sysops' Conference was born. Within a short time sysops in other areas began hearing of this marvelous new gadget and EchoMail took on a life of its own. Today the FidoNet public network boasts a myriad of conferences varying in size from a handful of participants to Sysop conferences with hundreds of participants. It is not uncommon for a system to carry hundreds or more conferences and share those conferences with 10 or more nodes. HOW ECHOMAIL WORKS Today's EchoMail processing is functionally compatible with the original EchoMail utilities. In general, the process is: - A message is entered into a designated area on a FidoNet compatible system. - This message is "Exported" along with some 'control information' to each system "linked" to the conference through the originating system. - Each receiving system "Imports" the message into the proper Conference Mail area. - The receiving systems then "Export" these messages, along FIDONEWS 13-46 Page 8 11 Nov 1996 with additional control information, to each of their own EchoMail links. - Return to the import step. The method is quite simple in general. Of course, following the steps literally means messages would never stop being Exported and transmitted to other systems. This obviously would not be desired. The information contained in the 'control information' section is used to prevent exporting the same message more than once to a single system. MESSAGE CONTROL INFORMATION Control information is associated with each EchoMail message. This information consists of certain special lines placed inside the message. These lines are typically inserted automatically by the program which prepares or processes the message, not by the person writing it. In FTS-0001 terminology, these control information lines shall be inside the "text" field of a "packed message". Control information lines shall contain only ASCII characters, from 32 to 126, except the first character of the path line and as noted elsewhere in this document. This limitation applies only to control information lines. Alphabetic characters in required literal strings (AREA, Origin, SEEN-BY, and PATH) are case-sensitive. All control information lines shall be terminated with ASCII character 13 (carriage return). These required control information lines determine how EchoMail is handled: | The origin line, seenby and path are generated in that order, with | no other control information intermingled. 1. Area line There shall be exactly one area line in an exported message. The AREA line: - Shall be the first line of the text and thus shall immediately follow the packed message header. This position is "offset 0" of the "text" portion of the packed message. - Shall be formatted as: AREA:CONFERENCE FIDONEWS 13-46 Page 9 11 Nov 1996 AREA: is a required five character upper case literal. | There is NO space between AREA: and CONFERENCE CONFERENCE is the name of the conference. The conference name is composed of ASCII characters in the range 33 to 96 and 123 to 126. The conference name shall be no more than 60 characters in length. The AREA line is added when a conference is "Exported" to | other systems. It is usually based upon information found in a configuration file for the designated message area. This field is used by receiving systems to "Import" messages into the correct EchoMail area. Some implementations insert a Ctrl-A (0x01) immediately | preceding the AREA: literal (^AAREA:CONFERENCE). This is broken | behavior but should be handled, but never created. A warning | message to the node who created the message can, optionally, | be sent. 2. Origin Line There shall be exactly one origin line in a message. It shall | be placed in the message directly after the user text and | immediately before the remaining control information lines. The origin line: - Shall begin with the eleven character literal: *Origin: - Is optionally followed by user/system defined data in the ASCII range 32 to 126. - Shall end with a FidoNet network address enclosed in parenthesis: ([:]/[.][@]) - Shall be no more than 79 characters long including the required lead-in and address information. - Shall be inserted into the message at the originating system. The complete line might look like: * Origin: Conference Mail BBS (1:132/101) 3. Seen-by Lines FIDONEWS 13-46 Page 10 11 Nov 1996 Seen-by lines are the focus of EchoMail distribution control information. They are used to determine which addresses (systems) have received messages. There can be as many seen-by lines as required to store the necessary information. Seen-by lines consist of "SEEN-BY:", followed by a list of net/node numbers corresponding to the systems which have received that message. The net/node number of each system to which a message is exported is added to the seen-by lines at the time of export. There shall be exactly one set of seen-by lines in a message. Seen-by lines: - Shall follow the origin line. - Shall begin with the nine character literal: SEEN-BY: - Shall contain a list of net/node numbers. - Shall be no more than 80 characters long including the required literal. The complete lines might look like: SEEN-BY: 104/1 501 132/101 113 136/601 1014/1 SEEN-BY: 1014/2 3 The list of net/node numbers: - Shall identify at least one address. "Blank" seen-by lines shall not be transmitted. - Shall be sorted in ascending net/node order. - Shall not contain repeated node numbers. - Shall use only "2D" net/node notation. | - Shall be stripped at zone gates (since the data is 2D). | In essence when a system imports an echo from a system | in another zone it will dispose of all SEEN-BY lines | in the message and replace it with a single SEEN-BY | that contains their net/node. - May use short form address notation where a net number is listed once on any one line. These 2 lines are equivalent: SEEN-BY: 104/1 104/501 132/101 132/113 136/601 SEEN-BY: 104/1 501 132/101 113 136/601 | The first entry in a line must be full net/node. Some implementations insert a Ctrl-A (0x01) immediately FIDONEWS 13-46 Page 11 11 Nov 1996 | preceding the SEEN-BY: literal (^ASEEN-BY:). This is broken | behavior but should be handled, but never created. A warning | message to the node who created the message can, optionally, | be sent. 4. Path Lines Path lines identify a list of net/node numbers that processed a message before it reached the current system. There can be as many path lines as required to store the necessary information. This is different from seen-by lines, in that seen-by lines list list all systems to which the message has been sent while path lines list the systems which have processed the message. There shall be exactly one set of path lines in a message. Path lines: - Shall follow seen-by lines. - Shall be the last line(s) in the text field of a packed message. - Shall begin with the seven character literal: ^APATH: The ^A is a special character which stands for Control-A (ASCII character 1), and is required at the beginning of each path line. - Shall contain a list of net/node numbers. - Shall be no more than 80 characters long including the required literal. The complete path line might look like: ^APATH: 132/101 1014/1 The list of net/node numbers: - Shall identify at least one net/node number. "Blank" path lines shall not be transmitted. - Shall not be sorted. They shall remain in the order representing the actual "path" along which the message traveled. - Shall use only "2D" net/node notation. - Shall begin with the net/node of the originating system. - Shall not be deleted during processing. The original path information shall be maintained from origin to final FIDONEWS 13-46 Page 12 11 Nov 1996 destination. ECHOMAIL TOPOLOGY The way in which systems link together for a particular conference is called the "EchoMail Topology." It is important to know this structure for two reasons: - It is important to have a topology which is efficient in the transfer of the EchoMail messages. - It is important to have a topology which will not cause systems to see the same messages more than once. Efficiency can be measured in a number of ways: - Least time involved for all systems to receive a message - Least cost for all systems to receive a message - Fewest phone calls required for all systems to receive a message. Users of EchoMail systems have determined (through trial and error) the best measure of efficiency to be a combination of all three measurements. Balancing the equation is not trivial, but some guidelines can be offered: - Have nodes form "stars" for distribution of EchoMail. This arrangement has several nodes all receiving their EchoMail from the same system. In general the systems on the "outside" of the star poll the system on the "inside". The system on the "inside" in turn polls other systems in a similar star configuration to receive the EchoMail that is being passed on to the "outside" systems. - Utilize fully connected polygons with few vertices. Nodes can be connected in a triangle (A sends to B and C, B sends to A and C, C sends to A and B) or a fully connected square (all corners of the square send to all of the other corners). This method is useful for getting EchoMail messages to each node as quickly as possible. All of these efficiency guidelines have to be tempered with the guidelines dealing with keeping duplicate messages from being exported. Duplicates will occur in any topology that forms a closed polygon that is not fully connected. Take for example the following configuration: A ----- B | | | | C ----- D FIDONEWS 13-46 Page 13 11 Nov 1996 This square is a closed polygon that is not fully connected. It is capable of generating duplicates: 1. A message is entered on node A. 2. Node A exports the message to node B and node C placing the seen-by for A, B, and C in the message as it does so. 3. Node B sees that node D is not listed in the seen-by and exports the message to node D. 4. Node C sees that node D is not listed in the seen-by and exports the message to node D. At this point node D has received the same message twice - a duplicate was generated. Normally a "dup-ring" will not be as simple as a square. Generally it will be caused by a system on one end of a long chain accidentally connecting to a system on the other end of the chain. This causes the two ends of the chain to become connected, forming a polygon. In FidoNet this problem is reduced somewhat by having a regional EchoMail star distribution architecture that maintains EchoMail connections within regions of the world. Within that architecture only a small number of prearranged systems (regional collection systems) make inter-regional connections. This architecture, along with multiple daily connections, results in an efficient topology which typically allows global distribution within 24 hours. THE PATH LINE AND TOPOLOGY The PATH line stores the net/node numbers of each system having actually processed a message. This information is useful in correcting the biggest problem encountered by nodes running an Echomail compatible system - the problem of finding the cause of duplicate messages. How does the PATH line help solve this problem? Take the following path line as an example: ^APATH: 107/6 107/312 132/101 This shows that the message was processed by system 107/6 and transferred to system 107/312. It further shows system 107/312 transferred the message to 132/101, and 132/101 processed it again. Here's another example: ^APATH: 107/6 107/312 107/528 107/312 132/101 This shows the message having been processed by node 107/312 on more than one occasion. Based upon the earlier description of the 'information control' fields in Echomail messages, this identifies an error in processing. This further shows node 107/528 as the node which apparently processed the message incorrectly. In this case the path line can be used to help locate the source of duplicate FIDONEWS 13-46 Page 14 11 Nov 1996 messages or topology problems. In a conference with many participants it becomes almost impossible to determine the exact topology used. In these cases the use of the path line can help a moderator or distributor of a conference track any possible breakdowns in the overall topology, while not substantially increasing the amount of information transmitted. Having this small amount of information added to each message pays for itself very quickly when it can be used to help detect a topology problem causing duplicate messages to be transmitted to each system. === End ============================================================== Sections deleted from the current version of fsc-0074: < Six months after adoption of this document the ^AAREA: format < shall be processed equally with the AREA: format when either < occurs in received packets. Replaced with: > | preceding the AREA: literal (^AAREA:CONFERENCE). This is broken > | behavior but should be handled, but never created. A warning > | message to the node who created the message can, optionally, > | be sent. and... < Six months after adoption of this document the ^ASEEN-BY: < format shall be processed equally with the SEEN-BY: format < when either occurs in received packets. Replaced with: > | preceding the SEEN-BY: literal (^ASEEN-BY:). This is broken > | behavior but should be handled, but never created. A warning > | message to the node who created the message can, optionally, > | be sent. The nonsense replaced was added to the original submitted version of fsc-0074 BY THE FTSC! This is the same FTSC that 'only documents current practise, not improvements' Some more information for the FTSC to mull over... ----------------------------------------------------------------- For immediate release to FidoNews: First of all, I apologize if I have mislead anyone about U'NI-Net. I have not actually *tried* U'NI-Net since there is no system on that network local to me. I merely chose UN'I-Net as an example of another network like Intelec that has much stricter rules than FidoNet. The one thing I do have to add is that Cam DeBuck is a moderator on FIDONEWS 13-46 Page 15 11 Nov 1996 Intelec, so it's obvious where her ideas about a BBS network come from. Enough said on that subject. Now for the topic at hand. FidoNet *is* suffering crushing blows from the Internet. If we intend to survive as a network, we have to appeal to netizens. This might start with a World Wide Web site. I have not seen www.fidonet.org, because for some reason I kept getting an error message that the server was not responding...(this could be the fault of the ISP, though) This article is an open letter, and a call for action. We need software that's easier to use. Your typical FidoNet connection software requires understanding obscure concepts like FOSSIL drivers and nodelists and so forth. As much as possible needs to be shielded from the end user and there needs to be ONE software package to do it all. A FidoNet BBS or point node needs separate components from various vendors: a FOSSIL driver, a front-end mailer, mail reading software (or the BBS software itself), a mail tosser (one for Fido .PKTs and one for .QWKs for some setups), a nodelist, a nodelist compiler, a nodediff compiler, an offline mail reader door for some BBSes, etc. The closest approximation to a "complete" FidoNet point setup, for instance, is Terminate 4.0. It includes a FidoNet-compatible mailer, mail reader, mail tosser (both QWK and PKT), terminal program, internal communications drivers (obviating the need for FOSSILs except for a few with ISDN, or other non-standard setups), etc. We're in the age of GUI, folks! We need to settle on a standard for GUIs on a BBS, and make all-inclusive packages like Terminate for end-users, and better setups for people to start BBSes (WildCat! 5 is a start...) We need to emphasize FidoNet's quality of messaging content. The fact that we have Moderators and newsgroups are not usually moderated matters. We need more echos that cross FidoNet <-> Usenet boundaries but have their roots in FidoNet (there's at least one I'm aware of). We need to emphasize that FidoNet can offer all of the functionality of Usenet without the anarchy and chaos that exist on Usenet. Besides porting FidoNet to Usenet, another idea might involve porting FidoNet conferences into Internet mailing lists, or making them available on the WWW. Advertising ourselves on the Web is just as important... Like I said, I haven't seen www.fidonet.org (if it even exists), but advertising is key. Getting the message out that FidoNet is out there, and is a completely viable alternative to the Usenet is the key to FidoNet's survival. So, software authors, users, SysOps, coordinators, UNITE! There is much work to be done, and we should stop squandering time with all the political in-fighting. If we don't, FidoNet's days are numbered. Rob A. Shinn @ 1:2410/116, ----------------------------------------------------------------- Atari-related Echos in Fidonet FIDONEWS 13-46 Page 16 11 Nov 1996 by Troy H. Cheek, 1:362/708.4 According to Peter E. Popovich (1:363/264) and his Latest Greatest Software Versions list, Atari ST/TT software is slated to be phased out this week. I hope that the information I mailed him yesterday will change that to "_was_ slated..." Given the number of people still using such software (judging by origin and tear lines seen in various echoes), I simply assumed someone more qualified than I am would have already given Peter all the information he needed to know. Shows us what we get when we assume, doesn't it? :-) If you or someone you know is using an Atari computer to access Fidonet, or simply has an interest in Atari in general, please note the following Fidonet echomail conferences: Tag: ATARI_ST Mod: Troy Cheek, 1:362/708.4 Dist: Z1-Backbone ATARI_ST covers the Atari ST and every Atari computer since (Mega ST, STe, Mega STe, TT, Falcon, Medusa, etc). It also covers the Lynx and Jaguar game machines. Tag: ST_PROG Mod: Rodney Rudd, 1:138/34 Dist: Z1-Backbone ST_PROG originally covered only the programming of the Atari ST and later computers, but later expanded to include the game machines as well. More recently, it has expanded to include programming of all things Atari. Tag: ATARI Mod: Larry Black, 1:3608/121 Dist: Z1-Backbone ATARI covers all Atari products based on the 6502 microprocessor such as the Atari 400/800, 600XL/800XL/1200XL, 65XE/XEGS/130XE, etc. The moderator enforces this restriction rather strictly. Tag: VID_GAME Mod: Troy Cheek, 1:362/708.4 Dist: Z1-Backbone VID_GAME is dedicated to home videogames in general, including the Atari 2600, 5200, 7800, Panther, Lynx, and Jaguar. Please note that ALL of these echoes are active, listed in the Echolist, and are distributed on the backbone. For some reason, people seeking these echoes have been told this is not the case. -- |Fidonet: Troy H. Cheek 1:362/708.4 |Internet: 362-708-4!Troy.H..Cheek@river.chattanooga.net | | Standard disclaimer: The views of this user are strictly his own. | River Canyon Rd. BBS <=> Chattanooga OnLine! Gateway to the World. FIDONEWS 13-46 Page 17 11 Nov 1996 ----------------------------------------------------------------- FIDONEWS 13-46 Page 18 11 Nov 1996 ================================================================= GETTING TECHNICAL ================================================================= [This is the second in the FidoNet Technical Standards list. FTS-0002 and FTS-0003 were obsoleted by other Standards. This standard has been reformatted to meet the 70 column requirement of MAKENEWS and is part of a continuing series of FidoNet History.] Ed. FTS-0004 EchoMail Specification This document is directly derived from the documentation of ---------------------------------------------------------------------- The Conference Mail System By Bob Hartman Sysop of FidoNet(tm) node 132/101 (C) Copyright 1986,87, Spark Software, Inc. 427-3 Amherst Street CS 2032, Suite 232 Nashua, N.H. 03061 ALL RIGHTS RESERVED. ---------------------------------------------------------------------- version 3.31 of 12 December, 1987. With Bob Hartman's kind consent, copying for the purpose of technological research and advancement is allowed. ---------------------------------------------------------------------- ---------------------------------------------------------------------- WHAT IS THE CONFERENCE MAIL SYSTEM?