Volume 6, Number 15 10 April 1989 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Copyright 1989 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article will be rejected which is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 Reflections on the Anarchist Principle ................... 1 Daisy, The Apple CP/M BBS ................................ 10 Groupmail and Confmail replacement released .............. 15 VETNet is ALIVE!!!!! ..................................... 20 2. COLUMNS .................................................. 27 The Veterinarian's Corner: Vaccinations .................. 27 When the Topicops Came Calling ........................... 28 3. LATEST VERSIONS .......................................... 35 Latest Software Versions ................................. 35 And more! FidoNews 6-15 Page 1 10 Apr 1989 ================================================================= ARTICLES ================================================================= Tom Jennings 1:125/111 The following is the opening essay in "THE BLACK FLAG OF ANARCHISM AND OTHER ESSAYS", available from Employee Theft Press, ($2.50 from 1369 Haight St, San Francisco CA 94117) -- all funds from the sale of this pamphlet go to "WITHOUT BORDERS ANARCHIST CONFERENCE & FESTIVAL", to be held in San Francisco this July 20 - 25. Reflections on the Anarchist Principle by Paul Goodman "Anarchism is grounded in a rather definite proposition: that valuable behavior occurs only by the free and direct response of individuals or voluntary groups to the conditions presented by the historical environment. It claims that in most human affairs, whether political, economic, military, religious, moral, pedagogic, or cultural, more harm than good results from coercion, top-down direction, central authority, bureaucracy, jails, conscription, states, pre-ordained standardization, excessive planning, etc. Anarchists want to increase intrinsic functioning and diminish extrinsic power. This is a social- psychological hypothesis with obvious political implications. "Depending on varying historical conditions that present various threats to the anarchist principle, anarchists have laid their emphasis in varying places: sometimes agrarian, sometimes free- city and guild-oriented; sometimes technological, sometimes anti- technological; sometimes Communist, sometimes affirming property; sometimes individual, sometimes collective; sometimes speaking of Liberty as an almost absolute good, sometimes relying on custom and 'nature'. Nevertheless, despite these differences, anarchists seldom fail to recognize each other, and they do not consider the differences to be incompatibilities. Consider a crucial modern problem, violence. Guerrilla fighting has been a classical anarchist technique; yet, especially where, in modern conditions, *any* violent means tends to reinforce centralism and authoritarianism, anarchists have tended to see the beauty of non-violence. "Now the anarchist principle is by and large true(1). And far from being 'utopian' or a 'glorious failure', it has proved itself and won out in many spectacular historical crises. In the period of mercantilism and patents royal, free enterprise by joint stock companies were anarchist. The Jeffersonian bill of rights were anarchist. Progressive education was anarchist. The free cities and corporate law in the feudal system were anarchist. At present, the civil rights movement in the United States has been almost classically decentralist and anarchist. And so forth, down to details like free access in public libraries. Of course, to later historians these things do not seem to be anarchist, but in their FidoNews 6-15 Page 2 10 Apr 1989 own time they were regarded as such and often literally called such, with the usual dire threats of chaos. But this relativity of the anarchist principle to the actual situation is of the essence of anarchism. There *cannot* be a history of anarchism in the sense of establishing a permanent state of things 'anarchist'. It is always a continual coping with the next situation, and a vigilance to make sure that past freedoms are not lost and do not turn into the opposite, as free enterprise turned into wage-slavery and monopoly capitalism, or the independent judiciary turned into a monopoly of courts, cops, and lawyers, or free education turned into School Systems." Footnote(1) "I, and Other anarchists, would except certain states of temporary emergency, is we can be confident that the emergency is *temporary*. We might except certain simplistic logistic arrangements, like ticketing or metric standards or tax- collection, if we can be confident that the administration, the 'secretariat', will not begin to run the show. And we might except certain 'natural monopolies', like epidemic control, water-supply, etc." First published in ANARCHY 62 (April 1966) ----------------------------------------------------------------- FidoNews 6-15 Page 3 10 Apr 1989 Gateways to and from FidoNet Technical, Administrative, and Policy Considerations Randy Bush 3 April 89 Copyright 1989, Randy Bush. All rights reserved. The right to distribute for non-commercial use is granted to FidoNews. What is a Gateway to/from FidoNet? ---- -- - ------- ------- -------- A gateway is a collection of software and procedures whereby net mail and/or echomail may be transferred between FidoNet and another computer communications network. Gateways are bi-directional, as folk always want to reply to others' mail. Gateways exist now. o There are a number of software packages for gating between uucp-based systems and FidoNet, the most well-known being the UFGATE shareware package. These packages gate both net mail and echomail, and are often used to provide FidoNet access to/from Internet via the uucp network. These tend to go through much effort to make FidoNet look as much like Internet as possible. About 25 uucp gateways are scattered around FidoNet. o Rhodes University has developed a complete system between a Cyber-based NOS network and FidoNet. This system handles both net mail and echomail, and is also strongly based on the Internet standards, and almost views FidoNet as a transport mechanism to get to/from Internet. It is used to gate a fairly localized cluster of mainframes to FidoNet at a single point, and has made special arrangements for further routing and forwarding of mail. o WWIVnet has developed gating software based on the ForDog package for the MS-DOS-based WWIV systems, and some other package for the Mac-based Tabby systems. The MS-DOS system uses Binkley or another FidoNet mailer handles the protocol transfers to make the WWIV system look like a FidoNet system to other FidoNet nodes. WWIVnet gates are said to be scattered around the US and Canada. o A number of FidoNet-based systems have been developed for various flavors of UN*X. These vary from encapsulated Fido- worlds within UN*X (i.e not true gates at all), to FidoNet front ends for UN*X mail systems. o RBBS-net seems to have developed gateway software for the MS-DOS-based BBS network, but I do not know enough to characterize it. All of these gateway systems can and are being run in a safe and FidoNews 6-15 Page 4 10 Apr 1989 cooperative fashion, and are providing a nice cross-cultural exchange with benefits for both sides of the gates. At this time, there are also other nets which, because they are based on technology similar to FidoNet, are dumping mail onto and taking mail off of FidoNet willy nilly, with little thought to the technical, administrative, or social consequences. Often, this is done with good intentions, not realizing they are providing a disservice to both nets. What are the Characteristics of a Good Gateway? ---- --- --- --------------- -- - ---- -------- Like good contracts, good gateways should be fair to both sides. There is the need to preserve both the technical and sociopolitical integrity of all parties to the transaction. Technically, both networks will have specifications and requirements for transfer protocols, message and echomail formats, control data files, etc. Beyond the borders of the gateway software, each universe should be completely and safely maintained. o Messages and echomail should completely conform in format and content to the technical specifications of each side of the gateway. o Addressing of messages and echomail should completely conform to that of the network in or through which the messages are traveling or resident at all times. o A normal user should be able to enter new messages destined for the other side of the gate and to reply to gated mail with relative ease. o If FidoNet uses a network A as an intermediate to get to/from a network B, or if network C uses FidoNet to get to/from network D, then the inter-net transitions should be auditable, but local customs and technalia of the intermediate network may not need always be enforced. Socially, the customs and fashions of each network should be maintained in that network. o There must be administrative liaison and control between the two networks so agreements may be made and enforced and disputes may be adjudicated. o If the networks being gated overlap geographically, then systems should not have to pay significant costs to move mail between the two networks when it is between two nodes that are in the same general locale. o Gating is not simple, technically or administratively. Unless each net anticipates significant use of the gateways, and the anticipated gain is seen as greater than the FidoNews 6-15 Page 5 10 Apr 1989 anticipated pain, then one side or the other may reasonably decline to do the necessary work. What Technical Standards Exist? ---- --------- --------- ------ Before we develop new specifications, social protocols, and standards, we should see what exists already. o FidoNet Technical Standards exist already for the data formats and the communication protocols for net mail and echomail. All conforming gateway systems mentioned above conform to these standards. These are named FSC-nnnn, or more recently FTS-nnnn. o The SRI-NIC has published standards for message formats and communication protocols that are used between a significant number of networks that already gate to each other. These are often referred to as the Internet standards and named RFCnnnn or IDEAnnnn. o The ISO and CCITT have standards for message formats and communication protocols which are used between a significant number of systems. These are based on X.nnn specifications, eg. X.400. Other standards undoubtedly exist and should be investigated by anyone desiring to build a gateway system. The game of 'my standard is better than yours' has been played for decades with no conclusion other then demonstrating the stupidity of war. What matters is that each net's standards are maintained within that net. What Administrative Standards Exist? ---- -------------- --------- ------ Most networks have formed administrative procedures and guidelines which regulate if and how other networks may gate to/from them. The most notable exception is the uucp/Usenet which, having no formalized administrative rules for anything else, imposes none on gateways. Before we recoil in horror, note that uucp/Usenet is three to four times the size of FidoNet, is over twice FidoNet's age, and has a significantly better signal- to-noise ratio. The SRI-NIC provides a procedure for registering Internet domains. A domain is somewhat like what we are considering a network. This Internet registration procedure ensures that the network has o administrative responsibility and control, and o at least two registered sites which provide address mapping FidoNews 6-15 Page 6 10 Apr 1989 for the network being gated. FidoNet is a registered domain of Internet. Our domain is called fidonet.org. The administrative responsibility is the FidoNet IC's. The registered 'nameservers' are at lynx.cs.orst.edu and k9.cs.orst.edu, both at Oregon State University, though this is bending the two nameserver policy a bit. DECNET, ARPANET, ... all have applicable standards, but, as they are strictly limited to formal commercial relationships, they are of little interest here. What Administrative Policies are Needed by FidoNet? ---- -------------- -------- --- ------ -- -------- What does FidoNet really need to state in terms of administrative requirements on a network wishing to gate to/from FidoNet? FidoNet needs a means of ensuring that a formal relationship exists which may be used to negotiate technical standards between the two nets, internet adjudication of disagreements both technical and social, and enforcement of decisions. Similarly, the other network will likely want such assurances as well. Therefore an agreement should be reached stating: o who is administratively responsible, o who is technically responsible, o what technical and administrative documentation exists, and o both parties will abide by eachother's rules when in the other's house, and o how grievances are to be stated and adjudicated. In addition, it will be advisable for FidoNet to place some requirements on a network wishing to form official gateways. Some of these requirements and their motivations are: o If the other network geographically overlaps a significant portion of FidoNet, then the other net should be of sufficient size that gateways can likely be recruited in most areas where the nets overlap. Thus, systems should not have to pay significant costs to move mail between two nets that happen to be in the same locale. o If the other network geographically overlaps a significant portion of FidoNet, then there should, at a minimum, be gateways in each FidoNet zone where they overlap. o If the other network geographically overlaps more than one zone of FidoNet, then that net should have its own gateways between the zones, and not use FidoNet to move the burden of interzone PTT costs. FidoNews 6-15 Page 7 10 Apr 1989 o If the other network geographically overlaps a significant number of the regions in a FidoNet zone, then there should, at a minimum, be gateways in each FidoNet region where they overlap. o If the other network is geographically localized, then special arrangements may be made whereby there traffic is gated to/from FidoNet at one or more places by special arrangement as if the other network were a FidoNet node or local network (in the intra-FidoNet sense) itself. o Gating of net mail, i.e. user-to-user messages, must be implemented and easily used. Gating of Echomail is optional. o Mail must be bi-directional. If someone in the other net can send mail to a node/user on FidoNet, then that FidoNet node/user must be able to reply. o If echomail is gated, then, unless special circumstances are recognized by the responsible administrators, it must be gated bi-directionally. o If a conference is moderated (in the Usenet sense, similar to Dutchie's Conference Mail's moderation or GroupMail) on one network, then it should be moderated on all other networks, or at least the gateway into the network where it is moderated should ensure that correct moderation is done by forwarding or whatever is appropriate. For inter-net gateway systems in the process of formation, it is assumed that some of the above requirements may be waived during a startup period at the discretion of the administrative bodies. Observe that if FidoNet were to try to take a shortcut which has been suggested and simply require Intetnet registration of gating networks, then, of the current networks gating to FidoNet correctly (see above), only the Rhodes system could conform technically. Eg. the uucp gating packages gate to uucp which has no administrative center and is not registered with Internet. To require Internet registration would further neither the goals of Internet, nets wishing to gate to FidoNet, nor FidoNet itself. What Technical Requirements should FidoNet Place on Gating Systems? ---- --------- ------------ ------ ------- ----- -- ------ -------- Each network will have its own specifications for communication protocols, data formats, message conventions, addressing, etc. Though more generally used standards are to be preferred, what really matters is that each net be self- consistent and integritous and that gateway systems maintain that integrity. From the FidoNet perspective, the following attributes of a gateway system seem to be mandatory. FidoNews 6-15 Page 8 10 Apr 1989 o Conformance to FidoNet message format as specified in current FidoNet technical standards (eg. currently FSC-0001) must be maintained while messages are within FidoNet. o Information to assist message comprehension and processing by gateway systems and/or other networks may be contained within the message body, either hidden behind ^A lines or not. If such information is needed, then conformance to current Internet standards (eg. currently RFC822) is recommended. o The FidoNet message header must contain valid FidoNet addresses at all times the message is on FidoNet. Valid FidoNet addresses are addresses of specific FidoNet nodes in the current FidoNet nodelist. o The source and/or destination address in the other net should be embedded in the text body of the FidoNet message, either hidden behind ^A lines or not. Conformance to current Internet standards is recommended where appropriate, but addressing conventions in the other net may preclude this. o A message must contain sufficient information that the originating system and user may be easily determined. o A FidoNet sysop and/or normal FidoNet BBS user should be able to enter messages destined for users in the other network and reply to gated mail using current FidoNet software. o If echomail is gated, then the echo messages should conform to all current FidoNet standards for echomail. For example, currently an echomail message should: - have a correct tear line - have an origin line of the proper format with a FidoNet origin of the gating FidoNet node - have seenbys of only FidoNet nodes - have a path line that goes back at least to the gating node o If echomail is gated, then an echomail message must contain sufficient information that the system and user of origin may be trivially determined, whatever net may have originated it. o The origin of gated echomail should be determinable in a regular way sufficient that the gating software can provide easy construction of private net mail replies to echomail messages which would return to the echo messages's originator through the appropriate gateway, which may or may not be different than the gateway through which the echo message came. It is acknowledged that this may require hand editing on the part of the user composing the reply. o If echomail is gated, and the other net has no equivalent, it may use net mail and/or net mail mailing lists. Messages coming into FidoNet from this type of net mail or mailing FidoNews 6-15 Page 9 10 Apr 1989 list should properly gate into the appropriate echomail conference, and replies should work correctly as well. Conclusion ---------- It is hoped that, given a philosophy and guidelines such as those outlined in this paper, FidoNet will continue to expand its links to other networks to the benefit of FidoNet and networking in general. It is hoped that this paper will be of some help to those constructing gateways to/from FidoNet, and to the administrators of FidoNet and other nets who are considering gating to/from FidoNet. This paper, the purported facts contained, and the philosophy espoused are the sole responsibility of the author, and are quite likely technically incorrect and are undoubtedly morally bankrupt. Should you have constructive correction or criticism, please contact: Randy Bush FidoNet: 1:105/6 1:105/42 randy@dawggon.fidonet.org uucp: { mcvax!uunet, tektronix }!oresoft!dawggon!randy Internet: randy@oresoft.uu.net randy@m2xenix.uucp Telemail: RBush FAX: +1 (503) 245-8449 TWX 910-464-4779 ---------- FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe much thanks for the origin and spirit of FidoNet. DECNET is a trademark of Digital Equipment Corporation. MS-DOS is a trademark of Microsoft Corporation. -30- ----------------------------------------------------------------- FidoNews 6-15 Page 10 10 Apr 1989 Raymond Lowe 3:700/13 D A I S Y THE Apple CP/M Bulletin Board System * * * It seems that there have recently been quite a few queries in the net about Daisy, the Apple II BBS of which I am the author, so for all those interested here are some details about Daisy. Daisy who? ---------- A couple of years ago I was talking to my friend Ken Lo about Bulletin Board Systems, and about how hard they were to write. This was not a surprising topic of conversation as we are both programmers, both BBS users and the conversation in question was via messages on one of the local RBBS. I thought that BBS were probably pretty hard to code, and were way beyond the capabilities of the Apple ][+ which was then my main computer (I've since moved up to a //e). Ken disagreed, he thought it wouldn't be that hard to produce a BBS. So after some discussion we decided to attempt the development of what we referred to at the time as an "Apple Fido". We decided to use Apple CP/M and Turbo Pascal v2 for the development as these were the most advanced systems available to both of us. With Ken working on the low level serial card drivers, we found it necessary to drive the UART directly using memory mapped registers, and me on the high level code it wasn't long before the first Daisy was running. You can well believe that the first call I received using Daisy was quite a thrill for me. Even if a major bug did mean that every character the user entered was displayed on a separate line. That, and many other bugs, were soon found and fixed - it wasn't long before the very first version of Daisy was released. Of course it was some time before anyone actually USED Daisy to run a regular BBS. But the thrill of coding and debugging kept us happy as we quickly developed a whole range of features for the system. FidoNews 6-15 Page 11 10 Apr 1989 Though it started off as a deliberate backward engineering of Fido Daisy soon took on a life and character of its own. Today Daisy includes many features seen in Fido, Opus and other BBS together with quite a few features all of its own. For Users --------- From the point of view of a remote user the overall look-and-feel is very much that of Opus or Fido. Most of the commands they are already familiar with will work as they expect, and they can use the system just fine without ever learning anything about the Daisy specific features. This only applies to users though; Sysops will find Daisy rather different from what they may have seen before. As I had never seen any BBS from the Sysop side when I started writing Daisy I had to design everything from scratch. For Sysops ---------- The first level of Sysop control is through a point-and-press interface available all the time the system is waiting for callers. This gives options such as "Start local session", "Edit user list", "Event" and the "Terminal mode"; though not all are available while a remote user is on-line. During a session, be it from the local console or remotely via modem, an on-line Sysop menu gives high-level users access to another level of commands used to control message areas, message renumber, access privilege levels, multiple bulletins and similar things. At the most detailed level all basic configuration information, detailing which drives are to be used and so on, is controlled by a text file which can be created using any normal text editor. In fact all these configuration options are entirely optional, it is perfectly possible to run the BBS by just entering 'BBS' at the CP/M prompt and letting it run. The program automatically generates any files it really needs. Daisy Mailer ------------ Of course if you write a program on the basis of it being an "Apple Fido" pretty soon people start expecting it to be able to do FidoNet mail. Well after quite a lot of prodding I finally got around to starting on a mailer for Daisy. Working from the early Fidonet Technical Standards Committee documents I built up all the code I needed to automatically send message back and forth from Daisy to Fido and Opus systems. FidoNews 6-15 Page 12 10 Apr 1989 Now the Daisy Mailer is an optional extra which plugs into the BBS and does all the packing, calling, transferring and unpacking of messages. It handles type two mail packets, file attaches and routing perfectly. Echomail support is built-in and in the most recent versions can receive ARCmail. As Daisy is fully NetMail aware mail calls can be accepted at any time, so it qualifies for the #CM: continuous mail flag if correctly configured. Ah, but... ---------- Unfortunately there is one catch if you want to use Daisy for its FidoNet mail capability; the Mailer has not been tested by the FTSC and hence has not been 'validated' by them as being Net compatible. This means that officially a Daisy BBS cannot be assigned a node number in the nodelist. Of course this doesn't stop you from using it as a Point system, and I've used Daisy as a point without any problems, but if you want a regular node number you're out of luck. My early attempts to get the Mailer tested and validated were to no avail; not because it was tested and failed those tests, but rather because I could never get anyone to answer my messages requesting that it be tested. More recently, around the new year, I sent a full set of Daisy and the Mailer on floppies to an Apple user in the U.S. at the request of James Deibele who is apparently now responsible for 'foreign' mailers. As the Apple user in question is not a CP/M user I don't expect she'll get anywhere very fast (how soon do you think you'd be able to get Opus running if you were not a MS-DOS user and didn't even have a DOS bootable disk?) So the Daisy Mailer may or may not be tested and validated Real Soon Now. Despite all that if you have a friendly NC, as I have, you can probably get yourself hooked into the network for Echomail and such. Requirements ------------ To run Daisy you need the following: * An Apple ][ series computer or compatible FidoNews 6-15 Page 13 10 Apr 1989 * Z80 card and CP/M software * Super Serial Card or compatible serial communications device. * External 300/1200 or 2400 baud Hayes AT compatible modem. * Clock cards, either Time ][ or TimeMaster, are optional. * A large capacity RAM card configured as a ramdisk is recommended for running the BBS, it is considered essential for running the Mailer. * You'll also want as MUCH on-line disk storage as possible; floppies are okay but three would be better than two. Copyright --------- Daisy and its associated documentation and utilities are not PD, they are the copyrighted property of the authors. Free use and distribution is, however, permitted - and encouraged. The only restrictions are 1) you mustn't sell it (make money out of distributing it), 2) distribute modified versions without the authors permission. Getting Daisy ------------- The following Daisy files can be FileRequested from Electronic BBS, 3:700/18, 2400, 23 hours a day (not during NMH). DSY2-D.ARC 32940 02-11-89 Documents, manuals DSY2-X.ARC 35061 07-19-88 Extra files, help DSY2HTCS.ARC 57701 11-09-88 Daisy v2H for Time II, code DSY2HMCS.ARC 57872 11-09-88 Daisy v2H for Timemaster //, '' MSGUTL25.ARC 22793 01-03-89 Message utility v2.5 /w source PACKUSR4.ARC 12326 12-28-88 Pack user list v4 MLR034.ARC 40442 02-11-89 Mailer v0.34 NODECOMP.ARC 23311 02-11-89 Nodelist compiler SCHED0-5.ARC 13968 07-19-88 Scheduler v0.50, timed events FILER7.ARC 28110 01-06-89 Filer sub-system DSYST130.ARC 11131 09-04-88 Statistic program for Daisy DSY2G-S.ARC 89663 08-22-88 Source code of Daisy V2g The Daisy support echo, echo key DAISY, is also available from 3:700/18 or 3:700/0(Mail Gateway), it has quite a low turnover. The Daisy support board is Daisy Information Gateway 3:700/719(700), +852-3-765-6899, 1200 baud, 24 hours. You won't find this in your Nodelist for reasons as given above. FidoNews 6-15 Page 14 10 Apr 1989 ----------------------------------------------------------------- FidoNews 6-15 Page 15 10 Apr 1989 Dutchie Conference manager 2.91 released Henk Wevers 2:500/1 This week DCM, short for Dutchie Conference manager, has been released. DCM is a full replacement for the Confmail/PKARC combination and has optional many of the features of Groupmail without its drawbacks. DCM was the last program needed to complete the Dutchie software packet so no third party programs are needed for a complete mailer/editor/conferencemail setup. Although DCM is part of the Dutchie packet it can be used in cooperation with almost all other mailers available for FidoNet operation. Confmail replacement -------------------- DCM replaces confmail completely and even has a powerfull build in archive program so you do not need programs like PKARC/PKXARC or ARC for your conference setup. One relatively small program replaces all. In addition to the known Confmail features DCM offers a lot more in about 85 Kb. o Two control files Two control files tell DCM how to perform its tasks. As those files are already present in a Dutchie environment Dutchie users need no extra configuration files. o Smart tossing/scanning DCM will toss/scan in one run. This means that fewer diskaccesses have to be made. As the complete Dutchie package uses standard dosscalls that are a bit slower than some of the tricks confmail 4.0 plays (but less risky) the overall speed is about the same as that of Confmail. If you have a lot of 'passthru' conferences, DCM wins. o Smart Passthru conferences. If you pass some conferences without reading them DCM will never unpack the messages in those conferences into a local directory. You do not need a directory for these conferences. It speeds up the scan/toss process too. o Smart zonehandling If you are processing echomail between zones DCM will help you out. All seen-bye lines will be stripped off except the important ones (your own and the other gates address). This zonehandling capability is standard in the dutchie package. o Smart pointsupport DCM handles (like the rest of the Dutchie program) points transparantly. Just set it up and forget about FidoNews 6-15 Page 16 10 Apr 1989 them. o smart scanlists. a typical scanlist looks like this: 500/2 3 4h 5c 6 512/3 .1S .2 .3 1:105/42 As you can see short notations are available, and points are indicated by a dot in front of their pointnumber. An 'H' attached to an address means that the attache file message to this node must have the HOLD flag, a 'C' means that it must have the crash flag. S means a 'split' conference and this one switches on Groupmail like features that will save you lots of diskspace and transmission time. We will discuss that later in this article. If a full zone address is available and the zone is another than your own zone DCM will act as a zonegate for this Conference. In addition to or in stead of this list of nodes you can tell DCM to find the nodes in an ascii file by placing a @filename.ext on this line. If you have standard distributions you can point to the same file from different conferences. The dutchie package has support programs to send canned messages or files to a distribution list so you can inform all nodes that get the conference with one simple command in a batchfile or on the commandline. o smart flags The flagfield controls DCM Functions per conference. Among them are f.i. R for renumber, K: for killing messages older than n days and M: for the maximum number of messages to keep in this Conference. Access to the conference is controlled by the L: and S: flags, who control Accesslevel and Accesskeys for the automated JOIN and DISJOIN functions that are build into DCM as an AREAFIX replacement. o smart JOIN/DISJOIN build in functions DCM has build in JOIN and DISJOIN functions for unattended joining and disjoining a conference. These functions are easy to use yet versatile. They generate welcome messages and succesfull joining a conference (by means of dutchies service requests) will result in a working conference on the requesting node. All changes on both nodes involved are performed, including creation of directories, changes in the areas file, welcome messages and a 'rulesfile' created on the requesting node. For full appriciation of this function you will need Dutchies mailer program, but the function can easely be performed by other mailers in cooperation with a small program to be released in the near future. o smart archiving DCM has build in archive and dearchive programs modelled after the PAK series. An environment variable controls the backward compatibility with older archive FidoNews 6-15 Page 17 10 Apr 1989 programs but if your echomail is exchanged with other systems using DCM you can switch to a better 'crunching' system. o Smart duplicate and topology problem detection DCM will detect duplicate messages that arrive on your system and get rid of them before they hurt the network. DCM will also scan the PATH list at the end of each message. If there is a topology problem DCM will remove the message and inform you about the problem so you can take corrective measures. Groupmail functions ------------------- DCM addresses the same drawbacks in current conference mail processing (pointed out by a lecture of the echomail coordinator last FidoCon) as Groupmail but has a totally different solution for these problems. Lets quickly review the problems that we all have with the current way of handling conference mail: o there is a copy of each messages present on your disk for every node you scan to. o The number of seenbyes often exceeds the contents of the message itself. Those designproblems in confmail lead to excessive disk use and unneeded connection time. Both translate in money unneccesarely spend on diskspave and phone costs. When the echomail topology is under control in a network you can switch to the split conference mode of DCM by merely adding an S at the end of the node in the scanlist. Other than Groupmail, you can switch to the new system on a per node base and you do not need to convert the whole conference. From this you can also see that switching back and forth between the new methode is very easy, just append or erase the trailing S. The best place to convert to the new format is on a BOSS node. He has tight control over the topology and will benefit most. When switched to the new methode almost all seenbyes are stripped off and there will be only one copy of the message on you disk. This works two ways, the messages are shorter and there are a lot less. An example: a Boss serving 20 points, who all have 5 conferences with ca 40 messages a day yield a total of 20 * 40 = 800 (packed) messages a day. The new system only has 40 (packed) messages on your disk and they are about 50% shorter. Not bad and on hughe echomail processors this adds up. There is a small drawback to this approach, there is FidoNews 6-15 Page 18 10 Apr 1989 an attached file for every conference. On high speed half duplex modems this will reduce the overall through put. The Dutchie Mailer 2.91 will solve this problem in cooperation with DCM and send those small archives as one big archive, real time. In the next few months we will release a 'condense' program that will condense those files into weekly, monthly and yearly archives. Nodes wishing to get a backlog of the conference then can filerequest the old messages. More ---- I have not discussed all features of DCM, you should try it yourself. The program is copyrighted, but there is no fee charged. It will be released with a conversion program for an easy switch from confmail to DCM. Availability ------------ We expect that the 2.91 release will reach the USA this or the next week, it will be put on the software d istribution backbone, so in a few days it will pop up everywhere in fidonet. There is more ------------- DCM is the last program we needed to complete the Dutchie Personal Mailer software packet from the Netherlands. Its a complete fidonet capable software packet with an european touch. The complete packet contains: Dutchie, the mailer Dutched, the full screen editor Install, a 5 minute install program Packer, the most versatile packer available Sched, an intelligent scheduler DCM, dutchies conference manager XMIT a batch/commandline file sender REQ a batch/commandline file requestor MSG a batch/commandline message sender Dutchlat an intelligent nodelist translator Dutchcom the nodelist compiler Dutmain a full screen nodelist maintenance prg Third party software avaiable: Dmenu A very friendly full screen shell around dutchie for points Dutchlog The best log analyzer available FidoNews 6-15 Page 19 10 Apr 1989 Password a service request to allow nodes to change there own session password on another dutchie mailer more .... Current version is 2.90c. Next version will be 2.91 DCM is the first 2.91 version that has been released, the others will follow during april and may. ----------------------------------------------------------------- FidoNews 6-15 Page 20 10 Apr 1989 VETNet is ALIVE!!!!! By: Todd C. Looney Vietnam Veterans' Valhalla 1:143/27 7:406/27 300/1200/2400 Bauds (408) 293-7894 The sysops of the Vietnam Veterans Valhalla bulletin board are both Vietnam combat veterans; I served during the war as a Medical Field Surgeon in the U.S. Navy attached to an Emergency Field Evac Hospital and later a long-range recon team near Dac To, and spent more than my fair share of time in a VC/NVA prison camp across the border in Laos, and Nancy my wife, who is a veteran of a different sort having fought HER war *years* after I returned to the United States, battling the problems I brought back from that little country tuck