F I D O N E W S -- Volume 14, Number 19 12 May 1997 +----------------------------+-----------------------------------------+ | 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. | +----------------------------------------------------------------------+ GO AHEAD MAKE MY DAY! Table of Contents 1. EDITORIAL ................................................ 1 Zone 2 reports problems in Italy ......................... 1 2. LETTERS TO THE EDITOR .................................... 2 International BBS Week Update ............................ 2 A cover up ............................................... 2 3. ARTICLES ................................................. 3 Police crack-down on Fido-nodes in zone-2/region-33 (It .. 3 It Can't Work? ........................................... 4 4. COLUMNS .................................................. 7 Lock and Load: Special Edition ........................... 7 5. GETTING TECHNICAL ........................................ 9 FSC-0068 - Proposed Replacement for FTS-0004 ............. 9 FSC-0069 - Proposal for FidoNet (FTN) Domain Name Servi .. 14 FSC-0070 - Improving Fidonet/Usenet gating/Dupe Checkin .. 21 6. COORDINATORS CORNER ...................................... 24 Nodelist-statistics as seen from Zone-2 for day 129 ...... 24 7. ECHOING .................................................. 25 North American Backbone Echo Changes [Mar-Apr] ........... 25 8. NET HUMOR ................................................ 27 How to install software .................................. 27 9. QUESTION OF THE WEEK ..................................... 30 Who has OLD Nodelists out there? ......................... 30 10. NOTICES ................................................. 31 Future History ........................................... 31 And more! FIDONEWS 14-19 Page 1 12 May 1997 ================================================================= EDITORIAL ================================================================= Law enforcement in many places still hasn't moved into the current century it would appear. Humans are slow to catch up with technology and this is particularly true for the computer communication revolution now underway. We also see it in the U.S. [so-called technology leader of the world] in the form of the C.D.A. [Computer Decency Act] and lots of local crimes against information by the uninformed or ill-informed. At least FidoNet, for the moment, is still a leading light in the fight for progress and information spread! Go get 'em Italian Sysops! Still no IC. The ZEC election in Zone 1 appears to be unraveling. Same old stuff. Keep those cards and letters coming! [grin] C.B. ----------------------------------------------------------------- FIDONEWS 14-19 Page 2 12 May 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= International BBS Week Update by David Chord (3:771/1560/david.chord@cobra.galaxy.gen.nz) Things are moving along slowly for International BBS Week. So far, only a few people have bothered to do something about it, although some of those who have should be able to contribute quite a bit to help get things moving. There has been a request to move the date, as the first week of June is a bit early to do any adequate planning, espically for something hoped to have world-wide media coverage. At this stage, there is no definite date, it is open for discussion. Also, I have created a new echo for the discussion and planning of International BBS Week - INTBBS_WEEK. This will be co-moderated by Anne Pickets (3:772/270, Ivy Iverson (1:154/170) and myself, if Ivy and Anne accept this proposal. If you haven't already connected to the echo, please badger your local Hub/N(e)C into getting a feed for it. Hopefully, an echo will be a much better method of discussion. ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Fri May 09 00:11:13 1997 From: Bob Moravsik @ 1:2606/583 To: Fidonews @ 1:18/14 Date: 30 Apr 97 07:08:45 Subj: A cover up * Original to Jason Steck of 1:285/424@fidonet.org cc: Zorch Freezberg Fidonews Jason: My link cut from ZEC was done by for political reasons. Its well known that ZEC is really TWO conferences. Its not against Fidonet's policy to have two conferences with the same tag. Bodger's node was put in the seenbye as I CHOOSE to not provide MY MESSAGES to him. Your continuing this charade just points out what a DISHONEST WEESEL you are. You are out to create a problem then drop out of Fidonet in laughter. Resign NOW...Fidonet will be far better off without you. Bob Moravsik ----------------------------------------------------------------- FIDONEWS 14-19 Page 3 12 May 1997 ================================================================= ARTICLES ================================================================= Police crack-down on Fido-nodes in zone-2/region-33 (Italy) By Ward Dossche, 2:292/854 ZC/2 For the second time in a relatively short period the Italian police cracked-down on some Fidonet-nodes in Italy (zone-2/region-33) May 7th at 7.30am thereby effectively shutting down substantial portions of the net. The hardware of some 3 nodes was seized pending investigation. Suspicion of distributing child-pornography is held against the sysops but people in their immediate vicinity, among which the RC for region-33, describe this as a terrible mistake probably due to misinformation of the concerned prosecutor or total ignorance about the difference between Fidonet and Internet. I have already written to the Italian ambassador and the Italian delegation at the European Commission, both in Brussels. This is the text: Dear Sirs: I am the European coordinator of the world-wide Fidonet computer- network. Fidonet is a low-cost-technology network which unites computer- communication hobbyists all over the world. At present there are worldwide 26.847 systems connected of which 15.904 are in Europe and 415 in Italy itself. This network reaches worldwide millions of people, organizations, schools, etc.. who rely on it as their window to the world. It has been brought to my attention that 3 eminent members of Fidonet in Italy in the cities of L'Aquila, Naples and Taranto were faced with seizure of their private computer-equipment on May 7th on suspicion of distributing child-pornography. People that I know in the Rome-area whom are trustworthy to me vouch for the 3 individual citizens that the claims being made by the local authorities are unfounded. I support this point of view. It is now the second time that Italian law-enforcement seriously hampers the operation of this network which is completely non- commercial and run on private funds as a hobby by individual system-operators. The lack of distinction by certain Italian law-enforcement officers FIDONEWS 14-19 Page 4 12 May 1997 between honest hobbyists who function in the regulated environment that Fidonet is and the unregulated internet where anything and everything is possible, is a blame to the professional abilities of these individual Italian law-enforcement officers. I would like to be kept officially informed as to the status of this matter and would like to ask you to inform your government that in the meantime hundreds of thousand, if not millions, individuals worldwide will have received this message and are watching on how it will be solved. I am looking forward to your further communications, (signed) Although everyone does as he/she pleases I would encourage individuals to look for the addresses of their local embassies or consulates and in a kind of cut-and-paste technology write similar letters of protest. Thank you very much for your attention. Ward ----------------------------------------------------------------- It Can't Work? By: Clay Tannacore 1:372/4 As many of you serious readers of FIDONEWS are aware, I have, over the last several months, been on a somewhat unavailing campaign to merge FidoNet with EchoMail. I have stated many reasons for this and creditable ones *were* included. However, over those months, I have been inundated with many ideas and opinions contrary to my views. Varied opinions have been expressed in opposition of my ideas and many of those were, in themselves, creditable. Some of the rationale why the two entities should not and could not be accomplished led me to the belief that perhaps, the readers weren't completely sane. While a number of the opinions expressed seemed to have merit, I felt I should perhaps rethink my views or at least investigate the idea of an emergence of a policy that would direct both associated entities to be one. Of course, among the creditable opinions rendered were a reasonably abundant scattering of ideas as to how I might increase my sexual activities with some rather unworkable arrangements in placement of my partner and myself. Needless to say, I was not of the mind to attempt any of these recommendations, as testified to by my presence once again in FIDONEWS, and the fact that I have not had occasion to seek out professional attention from a chiropractor. Nonetheless, I did feel obligated to take a more prolonged and FIDONEWS 14-19 Page 5 12 May 1997 in-depth look at what I was advocating. During this time period, I had the opportunity to observe the power struggle taking place in Zone1 for the ZEC1 position. I have read numerous messages in the NL_SYSOP Echo, as well as a number of posts in other related areas. It was only after observing and following these message areas that I started to comprehend what so many individuals had been attempting, all along, to make me aware of. It would appear that if EchoMail was indeed included in the jurisdiction of FidoNet under POLICY4, and if a tyrannical type were to be installed into a position such as ZEC, this despot could, with very little exertion on his/her part, promote the overtaking of the whole of FidoNet. With the use of intimidation, threats, controlling of EchoMail feeds, and to some extent, bribery, place himself in such a position as to have every member in FidoNet totally dependent on him/her. To some extent this contemptuous situation is already taking place and without the unification of the members of that region, this poisonous alliance of a few will prevail. Getting back to the original intent of this article - the merging of FidoNet with EchoMail. It is now my enlightened position that in the interest of FidoNet, and those who are a part of this association, that both FidoNet and EchoMail can *never* be successfully merged. Both entities should remain separate and apart but both entities should attempt to strengthen the versions of their active policy documents. While I no longer feel that POLICY4 should include in its body any mention of social behavior which in itself would be destructive to that policy. I immovably believe a policy outlining behavior within EchoMail that is distributed by FidoNet, should be enacted and placed in affect at the earliest possible time. This behavioral policy document should set minimal standards for all EchoMail and Echoes distributed via the FidoNet association. Specific language should be included in this document detailing the consequences of not complying with the language. Special attention should be integrated within the document, taking into consideration that the users of EchoMail are not necessarily members of FidoNet and are not governed by POLICY4, or ECHOPOL. It should be stressed that latitudes when dealing with non-members may vary depending upon the situation at hand. However, rules and procedures must be administered properly, for the benefit of FidoNet as a whole, and equability for the end user. I would suggest that an Echo be set up, with a moderator in each region linked together via EchoMail, for discussions and suggestions pertaining to this document. Input from different sections and segments of FidoNet will be imperative in order to make this undertaking workable. I realize this is an open invitation to those of you who feel nothing in FidoNet needs changing but I assure you that something has to be done in order for FidoNet to survive. We have to attempt to bring back into the folds of this association those users who have moved on to the Internet. We have a golden opportunity to restore FidoNet to the prominence it once had. Once the user discovers that the Internet is nothing but a commercial venture with no personality, no FIDONEWS 14-19 Page 6 12 May 1997 friendliness and, no closeness or brotherhood, FidoNet can, with a little effort on our part, be number one again. ----------------------------------------------------------------- FIDONEWS 14-19 Page 7 12 May 1997 ================================================================= COLUMNS ================================================================= Lock and Load: Special Edition Robert Parson (1:3822/1) There normally would not be a column for this week, but with the pending International BBS Week, I thought I'd write a News Release you can use. Just fill in the blanks in the first and last paragraphs with the appropriate information, and fax or mail this to your local news outlets (Newspaper, Radio, TV). As I've discussed before, don't expect to receive any media coverage from a News Release. You're competing with dozens, possibly hundreds of other pieces of mail or faxes that media outlets receive each day. Also remember, some newspapers may simply re-write the news release without contacting you. I'd like to know if you get any media coverage. You can contact me at the above Fidonet address, or (gasp!) the internet at newsbob@kwhn.com I'd like to know: Who you are, the name and city of your BBS, the name and city of the media outlet, what sort of outlet they are (radio, tv, newspaper, magazine, wire service, etc), the name of the reporter, the date the article appeared, and the general tone of the article (favorable, unfavorable, bemused). Next week: the return of our regularly scheduled column. Good luck! ---> Cut here! <--- International BBS Week June 1-7 1997 (BBS Name) in (City) is joining with tens of thousands of other Computer Bulletin Board systems worldwide in celebrating International BBS Week June 1st through 7th. Most BBSes, as they are commonly called, are operated by hobbyists from their homes. They allow other computer users to call in with their modems to exchange messages and files and to play games. As with any hobby, the exact number of BBSes is unknown. However, at last count FIDONET listed nearly 33 thousand nodes, or incoming phone lines. Fidonet is the oldest and largest amateur network connecting BBSes worldwide. Some BBSes offer other networks, some offer none, and other BBSes may even be connected to the Internet. Many BBSes provide their services for free, although some do charge a small fee for access. FIDONEWS 14-19 Page 8 12 May 1997 For more information on International BBS Week, contact (BBS Name) System Operator (Your Name) at (Voice phone), or leave a message on the BBS by calling (BBS Number) with a modem. -30- ----------------------------------------------------------------- FIDONEWS 14-19 Page 9 12 May 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing FidoNet History series featuring the FTSC Standards and Proposal documents to-date. This docs have been reformatted to 70 columns where required which may cause tables to appear askew. Node and telephone numbers may be outdated.] Ed. Document: FSC-0068 Version: 001 Date: 13-Dec-1992 A Proposed Replacement For FTS-0004 Mark Kimes 1:380/16@fidonet Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Echomail documentation: ====================== Definition: ========== Echomail, sometimes called broadcast or conference mail, is netmail (ref. FTS-0001) containing additional control information that allows it to be "echoed" (forwarded) from node (site) to node. Echomail is divided into areas, or conferences, with unique names. The format for packets, message headers and message text is identical to that specified for netmail in FTS-0001. Control lines in general: ======================== A control line is a line of text in the message's body (the nul-terminated text portion of a message following the binary header; see FTS-0001) ended by a carriage return. Some control lines are preceded by a ^a (control-a, ASCII character 1) and are sometimes referred to as "kludge lines." Kludge lines are normally not shown when displaying a message; the reading software will treat the initial ^a as meaning "not (normally) for human consumption." Required control information: ============================ AREA: An AREA tag is what makes the difference between netmail and echomail. The AREA line must be the first line in an echomail FIDONEWS 14-19 Page 10 12 May 1997 message's body. An AREA line's format is simply: AREA: The AREA tag is specifically _not_ preceded by a ^a. It might be a good idea for an application to allow for but not produce AREA tags with ^a prefixes. Where is the unique name of the echomail conference. For compatibility with existing software, area names should not begin with the plus or minus ("+" or "-") symbols. Area names must not contain control characters (less than ASCII character 32, a space). Leading and trailing spaces on the area name should be ignored (and preferably not produced). Compares on the area name should be case insensitive. Area names are generally kept as short as possible while still maintaining uniqueness and some sense of what the area's topic is about. The purpose of the SEEN-BY control line is to protect fully connected polygon topology (see Topology below) from duplicate message looping. Keeping SEEN-BYs beyond a small topology group is wasteful and should be avoided, but a message must contain at least "Tiny Seenbys" in order to avoid choking older mail processors. Tiny Seenbys are the node currently processing the message and any nodes to which that node is sending the message. This means that in all cases a SEEN-BY line will contain more than one address. SEEN-BYs are located after any Origin line and before any PATH line(s). A SEEN-BY line has the following format: SEEN-BY <[net]/node> ... <[net]/node> The 2-D addresses following the SEEN-BY tag are "net sticky," which means that net information is not duplicated if unchanged from the previous address listed. For example, if 380/20 sends a message to 380/16, 380/100 and 170/1, the SEEN-BY line would read: SEEN-BY 170/1 380/16 20 100 SEEN-BY tags are specifically _not_ preceded by ^a. It might be a good idea for applications to allow for but not produce SEEN-BY tags with ^a prefixes. SEEN-BY addresses _are_ specifically sorted by net/node. It might be a good idea for applications to allow for but not produce unsorted SEEN-BY addresses. SEEN-BY lines should not exceed 79 bytes in length; if more addresses are required than can be represented on one line, a carriage return followed by another SEEN-BY tag followed by more addresses should be added. Current practice is to strip SEEN-BYs at zone and domain gates since FIDONEWS 14-19 Page 11 12 May 1997 their 2-D nature make them useless for duplicate message checking beyond a given zone. Optional control information: ============================ Origin: Origin lines, when they appear, contain the text " * Origin: " at the start of the line, and an address in parentheses at the end of the line. Between these two portions of the line there may be some other text which can be ignored. Origin lines may contain addresses in many formats, from simple 2-D net/node to 5-D domain addresses. An echomail processor should never choke because a message contains no Origin. Origin lines are specifically _not_ preceded by ^a, and should be no longer than 79 characters in total length. Some existing mail processors may choke on echomail that does not contain an origin line. Therefore, for maximum compatibility, echomail processors should have an option, perhaps on a conference-by- conference basis, to assure all messages originating at a site contain an Origin (adding a default one if not already present). In situations where an Origin is not used, a MSGID (see below) should be used so that private (netmail) replies are possible. Some gateways add their own Origin line and change any existing Origin line to " # Origin: ". You should keep this in mind if attempting to use Origin lines to find the "real" origin of a message. PATH: PATH line(s), when they appear, follow the message's SEEN-BY line(s). PATH lines are specifically preceded by ^a, and should be no longer than 79 characters in length. PATH lines have only one purpose: to convey to a human some information about which systems have processed (forwarded) a message, and in what order. The 2-D (net/node) nature of PATH coupled with the practice of not stripping PATH lines from a message at zone gates make it impossible to reliably use for the prevention of duplicate message looping (you can't tell if 380/16 refers to 1:380/16 or 2:380/16, or Dufusnet#1:380/16 instead of Fidonet#1:380/16). A PATH line has the following format: ^aPATH <[net]/node> ... <[net]/node> Like SEEN-BYs, PATH lines consist of a tag, ^aPATH, followed by 2-D "net sticky" addresses. Unlike SEEN-BYs, PATH is specifically _not_ sorted, and it's possible there will be only one address. For example, assuming all nodes support PATH, given that a message originates on 380/16, and goes through 380/20 to 380/100, the PATH line at 380/100 would read: ^aPATH 380/16 20 and the PATH line at 380/20 would read simply: FIDONEWS 14-19 Page 12 12 May 1997 ^aPATH 380/16 Other optional information: ========================== Tear line: A tear line, when it appears, consists of three dashes ("---") at the beginning of a line, sometimes followed by a space and some text, possibly the name of the editor, packer, or BBS that created or first manipulated the message. Tear lines, when present, are located just before the Origin line. Tear lines serve no control purpose, but are often placed into messages for historical reasons. They should be considered as what they are: just part of the message text. MSGID: A control line defined in FTS-0009. Identifies the origin address of the message, and provides a unique serial number that can be used for linking replies and duplicate message control. REPLY: A control line defined in FTS-0009. In conjunction with MSGID, can be used to link replies to original messages. INTL, TOPT: Netmail routing control lines defined in FTS-0001. These control lines should not appear in echomail as they impart "false" information after the first "stop" due to the nature of echomail. FMPT: A control line defined in FTS-0001. Identifies point portion of from address. This control line should not appear in echomail unless there is no MSGID and the Origin line doesn't list the point portion of the address. You may find other (experimental) kludge lines in an echomail message. Generally speaking, a kludge which is "netmail only," like a routing kludge or a "VIA" line, should not appear in echomail. Remember that the cost of transmitting a message will be borne by many nodes, and extraneous, unuseful information produces unnecessary additional cost. All control information in echomail messages should be kept as small as possible. If you're curious about the uses of an experimental kludge and/or are considering supporting it, check for an FSC-* document covering it. Security considerations: ======================= Echomail processors that attempt to provide a "secure" environment should not rely on the message header address, but use the packet header address (and possibly the password field) instead. The packet header field will reflect who sent you the message. Message header addresses are usually also changed to reflect the forwarder instead of the "real" origin, but this is not guaranteed (and perhaps not even desirable). To find the "real" origin of a message, check for a MSGID and/or Origin line. Topology considerations: ======================= Nothing creates duplicate message loops faster than bad topology. Consider the following simple diagram: FIDONEWS 14-19 Page 13 12 May 1997 B<---->C ^ ^ A<-------->| |<-------->F v v D<---->E This topology contains a duplicate message loop. Consider: B receives mail from A and forwards to C, D and F. C, D and F forward to E. If we connect the polygon so: B<---->C ^\ /^ A<-------->| \/ |<-------->F v / \ v D<---->E In this topology (fully connected polygon), no such duplicate message sending occurs. While fully connected polygons can be effective in some networks (these are the reason SEEN-BYs can be necessary for more than backward compatibility), a better topology in general is the star and/or tree: +<-->E ^ | v another tree +<-->D<-->+<-->F ^ ^ ^ | | | | | v v v +<-->G another tree <--->A<--------->B<-->+ ^ ^ +<-->H | | ^ | | | v v v another tree +<-->C<-->+<-->I ^ | v +<-->J Echomail topology should be carefully monitored by the systems involved to prevent formation (or quickly disassemble) costly duplicate message looping constructs. Acknowledgements: ================ Tom Jennings "created" Fidonet. Jeff Rush "created" echomail. Bob Hartman's ConfMail docs served as the echomail specification for years, and did so admirably; the mail moved. Related documents: ================= FTS-0001 (transport layer, packet format, various kludge lines) FIDONEWS 14-19 Page 14 12 May 1997 FTS-0009 (MSGID and REPLY) FSC-0039 (alternate packet header format) FSC-0043 (hints on recognizing control information) FSC-0045 (alternate packet header format) -30- ----------------------------------------------------------------- Document: FSC-0069 Version: 001 Date: 13-Dec-1992 A Proposal for A FidoNet (FTN) Domain Name Service Robert Heller 1:321/153 Locks Hill BBS Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Information ----------- The purpose of this FSC is to describe my ideas for migrating FidoNet(r) networks from a "static" nodelist to a domain based nameserver type of address resolution scheme. This document does not propose a definitive scheme, only one posible scheme. Other schemes are posible - this document just presents one as a starting point for discussion. 1. Introduction --------------- In this document I plan to present a simple domain nameserver scheme for FidoNet(r) networks. This scheme could be implemented easily, since no new connection protocols would be needed and in fact little new software would be needed. Nameserver queries would be implemented as File Requests for magic filenames. The files would contain the information needed to perform the desired address resolution. These files would be built by the nameserver in advance by an off-line process. That is, they would be pre-computed - the querying node would not be left hanging on the line while the nameserver went off and did a database lookup. FIDONEWS 14-19 Page 15 12 May 1997 2. Addresses ------------ A domain nameserver based FidoNet would use three levels of addressing: virtual (most abstract), logical, and physical (least abstract). 2.1 Virtual Addresses A node has 1 or more virtual addresses, one of which is it primary address and the others are aliases. A virtual address is a totally symbolic address and is formatted just like an InterNet address: node.domain where node is the node's name and domain is a domain specification and can have any number of [sub-]* domains. For example, my system could have a virtual address of: LocksHill.DeepWoods.com.fidonet.org The node and domain segment strings consist of letters (upper and lower case are equivelant), digits, dash (-), underscore (_), and dollar sign ($) characters and must begin with a letter. Virtual addresses generally convey no geographical or routing information. They are intended purely for human convience purposes - they are really little more and a node name, with some added information. 2.2 Logical Addresses A node can 1 or more logical addresses, although having only 1 is preferable. A logical address is exactly an existing 3-4D FidoNet(r) address: Zone:Net_or_Region/Node or Zone:Net_or_Region/Node.Point A logical address is used by mail packers and mail routers. It is the addresses exchanged in YooHoo/2U2 packets and live in the Type-2 packet headers. 2.3 Physical Addresses A node has exactly one physical address. In FidoNet(r), this is typically the telephone number assigned by the telephone company. (It is posible that some nodes have something else as a "physical" address, for example a point which is connected to its bossnode via a LAN connection or a hardwired COM port.) A multi-line BBS typically has one line for FidoNet(r) connections or multiple logical and virtual address, at least one per line. The physical address is used FIDONEWS 14-19 Page 16 12 May 1997 by the mailer program to actually make a connection. 3. The Domain Database ---------------------- The domain database would consist of four ASCII text files, probably compressed: 1) The domain table. This text file maps between virtual addresses and logical addresses. It also defines aliases as well and lists nameservers. 2) The mail-exchanger table. This text file describes the prefered netmail routing. For each domain tail, it lists one or more node names that handle incoming mail for those domain tails. This file only uses virtual addresses. Its data is consulted by high-level mail routers, that take out-bound mail messages and combines them into bundles that are later packed into mail packets (which are routed to logical address fetched from the domain table). 3) The capability file. This file describes any extra services or capabilities a node might provide. This includes (but is certainly not limited to): gateway services (to other FTN or to non-FTN networks), alternitive low-level connection protocols (i.e. UUCP, SLIP, etc.), and file echos (SDS, SDN, etc.). This file is meant as a catch-all for misc. optional information that might be usefull. 4) The nodelist segment file. This file contains the mapping from logical address to physical address, and is in fact, a presnt-day NodeList file, except it is a "sparce" nodelist. That is, it only describes the nodes at the immediate level of the nameserver and nodes at the level above and below the nameserver. 3.1 Format of the domain table file. ------------------------------------ The domain table file contains 1 or more lines of text. Lines starting with a semi-colon (;) are comments and are ignored when this file is processd. Each non-comment line contains two or more fields separated by commas: field1,field2,...,fieldN The first field is a field type keyword. The field types defined are (case is not important): DEFAULT,domaintail Defines the default domain tail to append to domain names in the rest of the file. Domain tail must begin with a dot (.). Any subsequent domain names that do end in a dot will get the specified FIDONEWS 14-19 Page 17 12 May 1997 domaintail appended before further processing. NAMESERVER,domaintail,domain,preference Defines a domain server for domaintail. Domain is the virtual address of the server node and preference is a preference value, a number giving a relative value when looking for a server to contact. A higher number means this is a better node to try and a lower number means this is a backup server. The preference gives a ranking for multiple servers for a given domain tail. ALIAS,domain1,domain2 Defines that domain1 is an alias for domain2. ZONE,zone-number REGION,region-number NET,net-number Defines default values to use in subsequent ADDRESS lines. Region and net lines are effectivly interchangable and are used for documentary reasons. ADDRESS,domain,logical-address Defines the logical address for domain. The logical-address can be missing fields. Missing fields are supplied from prior ZONE, REGION, and NET lines. Node and point numbers cannot be defaulted. 3.1.1 Sample domain table. ;; Domain table for Network 999 (N_Luna) of zone 444 (the Moon) ;; (c) Copyright 2001 Network 999 ;; ;; Our default domain Default,.N_Luna.moon.fidonet.org ;; Our zone Zone,444 ;; Our Net Net,999 ;; Our NC, Jim Alias,N_Luna_Net,Jims_SpaceSuits ;; Our NEC, Sally Alias,N_Luna_NEC,Sallys_Lunies ;; Our namesevers ;; Note empty domaintail - the default is used NameServer,,N_Luna_Net,100 NameServer,,N_Luna_NEC,50 ;; Out of net nameservers ;; Our Zone nameserver NameServer,.moon.fidonet.org.,Moon_NS.fidonet.org.,100 ;; Our IC nameserver NameServer,.fidonet.org.,FidoNet_NS.fidonet.org.,100 ;; Use the IC nameserver for non-fidonet addresses NameServer,.,FidoNet_NS.fidonet.org.,100 ;; FIDONEWS 14-19 Page 18 12 May 1997 ;; ;; Nodes ;; Address,Jims_SpaceSuits,100 Address,Sallys_Lunies,110 Address,Moon_Rock_BBS,120 Address,Monolith_HQ,200 Address,Space1999,210 Address,LostOnTheMoon,240 Address,NorthLunaics,300 ;; ;; Out of net addresses ;; Address,Moon_NS.fidonet.org.,999/100 Address,FidoNet_NS.fidonet.org.,1:1/0 Address,naEarth_gate.moon.fidonet.org.,999/1 Address,eurEarth_gate.moon.fidonet.org.,999/2 Address,ozEarth_gate.moon.fidonet.org.,999/3 Address,saEarth_gate.moon.fidonet.org.,999/4 Address,AfricaEarth_gate.moon.fidonet.org.,999/5 Some notes about the above - the underscores (_) are part of the names and do not indicate spaces. The case mixing is stylistic and is an aid to readablity. The above is a net level domain table. It also includes nameserver definations for higher levels, so nodes in N_Luna net can perform address resolutions to out of net addresses. 3.2 Format of the mail exchanger table file. -------------------------------------------- The mail exchanger table file contains 1 or more lines of text. Like the domain table lines starting with a semi-colon (;) are comments and each non-comment line contains a list of three comma-separated values: domaintail,domain,preference Where domaintail is a domain suffix of a posible mail address, domain is the virtual-address of a node that handles the domain suffix's mail, and preference is a preference value (higher number is more prefered than a lower number). 3.2.1 Sample mail exchanger table file ;; Mail exchanger table for Network 999 (N_Luna) of zone 444 (the ;; Moon) ;; (c) Copyright 2001 Network 999 ;; ;; Local mail can go via either the NC or NEC, with the NC ;; getting a higher preference .N_Luna.moon.fidonet.org,N_Luna_Net.moon.fidonet.org,100 .N_Luna.moon.fidonet.org,N_Luna_NEC.moon.fidonet.org,90 ;; Out of zone mail goes through the zone gates .naEarth.fidonet.org,naEarth_gate.moon.fidonet.org,50 .eurEarth.fidonet.org,eurEarth_gate.moon.fidonet.org,50 .ozEarth.fidonet.org,ozEarth_gate.moon.fidonet.org,50 .saEarth.fidonet.org,saEarth_gate.moon.fidonet.org,50 FIDONEWS 14-19 Page 19 12 May 1997 .AfricaEarth.fidonet.org,AfricaEarth_gate.moon.fidonet.org,50 .JupiterNet.org,Monolith_HQ.N_Luna.moon.fidonet.org,50 Some notes about the above - undefined domain tails don't have a defined mail exchanger - this will a node trying to send such mail to do a nameserver call to get mail exchanger and any other info needed. ( The above is probably unrealistic - a more realistic mail exchanger table might have a default mail gateway. And/or a zone-local inter- network nameserver.) 3.3 Capability file. -------------------- The capability file lists virtual-address and any extra services it might provide. Semi-colon (;) in column one means a comment. The non-comment lines are of the format: virtual-address,keyword:value,keyword:value,... Where virtual-address is a node's virtual address. There can be any number of lines with the same virtual-address. The keyword:value pairs accumulate (as if there was only one very long line for that virtual-address). 3.3.1 Sample capability file. ;; Capability file for Network 999 (N_Luna) of zone 444 (the Moon) ;; (c) Copyright 2001 Network 999 ;; Jims_SpaceSuits.N_Luna.moon.fidonet.org,Protcol:UUCP-Z,File:SDSURISC Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTWIND,File:PDNVIRTR EAL Monolith_HQ.N_Luna.moon.fidonet.org,Protocol:X2500,Gateway:JupiterNet. org Space1999.N_Luna.moon.fidonet.org,File:PDNNUKEWASTE 3.4 The NodeList Segment File. ------------------------------ The nodelist segment file is just a FTS-0005 nodelist file, except it is "sparce", that is, it only contains just enough info to translate the logical addresses in the corresponding domain table file. 4.0 Nameserver Implementation. ------------------------------ Nameservers would be implemented by using the existing file-request methods presently in existance. Five magic filenames would be setup: DNSDTABL - Domain table file DNSMXTBL - Mail Exchanger table file DNSCAPAF - Capability file DNSNODEL - NodeList segment file DNSALL - An archive file containing all four of the files. All a nameserver would need to do would be to provide these five files, probably in some sort of commonly acceptable archive format. FIDONEWS 14-19 Page 20 12 May 1997 The real filenames should have some sort of predictable, but unique name probably based on the level of the nameserver and the number of the zone, region, or network the nameserver serves. 4.1 Nameserver Levels. ---------------------- Nameservers would exist at various levels: 1) At the zone level. The zone level nameserver(s) would supply information for the current zone level nodes, regional level nameservers, and would also have information about the zone level nameservers in all other zones. 2) At the regional level. The regional level nameservers would supply information for the current region level nodes (indpendent nodes), the current zone nameserver(s) (up level), and network level nameservers. In some smaller zones, the region level *might* be skipped. The RC also makes the regional level domain info available to each of the region's independent nodes. 3) At the network level. The network level nameservers would supply information about the current network level nodes (regular nodes), and the current regional nameserver(s). Also, the NC delivers or makes available the network level domain info to each of the nodes in the local network. (If the regional level is skipped, the network nameservers would contain entries for zone level nameservers and zone level nameserver(s) would contain network nameserver info instead of regional nameserver info.) 5.0 Database Updates and Management.