F I D O N E W S -- Volume 14, Number 23 9 June 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. | +----------------------------------------------------------------------+ IT'S ONLY LAME WITH AN F Table of Contents 1. EDITORIAL ................................................ 1 What would it take to get YOU to submit something? ....... 1 2. LETTERS TO THE EDITOR .................................... 2 To Compress Mail or Not to Compress Mail? ................ 2 3. ARTICLES ................................................. 4 FidoNet Via Internet Hubs ................................ 4 Some thoughts on a possible future direction for Fidone .. 4 SILLYSEASON Echo forming ................................. 6 Why I bother ............................................. 7 4. COLUMNS .................................................. 9 Lock and Load: Guerilla Marketing for BBSes .............. 9 5. GETTING TECHNICAL ........................................ 11 FSC-0080 - Describing FidoNet with layered model ......... 11 FSC-0081 - A TYPE-3 Packet proposal ...................... 13 6. COORDINATORS CORNER ...................................... 28 Nodelist-statistics as seen from Zone-2 for day 157 ...... 28 7. NET HUMOR ................................................ 29 Nevermore? ............................................... 29 8. NOTICES .................................................. 31 Future History ........................................... 31 9. FIDONET SOFTWARE LISTING ................................. 32 Latest Greatest Software Versions ........................ 32 10. FIDONEWS PUBLIC-KEY ..................................... 36 FidoNews PGP public-key listing .......................... 36 And more! FIDONEWS 14-23 Page 1 9 Jun 1997 ================================================================= EDITORIAL ================================================================= What? No urge to write something for FidoNews? You don't have to do a formal article or column. You can just send in something via Netmail. You can pick something new or forward something of yours from an Echo or some other forum. It's your newsletter. C.B. ----------------------------------------------------------------- FIDONEWS 14-23 Page 2 9 Jun 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= [This wasn't a Letter to the Editor, but it should have been. Folks should not be sending compressed mail to strangers. It adds an extra step when receiving mail from unsecured sources among other concerns. Unless you're sending a ton of mail, why bother?] Ed. --- Following message extracted from FTSC_PUBLIC @ 1:18/14 --- By Christopher Baker on Thu Jun 05 15:17:35 1997 From: Lisa Gronke To: All Date: 03 Jun 97 06:45:02 Subj: ARC * Original Area: PDX.SYSOP * Original To : Phil McCloud (1:105/61) The gospel says you should use either use ARC or no compression when sending to strangers. The reality is that you're more likely to run into someone who can't unARC than someone who can't unZIP. There is a networking precept that says, "Be liberal in what you accept; be conservative in what you send." As long as a sysop understands the landscape, there shouldn't be much of a problem either way. The biggest problem is passing around configuration files with ZIP configured as the default. That breeds new sysops who can't unARC and don't even know that they should be able to. I recommend ARC as the default, but encourage everyone to explicitly address the archiver issue at the time an echomail link is established. Alternatively, if you have ZIP as your default, the first interchange with a stranger should ask if it is OK. And for gawds sake, don't get into a policy pissing contest over the issue. > I believe some form of .ZIP can be compiled for any platform, > however none has ever changed the 'standard'. ZIP is very difficult to implement on 8-bit, 64K RAM systems. The lookup tables are too big to be kept in RAM. But 8-bit FidoNet systems are becoming as rare as ivory billed woodpeckers. No one has ever changed the 'standard' (which, btw, is durned difficult to find in the FTSC documents), but almost everyone has managed to minimize the effect. Other than the nodediff, ftsc and policy documents, nothing of any size is sent ARCed. The amount of FIDONEWS 14-23 Page 3 9 Jun 1997 bandwidth actually lost in ARC transfers is probably less than the bandwidth that will be used in arguing about what the replacement should be . A more cogent argument for the future is that zip/unzip are widely available in the unix world, whereas arc is not. I have three unix shell accounts. All have zip/unzip. None of them has arc. One has lharc. Oh, I'm sure that I can find unix arc source somewhere and compile it, but that's a lot of trouble if all I want to do is read policy4.arc from ftp.paonline.com. Incidentally, the "ARC" issue is a FidoNet (the network) issue, not a FidoNet (technology) issue. FTN OtherNets could have a different archiver policy. Origin: EastSide Data Services (1:105/61) ----------------------------------------------------------------- FIDONEWS 14-23 Page 4 9 Jun 1997 ================================================================= ARTICLES ================================================================= Fidonet Via Internet Hubs Speed|Node# |Operator | Facilities | Basic Rate -----+-----------+------------------+-------------------+----------- T1 |1:270/101 |George Peace | FTP | $30mo. T1 |1:396/1 |John Souvestre | FTP | $25mo. T1 |1:12/12 |Ken Wilson | FTP | $24mo. T1 |1:140/12 |Bob Seaborn | FTP, Transx | $5/$20 64k |1:124/7008 |Ben Hamilton | FTP, VFOS, Transx | $20mo. 56k |1:13/25 |Jim Balcom | FTP | $20mo. 33.6 |1:2604/104 |Jim Mclaughlin | FTP, VFOS, UUEMAIL| $1mo. 33.6 |1:2624/306 |D. Calafrancesco | VFOS | $15yr. 33.6 |1:281/169 |Brian Greenstreet | FTP | $2mo. 28.8 |1:330/204 |Patrick Rosenheim | Transx | $25yr. -- compiled by Cindy Ingersoll, 1:2623/71, (609)814-1978, fbn@cyberEnet.net Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews. --- ----------------------------------------------------------------- Some thoughts on a possible future direction for FidoNet: by Ron Dwight 2:220/22 I have been giving consideration lately to a future direction in which Fidonet could go and the following is offered for your consideration: .. Fidonet is a vastly different medium than the internet and should not be swallowed by it. Fidonet should retain it's current character, freedom and flexibility. .. FidoNet nodes need the speed and reduced cost of internet access, to communicate, this is why such things as Vmodem are being written. .. The FidoNet nodelist appears to be the largest single obstacle standing in the way of major changes to Fidonet methodology and either the nodelist can be changed to accommodate the new methods or alternative methods can be devised which make use of the current nodelist. What I am going to propose here, is a method of using the current nodelist, with almost no changes and yet allow those nodes which require access to internet transport, to obtain it quickly and easily. FIDONEWS 14-23 Page 5 9 Jun 1997 The basic concept revolves around the actual method of operation of the internet itself to satisfy the needs of Fidonet nodes. Whenever a connection is made, using a web browser, the address which you are seeking, http://.... is sent to a Network Access Point computer which translates that name into a TCP/IP address. This is sent back to your browser which then uses it to reach the destination computer on the internet. What I propose for Fidonet, is something very similar which will allow us to maintain the current nodelist format and content and yet obtain full access to internet capable systems willing to accept callers running Vmodem, Binkd or something similar.. 1) A computer, or computers, serve as Fidonet Internet Access Points. This would best be provided by a reliable system owned and operated by a large corporation. To that end we would perhaps need to obtain a sponsor, IBM would do nicely, so would US Robotics, to provide access to an internet server to act as the Fidonet Name Information Center. The load on this machine would not be great, but a little software would need to be written for it. 2) We then write a series of specifications for software which would use this service to access other Fidonet nodes via the internet. Part of this software specification would be something like: .. All internet capable nodes would be flagged in the nodelist with a single flag to indicate internet capability. The flag could be, for example: INET or something similar and the flag would indicate ONLY that the system was connected to the internet and was capable of accepting FidoNet callers. No other information would be carried in the nodelist and the nodelist entry could be used to indicate a normal PSTN node as well as an internet capable one. .. Mailers wishing to access an internet capable node must send a message, containing ONLY the FidoNet node number (Zone:Net/Node.point), over the internet to the FidoNet Name Information Center. The reply from that server would be a message containing the capabilities of that node which could then be used to establish (or refuse) a session. The time overhead for such a service would be a matter of milliseconds under normal conditions and would not add significantly to the length of a session. .. Mailer software, in order to reduce the number of transactions to the Name Information Center, would check if the information is locally available for the called number and use that if it was, say, less than 7 days old. In other words if the system had been called within the last 7 days, it is expected that the same session parameters can be used without requesting them again from the Name Information Center. 3) The information contained, and updated, on the Name Information Center would be such things as: .. Transport capability .. Open hours FIDONEWS 14-23 Page 6 9 Jun 1997 .. Protocol availability In other words, all the stuff that folks are trying to cram into the nodelist now. It could be in IEMSI format or similar. A Fidonet node, ZC?/IC? or designated SysOp, would be responsible for ensuring that the Name Information Center was properly updated and functional. This is only the basic outline of a concept which could be used to enhance Fidonet capability. I believe the sponsorship would be easy to obtain as the load on the Name Information Center machine would be very light as long as the mailers obeyed reasonable rules as to access. More important would be laying down the rules and mechanisms for the software to take advantage of the capabilities offered. Obviously a lot of technical detail needs to be worked out, but I believe this could be used as a basis to move FidoNet into a closer cooperation with the internet to our mutual advantage. Someone is going to object that using a single Name Information Center gives the entire system a central weakness. In answer to that I would reply that: .. Most of the entire WORLDWIDE internet services rely on only a few such centers. .. There is no reason why more than one machine could not be used and that these could be indicated in the nodelist, perhaps as comment lines, which mailer software can locate. Of course the more Name Information Centers which are created, the more difficult it becomes to keep them updated. This mini-article is intended as a START. Andy, Jo, Arjen and other developers, it's up to people like you to carry it further and make it become a reality. ----------------------------------------------------------------- SILLYSEASON Echo forming Fredric L. Rice (frice@linkline.com) The Skeptic Tank - 1:102/890.0 (818) 335-9601 24hrs N81 A new FidoNet echo -- tag named "SILLYSEASON" -- is forming and I'm soliciting participation. The forum will discuss the "Millennium" television series yet will also cover the broad spectrum of phenomena from which the series draws upon for its subject matter. The so-called "Millennium lunacy" phenomena has been commented upon and researched in growing frequency this last decade -- and for obvious reasons: The year 2,000 is only three years away. The phenomena labels the cyclic rise and fall of destructive behavior and beliefs plotted against the year number; yet it has nothing to do with numerology. It's a matter of the human psychology behind how humans contrive notions of significance when there are none. The phenomena FIDONEWS 14-23 Page 7 9 Jun 1997 is also called the "silly season" and has been the subject of several books and magazine articles. Even though the contemporary calendar is a hodge podge of badly formed months, weeks, and days, societies ever since the contemporary calendar was widely adopted have placed great significance to the year number whenever a new decade, century, or millennium comes along. Though the year numbers aren't predicated upon any meaningful event or indicate any meaningful demarcation, when a year number ends with a zero, a large portion of the so-called "Westernized societies" feel inclined to believe any damn silly thing and to "prophecy" much disaster. Sadly, many such believers work hard to bring about their images of doom and destruction in self-fulfilling prophecy. We observe the results of such beliefs in our newspapers and on television news reports. For a link to the forum, contact me and I'll set it up. I suspect that this will be a fairly low-volume forum except for times immediately following some Millennium lunacy --such as repeats of the "Heaven's Gate" mass suicides which are expected and the violent activities of self-proclaimed "militias." ----------------------------------------------------------------- Why I bother by Troy H. Cheek (1:362/708.4) Some say Fidonet is dead. Obviously, since I'm writing this, and you're reading it, and it went through Fidonet, then Fidonet isn't dead. As long as Fidonet isn't dead, it will require people to run BBS's, maintain nodelists, move messages, and moderate echoes. People who catch a lot of flak and get very little praise, but people who are required nonetheless. I've moderated a few Fidonet echomail conferences over the years for various reasons. The ones I moderate right now, however, have exactly one thing in common: They were abandoned without notice by their previous moderators. I took over echoes which were "dead" or "dying". You want to hear something funny? All of them are still active and still on the backbone. Had I not taken over, it's possible some of these echoes would no longer exist. But they would not have died because of lack of interest of the end users; they would have died because nobody with the proper knowledge bothered to update an echolist entry. In my mind, there's no doubt that the eventual demise of Fidonet will _not_ be because there are no longer any end users (lured away by the promise of the Internet and other factors), but because the people who do the vital jobs of Fidonet will give them up under the mistaken impression that they are no longer needed. Back in the early Fidonet days, the stand-alone BBS was declared dead. After all, what single BBS could possibly compete with a nation-wide network? And, hearing this solemn announcement that they were dead, FIDONEWS 14-23 Page 8 9 Jun 1997 BBS's closed shop or joined Fidonet. A funny thing happened on the way to the funeral, though. Some of the BBS's didn't listen and continued to operate for as long as they still had callers. Some operated for years. A few are _still_ operating to this day. And I've been known to call a few every now and then. Fidonet has been declared dead, killed by the Internet. In spite of being dead, there are still a lot of people using it daily. So, should we close up shop, forcing all these users to find other means of communication? Or maybe, just maybe, should we keep the doors open until the message packets actually stop coming in? By all means hook into the Internet! Learn about the World Wide Web and news services and electronic mail! Make new friends! Discover new sources of knowledge! But since you can do all these things without giving up Fidonet, why do so many people demand we do exactly that? Are they afraid that if we don't take their word that Fidonet is dead, instead of waiting for the mail packets to actually quit coming in, that it just might take years or even decades before Fidonet really ceases to exist? As long as I still have access to Fidonet, and as long as there are still echoes that interest me, I'll keep posting messages. And as long some of these echoes need somebody to send in echolist entry updates and perform the various administrivia functions, I'll still be a moderator. Troy H. Cheek, VID_GAME Echo Moderator (among others) -- |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 14-23 Page 9 9 Jun 1997 ================================================================= COLUMNS ================================================================= Lock and Load: Guerilla Marketing for BBSes (A Parenthetical Column) (Robert Parson) (1:3822/1) Every month, a major owner shuts down operations. More operations are rumored to be on the brink of going under. Everyone moans about the state of the industry. "The end is near!" Sounds familiar, doesn't it? Sure sounds like BBSes. But it isn't. This is newspaper. True, the total number of newspapers is down, as is total circulation. But revenues are at an all time high. That's because they maximize their audience. That's consultantspeak for targeting the readership. Do you really think they created "Food" sections solely because it would be a nice thing for the reader? No. They were created as a showcase for grocery ads. (Printed newspapers will never die, as some people have predicted, but that's another column for another time) BBSes can learn an important lesson here. This doesn't mean everyone should go out and create big "Food" areas on their BBSes (although we'll get to that shortly). However, you can focus some of your marketing on specific areas of your BBS. Many of you have already experienced success with Genealogy areas or possibly even dedicating your BBS to Genealogical research. Some of you look at gaming or chatting to draw in callers. But there are plenty of other topics that are ripe for the pickin'. Let's get back that "Food" section (this is going to be in a rather circular fashion, so hang with me.) Most BBSes have their messages bases numbered in some way or another. In many cases they are also alphabetized. But for the most part, they are not organized in any particular way. Pull together a text file or a bulletin of some sort that puts the message bases into topic order. Your callers can download this file or bulletin, do a search for "FOOD" and there will be a list of the message areas that are food-related. You could also include a few lines that will point them to files available on your BBS that are food-related (such as "Search the file section for 'meal' and/or 'recipe'!") While this doesn't create quite the same atmosphere as a "Food" section in the newspaper, it gives your callers a fairly easy to use index of what to look for when they are setting up their mail readers. (Sure, they can do a word search using the echo list you have available now, but this way they'll just have to do one search instead of a bunch.) FIDONEWS 14-23 Page 10 9 Jun 1997 This will also give you a more specific idea of where everything is at when you do any sort of outside promotions. For instance, you can declare "Food Month" on your BBS. You can highlight the food message bases and files in bulletins, local message areas, printed materials, in a speech to the local culinary society, on a table at the county fair, maybe even enter the local chili cookoff (using a recipe found on your BBS, of course). You can easily create and promote other "virtual sections" as well. But as I keep saying, you have to do more than leave a message on other BBSes saying "Come look at my Food Section. Think "out of the box." That's Bobspeak for get "out of the house." At the very least, you'll get a tan. But wait! There's more! Steve Prado, the Sysop of my Friendly Neighborhood BBS, Jackalope Junction (1:3822/1) this past week was a guest on KWHN-AM Fort Smith, AR talking about BBSes and International BBS Week. The tone of the interview was positive. Steve was able to pass along some good information, not just about his BBS but others in town and even a bit about Fidonet. (By the way, he adapted the sample news release I wrote a few weeks back and sent it to the radio station. For full disclosure: I happen to work there and did help set up the interview. But he did the hard work) Good job, Steve! Robert Parson ----------------------------------------------------------------- FIDONEWS 14-23 Page 11 9 Jun 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing FidoNet History series publishing the FTSC Standards and Proposal documents. FSC-0079 {RTF} is skipped due to its length {60K}. These docs have been reformatted to 70 columns where required and any tables may be askew as a result. High ASCII characters have been removed or replaced. Node numbers and telephone numbers may be out of date.] Ed. | Document: FSC-0080 | Version: 001 | Date: 01 Mar 1995 | | Mikael Stoldal, 2:201/337 Describing FidoNet with a layered model Mikael Stoldal, 2:201/337@FidoNet Introduction ============ FTS-1 tries to describe FidoNet with the OSI model, but I don't think that description is any good. I have tried to make a better description of FidoNet with the OSI model, but without success. I don't think that's possible. Instead I made my own layered model, inspired from OSI. I use seven layers with the same name as in OSI, but with Session and Transport swapped. Why this model? =============== The main goal with this model is to make FidoNet more flexible make it easier to change into newer and better protocols and data structures. It should be possible to change one layer without affecting the others. Description of the layers ========================= Physical layer -------------- The telephone network (PSTN). Link layer ---------- Modem with protocols like V.22 and V.32. This layer also include real- time error correction (V.42, MNP4) and data compression (V.42bis, MNP5). Serial communication hardware (UART). FIDONEWS 14-23 Page 12 9 Jun 1997 Network layer ------------- Serial communications drivers (FOSSIL) and file transfer protocols (Zmodem etc). Note that this layer can be divided into two sub-layers, the file transfer protocol on top on the serial communication driver; but upper layers can interact with the serial communication driver directly. Session layer ------------- Session handshake protocols (YooHoo, EMSI) implemented in mailers. This layer can reliably send files directly between two systems. It doesn't perform any routing. It doesn't know about NetMail, EchoMail etc. The upper layers uses logical addresses (node numbers), this layer performs address resolution (often by using a nodelist) to obtain the physical address (telephone number) necessary to establish a connection. The upper layers can tell if a file should be sent immediately, when appropriate or be placed on hold. When files are received, this layer tells the upper layers. Transport layer --------------- This layer handles routing and transport of NetMail, EchoMail and file attaches. The format of mailpackets is defined in this layer, except the internal structure of a packed message. A mail processor takes received NetMail and EchoMail and places it in the local message base. It also looks there for messages to send. Presentation layer ------------------ Here are the internal structure of a packed message defined. In TYPE-2, this layer is totally mixed up with the Transport layer. In new packet formats, they will hopefully be separated. Application layer ----------------- Here are the local message base (stored messages) defined. Interaction between layers ========================== Interaction between Session layer and Transport layer ----------------------------------------------------- The Session and Transport layers does only interact between sessions, not during them. The reason is that is should be possible to keep them in different programs and implement it in single tasking operating systems like MS-DOS. This doesn't prevent the Session and Transport layers from running simultaneously in a multitasking system. FIDONEWS 14-23 Page 13 9 Jun 1997 Comments ======== There is one problem with this model, how to describe the File Request server function. Sending File Requests are no problems, that's just a File Attach with a *.REQ file. The File Request server function have to be implemented directly in the Session layer. ----------------------------------------------------------------- | Document: FSC-0081 Part A | Version: 001 | Date: 01 Mar 1995 | | Mikael Stoldal, 2:201/337 A TYPE-3 Packet proposal Mikael Stoldal, 2:201/337@FidoNet Status of this document ======================= Copyright (C) 1992-1994 by Mikael Stoldal. This document may be freely distributed and copied. The standard described may be implemented by anybody. You may not distribute modified versions of this document without written permission from the author. Fido and FidoNet are registered trademarks of Tom Jennings and Fido Software. Introduction ============ This is a proposal on a new packet format for use in FidoNet and other FTNs (FTN = FidoNet Technology Network). This format can be used for both NetMail (private point-to-point mail) and EchoMail (electronic conferences). This document defines the transport layer. It also includes a presentation layer definition, but that can be changed without affecting the transport layer. It also includes a application layer (stored messages) definition, but it's not mandatory. This packet format conforms with FSC-39, rev 4. It has the PktType field in the header at the same position as TYPE-2 and it contains a capability word at the same position as TYPE-2+ (but no CW validation copy). The packet header has also the same size as in TYPE-2. This should make it easy to implement mail-processors supporting both TYPE- 2 and TYPE-3. This packet format separates the header from the message data and the header is extensible. A mail processor (the transport layer) doesn't have to look at the message data. This format eliminates most kludges currently used in TYPE-2. FIDONEWS 14-23 Page 14 9 Jun 1997 This packet format allows multiple AreaTags in EchoMail. This packet format is much more extensible than TYPE-2 and is probably easier to implement. This packet format allows up to 4 GigaBytes large messages and allows binary data in messages, this makes it possible to implement multimedia capabilities in the future. Definitions =========== Characters ---------- In this document, literal characters are written as two uppercase hexadecimal (base 16, 0..9A..F) digits following by lowercase h, e.g. "1Fh". The following abbreviations are used: "NUL" means 00h, "CR" means 0Dh and "space" means 20h (the quotation marks are not included). Basic data types ---------------- Name Length Description ---------------------------------------------------------------------- ShortInt 1 8-bit unsigned integer. Integer 2 16-bit unsigned integer, Intel 8086 byte order. LongInt 4 32-bit unsigned integer, Intel 8086 byte order. Byte 1 Field of 8 bits. Word 2 Field of 16 bits, Intel 8086 byte order. String[n] n Fixed length string of n bytes, NUL-padded. String{n} max n Variable length string of max n bytes, NUL- terminated. n includes the terminating NUL. String Variable length string, not terminated. Address ------- Field Type Description Range ---------------------------------------------------------------------- Zone Integer Zone address. 1..65535 Net Integer Net address. 1..65535 Node Integer Node address. 0..65535 Point Integer Point address or zero if boss. 0..65535 FTN address in text format -------------------------- An FTN address in text format must, unless otherwise stated, be in the Zone:Net/Node[.Point] format, where .Point must be excluded if point is zero, included otherwise. TimeStamp FIDONEWS 14-23 Page 15 9 Jun 1997 --------- A LongInt which contains the number of seconds since 00:00:00 1st January 1970 UTC. Organization ------------ An organization is a network such as FidoNet, VirNet, SigNet or InterNet. It's sometimes called "domain", but I use the term organization to avoid confusion with InterNet domains. Reserved -------- All fields marked "reserved for future extension" must be zeroed when creating/writing and ignored when reading. They might be defined by future revisions of this document. Filenames ========= It's recommended to use the naming scheme in FTS-LIST, for both NetMail and EchoMail. There should be no problem with using the same name space for TYPE-2 and TYPE-3 packets because the packet headers are enough compatible. Packet format ============= Packet header Zero or any number of data records. 00h 00h The first two bytes of a data record is used to check for the end of a packet. If both are zero, the end is reached (and the rest, if any, should be ignored). Packet header ============= Field Type Description ---------------------------------------------------------------------- PktOrig Address The node who created this packet. PktDest Address The node who should receive this packet. SubType Integer Packet contents (see below). PktType Integer Always 3. PktDate TimeStamp When the packet was created. ProdCode Integer FTSC Product Code. Programs without Product Code must use 65535. MajorVer ShortInt Major product version. MinorVer ShortInt Minor product version. Org String[16] Organization (see below). CapWord Word Capability Word (see FSC-39). Password String[8] Packet password. ExtraInfo String[4] Reserved for future extension. SubType ------- Defines what the packet contains. FIDONEWS 14-23 Page 16 9 Jun 1997 If this field is zero, data record is defined by the "Packed message" part of this document. If this field is non-zero, data record is not defined by this document. This field can be used for two things. The first is to define new packet types without having to use a new packet header. The second is to allow distribution of other things than Email. Organization ------------ This field contains the name of the organization the packet travels in. This field applies to both PktOrig and PktDest since packets are intra-organization. Packed message ============== The messages should be in chronological order in a packet. Field Type Description ---------------------------------------------------------------------- HeadSize Integer Size of the message header (see below). MsgFlags Word Message flags (see below). MsgDate TimeStamp When the message was created. MsgID LongInt Unique message identifier (see below). ReplyID LongInt Reply linkage information (see below). MsgLength LongInt Size of MsgData. MsgOrig Address The node who created this message. MsgDest Address The node who should receive this message. CharSet ShortInt Character set (see below). MsgType ShortInt Type of MsgData (see below). Area String{255} AreaTag(s) (see below). OrigAddr String{255} Origin address in text format (see below). ReplyAddr String{255} Reply linkage information (see below). FromUser String{255} Who wrote this message? ToUser String{255} To whom? Subject String{255} Subject or one filename (for file attaches and requests). Path String{65535} Path (see below). HeadExt String Header extension fields (see below). MsgData String Message data (see below). HeadSize -------- The total size of the message header (all fields except MsgData). Since this is an Integer, the header can't be bigger than 65535 bytes and Path can never reach it's maximum length (how big it can be depends on how big the rest of the header is). Message flags ------------- Bit Flag Meaning ---------------------------------------------------------------------- 0 Pvt Private message. 1 File File attach message. 2 FileReq File request message. FIDONEWS 14-23 Page 17 9 Jun 1997 3 UpdReq File update request message. 4 Direct Do not route this message. 5 Crash High priority mail. 6 Hold Hold for pickup. 7 IMM Immediate mail (highest priority). 8 RRQ Return receipt request (see below). 9 CRQ Confirm receipt request (see below). 10 IRR Is return receipt (see below). 11 Machine Message to a program (see below). 12 NoForCC CC in NetMail, NoForward in EchoMail (see below). 13 Permanent Message must not be purged by age (see below). 14 Foreign Message is from another organization. 15 reserved Reserved for future extension. RRQ, CRQ and IRR ---------------- The RRQ and CRQ flags without IRR is used to ask the software at the final destination to generate a receipt message to the sender. The receipt to an RRQ flagged message must be generated when the message is received, and this receipt must have the IRR and RRQ flags set. The receipt to a CRQ flagged message must be generated when it has been read by its addressee, and this receipt must have the IRR and CRQ flags set. A receipt must have the ReplyAddr and ReplyID fields set as if it was a reply to the original message. It's up to each network's policy to decide if all systems must support this, no system are allowed to support this or all systems are allowed but not forced to support this. Machine ------- The Machine flag indicates that this message is addressed to a program and not a human. A mail processor should store such messages as defined in the "Stored message" section later in this document so the program doesn't have to support 4711 different message base formats. The name of the program must be in the ToUser field. Carbon Copy ----------- The CC flag is used for sending a NetMail message to several nodes. Which nodes is determined by the MsgDest field. If the message is addressed to a Zone Coordinator, the message is destined for all nodes in that zone. If the message is addressed to a Region Coordinator, the message is destined for all nodes in that region. If the message is addressed to a Net Coordinator, the message is destined for all nodes in that net. If the message is addressed to a HUB, the message is destined for all nodes under that HUB. If the receiver of a CC message have other coordinators (or HUBs) below, it must send the message to them as CC's too. If the ToUser field is empty the message is considered to be addressed to the SysOp and the name is taken from the nodelist (or set to FIDONEWS 14-23 Page 18 9 Jun 1997 "SysOp"). This must be done by the system immediate before the destination (usually the destination's HUB). Permanent --------- This flag indicates that the message must not be removed when old messages is cleaned out. A new message with this flag automatically erase an old message with the same data in the Subject field. If you want to erase a permanent message without replacing it with a new, then post an empty message with the Permanent flag and the appropriate data in the Subject field. This flag can only be used in EchoMail. OrigAddr -------- This field must contain the true origin address of the message in text format followed by an "@" (40h) and the name of the originating organization. Message ID ---------- The origin address and MsgID fields are used as a unique message identifier. How the MsgID field is generated is left to the implementor, but it must be unique for each message generated on a given node in at least three years. MsgID must normally not be zero, zero is used to indicate lack of Message-ID. With this system these two fields together is unique for every message, and can be used for duplicate detection and other things. Reply linkage information ------------------------- In a reply the ReplyAddr and ReplyID fields must be identical to the origin address, and MsgID fields in the replied message. A message which is not a reply must have these fields empty. Use the ReplyAddr field to check this. Area ---- A list of one or more AreaTags in EchoMail, just a NUL in NetMail. If the list contains more than one tag, they are separated by space. 00h through 1Fh are not allowed in this field (except NUL as the terminator). Path ---- This field contains a series of addresses separated by space. The first system must place its address in this field and every system that routes the message must add its address to this field, Note that the first address in this field and the address in the MsgOrig field doesn't have to be the same. The first address must be the origin address in this format: zone:net/node.point@organization FIDONEWS 14-23 Page 19 9 Jun 1997 In the other addresses organization, zone, net and node must be omitted if same as the previous address. The other addresses must be in one of these formats: zone:net/node.point@organization zone:net/node.point net/node.point node.point .point .point must be excluded if point is zero, except when .0 stands alone. Example: 1:123/324@FidoNet sends a routed NetMail message to 2:224/546.5; 1:123/300, 1:123/0, 1:12/0, 1:1/2, 2:22/888, 2:22/0, 2:224/0, 2:224/546 and 2:224/546.3 routes the message (in that order). The path field must in this case be "1:123/324@FidoNet 300 0 12/0 1/2 2:22/888 0 224/0 546 .3" when 2:224/546.5 receives the message. Note that the message is routed via a point, that might not be so common but it's technically possible. In EchoMail, the Path field can also contain addresses suffixed by an exclamation mark ("!", 21h). This means that that node hasn't routed the message, but the message has been sent to him. Similar to SEEN- BY's in FTS-4. However, this should only be used when necessary. Never send an EchoMail message to a node listed in the Path field; regardless if the address is suffixed by an exclamation mark or not. If the message originates in a non-FTN organization, the name of the origin organization prefixed by an "@" (40h) must be placed before the address of the gateway. In such cases there may also be some other FTN addresses before the non-FTN organization name if the message have travelled from an FTN, via a non-FTN and to a FTN again. Example: someone@one.two.three in InterNet sends a routed NetMail message to 1:222/345 in FidoNet via the gateway 1:222/111 and 1:222/300. The path field must in this case be "@InterNet 1:222/111@FidoNet 300" when 2:222/345 receives the message. If there's not enough room to update the Path field (add what you should and have at least two bytes left), put a single "$" (24h) in it instead (and a space between it and the last address). This field has the same format as the PTH line specified in FSC-44 (except the "$"). Read FSC-44 for more information. HeadExt ------- This field contains zero or more NUL-terminated strings. The end of this field can be determined by the HeadSize field, but there must be a NUL after the last string anyway. If there are no strings here, there must not be any NUL either. Each string here is a header extension field. A header extension field FIDONEWS 14-23 Page 20 9 Jun 1997 contains a keyword followed by a space and some data. A header extension field can contain only a keyword with no data, in such case a space must not be used either. Inter-organization messages --------------------------- To send a message to an other organization place the final address in text format followed by an "@" (40h) and the name of the destination organization in a header extension field with the keyword "DEST" and address the message to a gateway. If the message must travel over more than one organization-border, the addresses to each gateway can be pointed out by header extension fields with the keyword "ROUTE". ROUTE fields contains addresses in the same format as DEST lines. The order of the ROUTE fields is important and the DEST field must be after the ROUTE field(s). When the gateway pointed by a ROUTE field processes the message it must change "ROUTE" to "ROUTD". Note: The gateway from your organization are pointed out by the MsgDest field so there must not be a ROUTE field for that gateway. Example: You are 34:65/12@StrangeNet and want to send a message to someone@one.two.three in InterNet. StrangeNet hasn't got any gateway to InterNet, but FidoNet has gateways to both StrangeNet and InterNet. In that case the message may have the following header extension fields: ROUTE 1:1/20@FidoNet DEST someone@one.two.three@InterNet Messages from other organizations (NetMail or EchoMail doesn't matter) must have their origin addresses (including @organization as mentioned before) stored in the OrigAddr field and the Foreign flag set. The MsgOrig field in the header must contain the address of a bidirectional gateway. The MsgID field must be generated using the message-ID in the originating organization, if that is possible. If the originating network doesn't have any message-ID that can be used to create the MsgID field, the MsgID field must be set to zero. If two identical messages (with identical message-ID) enters an FTN organization at two different gateways, they should get the same MsgID. The same counts for ReplyID. ReplyAddr must also be transferred if present in the original message. If the other organization uses a message-ID format that can't be transparently mapped to MsgID, a ORIGID header extension field is created with a direct copy of the original message-ID (both address and serial number). The same is done with reply-linkage information in a ORIGREF header extension field. This information is used if the message should be gated back to the original network. Example with message from InterNet: ORIGID ORIGREF FIDONEWS 14-23 Page 21 9 Jun 1997 Message routing --------------- The transport layer (including intermediate systems (systems handling in-transit messages)) are not allowed to change anything in the MsgDate, MsgID, ReplyID, MsgLength, CharSet, MsgType, OrigAddr, ReplyAddr, FromUser, ToUser, Subject and MsgData fields. No flags may be changed by the transport layer except the Foreign flag at gateways. The only exception is if the message have to be converted to another packet type. An intermediate system must update the Path field, both in NetMail and EchoMail. In EchoMail, the Area field may be changed. An intermediate system are allowed to add or change header extension fields. An intermediate system can add a header extension field with the keyword "Via". The Via field contains information about the system and when it processed the message. It's up to each network's policy to decide if this is allowed in NetMail, EchoMail or both. If the header is changed, the HeadSize field must be updated. EchoMail -------- This section lists the changes to FTS-4 needed to implement EchoMail with this packet format. SEEN-BY lines are not to be used. The Path field is used instead of PATH lines. The Area field is used instead of the AREA line. The MsgOrig and OrigAddr fields must contain the origin addresses of the message. A unaddressed EchoMail message must have the ToUser field empty, unless there is a good reason to put something there. The MsgDest field must be used as in NetMail. If you receive a EchoMail message not addressed to any of you addresses, you must handle it as in-transit NetMail. This makes it possible to route EchoMail through nodes not connected to the area. This can be performed inter-organization as well. Since the lack of complete SEEN-BY's, an EchoMail processor must use the single-pass technique. That means that it must export a message to all its downlinks at the same time as it tosses the message, before it goes into the local message base (it doesn't even have to get there if the area is pass-through). With this technique the tosser can do what ever it wants with the message before it stores it in the local message base since the message will never get out of it again (except when a rescan function is invoked, but the requesting system will have to stand that). A system which receives an EchoMail message with the NoForward flag set must not export that message. This flag is indented for EchoMail processors with a rescan function, all rescanned messages must have the NoForward flag set. FIDONEWS 14-23 Page 22 9 Jun 1997 The tear and origin lines have no technical meaning (the origin address is stored elsewhere) so no program is forced to create them. Additionally, a program must not require them. To distinguish EchoMail from NetMail, check the Area field. NetMail messages have empty Area fields. Cross-posting a message in several areas is preformed by storing multiple AreaTags in the Area field. If some of your downlinks don't have all the areas listed in the Area field then you must remove the AreaTags for the areas they don't have. All copies must still have the same MsgID. If you receive several messages with the same MsgID but different Area then you must join them into a single message and put all different AreaTags in the Area field (but not the same twice). Compare all fields in the header up to and including Subject (except Area) and not only MsgID. When preforming dupchecking with MsgID, compare all fields in the header up to and including Subject and not only MsgID. CharSet ------- Value Character set ---------------------------------------------------------------------- 1..99 ISO 8859 (8 bit) 100 ISO 10646 16 bit (Unicode) 101..149 Reserved for other 16 bit character sets 150 ISO 10646 32 bit 151 PC8-437 (The Original) 152 PC8-850 (Multilingual) 153 PC8-852 (Slavic) 154 PC8-860 (Portuguese) 155 PC8-863 (Canadian-French) 156 PC8-865 (Nordic) 157..199 Reserved for other 8 bit character sets 200..255 reserved PC8 means IBM's codepage (8 bit). CharSet=1 means ISO 8859-1 (Latin-1), CharSet=2 means ISO 8859-2 and so on. CharSet concerns FromUser, ToUser and Subject. It may also concern MsgData. Combined characters are built by 02h followed by a modifier and the base character. If you can't display the combined character, just ignore the modifier and display the base character unmodified. A combined character contains three bytes and are counted as three bytes. See FSC-51 for more information on this. There are a few things in FSC-51 that doesn't apply to this format: this method is allowed on all 8 bit character sets, not only Latin-1, and the byte values 80h through 9Fh are allowed. This can only be used for 8 bit character sets. Combined character can be used in FromUser, ToUser and Subject, it may also be allowed in MsgData. FIDONEWS 14-23 Page 23 9 Jun 1997 MsgLength, MsgType and MsgData ------------------------------ If the MsgData field contains nothing (MsgLength is zero), it's an empty message. An empty message must be forwarded and routed as any other message. An empty message must not be stored in the local message base (but read about the Permanent flag). If MsgType is zero, MsgData is defined by the "Message text" part of this document. If MsgType is non-zero, the MsgData field is not defined by this document. Message text ============ This part defines the presentation layer. The CharSet field in the header concerns the message text except binary extension fields. Combined characters can be used in the message text except in binary extension fields. If a 16 or 32 bit character set is used all characters are two or four bytes so all control codes must be prefixed by 00h or 00h 00h 00h. The bytes alone can be in printable character. The length of binary extension fields is still counted in bytes. All 256 byte values (including NUL) are accepted in the message text. 00h through 1Fh are control codes and must not be used to represent printable characters. A paragraph (also called "physical line") is ended with CR. 8Dh (sometimes called "Soft CR") must not be used as a line separator since it represents a printable character in some character sets. 01h first at a physical line (i.e. the first character of the message text or the character immediately after a CR) means that this line is a extension line. See below for more information. 00h first at a physical line (except in another binary extension field) indicates the start of an long binary extension field. 00h is followed by a LongInt and up to almost 4 GigaBytes of binary data. A binary extension field is not terminated in any way, it's length is stored in the LongInt (the 00h and the LongInt itself is not included in the length). 15h first at a physical line (except in another binary extension field) indicates the start of an short binary extension field. 15h is followed by a ShortInt and up to 255 bytes of binary data. A binary extension field is not terminated in any way, it's length is stored in the ShortInt (the 15h and the Integer itself is not included in the length). Attributes: 03h = Turn off all attributes 04h = Bold FIDONEWS 14-23 Page 24 9 Jun 1997 05h = Italic 06h = Underline 17h = All caps (lower case letters as small caps) 19h = Subscript 1Ah = Superscript 1Ch = Blinking 1Dh = Inverted 1Eh = Concealed Subscript automatically turns off superscript and vice versa. All other attributes can be used together. If an attribute already is on, it's turned off by the same code again. If your system doesn't support an attribute, just ignore it. CR turns off all attributes. To quote a message begin a physical line with 1Fh followed by the initials of the person you are quoting and another 1Fh. Use just two 1Fh if you don't want any initials. Successive quoting is marked with more 1Fh:s immediate after the two first ones. A quote is ended with CR. It's up to each implementor to decide how to display quoted text, but it must be possible to distinguish it from normal text. It's recommended to display it in another color if possible. You must translate the quote to the same character set used in the rest of the message. The last paragraph of the message text must be terminated by a CR (i.e. the last character of the message text must be a CR unless a binary extension field is last). Extension lines --------------- An extension line contains a keyword followed by a space and some data. A extension line can contain only a keyword with no data, in such case a space must not be used either. An extension line is ended like a paragraph. Extension lines may not contain 00h through 1Fh. If you want binary data, use a binary extension field instead. Extension lines are control information any should not be displayed to the user. If you want "hidden lines", then use the Concealed attribute rather than an extension line. Information that is relevant for the transport layer must be placed in a header extension field rather than in an extension line. Extension lines can be useful for describing a binary extension field. Currently defined extension lines --------------------------------- A extension line with the keyword FILE is used for sending files embedded in the message text. The keyword is followed by a eight digit uppercase hexadecimal number containing a TimeStamp for the file, a space and the filename. The filename can contain all chars valid for extension lines (including space) and must be at least 1 char and at most 255 chars. The file is stored in a binary extension field immediate after the FILE line. Examples: FILE AB34F657 FILE.EXT FIDONEWS 14-23 Page 25 9 Jun 1997 FILE 1234ABCD This is a filename Stored message ============== This is a description of the application layer, the local message base. It is recommended to use this format to store NetMail messages locally. It can also be used for EchoMail, but that's not necessary. Each message is stored as a single file which must have a hexadecimal number from 00000001 to FFFFFFFF as the base name and the extension MS3 (to distinguish from TYPE-2 stored messages). Messages can be stored in two ways. Either the same way as TYPE-2 with one directory for each area (including NetMail), in that case the Area field must be empty in all messages. Or all messages in the same directory with the area field used to indicate what/which area the message belongs to (or empty to indicate NetMail). The second format is useful if you normally store EchoMail in an other format and only use this format for messages with the Machine flag. Field Type Description ---------------------------------------------------------------------- SRdate TimeStamp When the message was sent or received (see below). ReplyTo LongInt Message which this replies (see below). Reply1st LongInt First reply to this message (see below). ReplyNext LongInt Next reply to this message (see below). LocalFlags Word Local flags (see below). Cost Integer Cost of sending in the lowest currency unit. HeadSize Integer Size of the message header (see below). MsgFlags Word Same as packed message. MsgDate TimeStamp Same as packed message. MsgID LongInt Same as packed message. ReplyID LongInt Same as packed message. MsgLength LongInt Same as packed message. MsgOrig Address Same as packed message. MsgDest Address Same as packed message. CharSet ShortInt Same as packed message. MsgType ShortInt Same as packed message. Area String{255}