      F I D O N E W S         Volume 16, Number 13           29 March 1999
     +----------------------------+---------------------------------------+
     |  The newsletter of the     |   ISSN 1198-4589 Published by:        |
     |    FidoNet community       |   "FidoNews"                          |
     |          _                 |        +27-41-581-5913   [5:5/23]     |
     |         /  \               |                                       |
     |        /|oo \              |                                       |
     |       (_|  /_)             |                                       |
     |        _`@/_ \    _        |                                       |
     |       |     | \   \\       |   Editor:                             |
     |       | (*) |  \   ))      |        Henk Wolsink    5:7104/2       |
     |       |__U__| /  \//       |                                       |
     |        _//|| _\   /        |                                       |
     |       (_/(_|(____/         |                                       |
     |             (jm)           |   Newspapers should have no friends.  |
     |                            |                    -- JOSEPH PULITZER |
     +----------------------------+---------------------------------------+
     |             Submission address: FidoNews Editor 5:5/23             |
     +--------------------------------------------------------------------+
     |  MORE addresses:                                                   |
     |                                                                    |
     |    submissions=> editor@fidonews.org                               |
     |                  hwolsink@catpe.alt.za                             |
     +--------------------------------------------------------------------+
     |    For  information,   copyrights,   article   submissions,        |
     |    obtaining copies of FidoNews or the internet gateway FAQ        |
     |    please refer to the end of this file.                           |
     +--------------------------------------------------------------------+


                        Table of Contents
     1. EDITORIAL  ................................................  1
     2. ARTICLES  .................................................  2
        Internet newsgroup<>echomail  .............................  2
        Packet type 2  ............................................  3
     3. COLUMNS  .................................................. 21
        What's Not Happening:  Tag-Teams  ......................... 21
     4. NOTICES  .................................................. 23
     5. FIDONET BY INTERNET  ...................................... 24
     6. FIDONEWS INFORMATION  ..................................... 28
     FIDONEWS 16-13               Page 1                   29 Mar 1999


     =================================================================
                                 EDITORIAL
     =================================================================

     Greetings,

     Our summer is comming to an end, with temperatures back to normal. ;-)
     What is normal you may ask?  Temperatures acceptable to us humans that
     is.

     Happy reading,

     -----------------------------------------------------------------

     FIDONEWS 16-13               Page 2                   29 Mar 1999


     =================================================================
                                 ARTICLES
     =================================================================


     Internet newsgroup<>echomail gating service now available
     By Joe Jared (1:103/301@fidonet) joejared@webworldinc.com

     Special thanks to Remarq.com, (formerly supernews.com) for making
     control messages available to me for creation of newsgroups.  If what
     I'm told is correct on this topic, newsgroups once added, are global
     in scope.

     TO ANY MODERATORS INTERESTED:

     Your echo can be gated to the internet
     on request.  To initiate gating of your echo, simply send netmail or
     an email to one of my addresses as listed above and respond to the
     confirmation message.  Once the echo has successfully be made global,
     the moderator may assume the gating duties assuming software is
     available to do so.  The software I am currently using is compatable
     with most news servers and works with Windows 95/98/NT and is
     freeware.  The key solutions however in performing this gateway are
     available from newsgate@webworldinc.com, a listserv open to all.

     The structure as the echo would appear on the internet would be
     fidonet.*, where the * is the name of your echo.  In some cases, it
     may appear as fidonet.name.*, replacing the underscores '_' with dots
     if deemed appropriate to the heirarchy.  For example:

     SIP_ACA would be mapped to fidonet.sip.aca, because it is a part of a
     group of echoes preceded with the keyword SIP.

     Your message as the moderator of an echo would need to include
     heirarchy if it's not readily visible as well as a request to have it
     added to internet distribution.  I will then respond to the elisted
     moderator address for all cases except where the moderator is a known
     highjacker, in which case the recognized moderator will take
     precedence.  No gated echo need be elisted but it would make things
     easier for me if you as moderator elisted the echo.

     If you are in contact with moderators of other newsgroups and would
     like your echomail conference merged with their newsgroup, a request
     from both moderators are required, and can be broken on request by
     either party.

     As a moderator the ONLY requests honored will be to add "known"
     spammers to the kill list, and to add and remove it from internet
     distribution. The object of this gateway is to improve the volume of
     traffic while minimizing some of the hazards (Spam, Viruses, trojans,
     twits etc).  A gated echo will disappear from distribution if it is
     deemed to be a problematic echo (I.E. too much used cowfood involved
     in distributing it).  This service is free and as such should have
     reasonable expectations.  Initially this system will be limited in
     terms of echoes that can be gated (I'm using soon to be replaced and
     outdated tosser that only supports 2048 echoes), but I doubt this will
     FIDONEWS 16-13               Page 3                   29 Mar 1999


     be a problem for a few months.

     As a final note, once mail leaves or enters fidonet, it is no longer
     bound by policy4, nor can it be expected to, as it is no longer just
     fidonet mail.  The gateway assumes no liablity for traffic whether it
     be legal or otherwise and will take prompt action once notified of an
     repeated offense, but it cannot be expected that all internet gated
     echoes will be free of clutter.  One a positive note however, your
     echomail area will receive the exposure that it desperately needs to
     thrive and grow.


     -----------------------------------------------------------------


     Packet type 2, draft 990328
     by Goran Eriksson, 2:201/505, get@get.pp.se


     It seems to be the general opinion among FTSC members that packet type
     2+ (and possibly others like packet type 2.2 and the packet type
     proposed by FSC-48) should receive FTS status.

     To prepare for this I have written a document describing packet type 2
     as this is the basis for all of these other packet types.

     I do not expect this document to be included verbatim into a new FTS.
     Neither for packet type 2, nor for the other packet types.

     However, I hope that the FTSC will find my document useful enough to
     build the new FTS documents upon it.

     Therfore, I will post my latest draft in the following messages and
     invite you to comment on it in the NET_DEV echomail conference.

     English is a foreign language to me. Purely linguistic remarks are
     welcome, but please send them to me by netmail or e-mail.


     1. General

     A packet file of type 2 has the following general layout

      ---------------------
      |   Packet header   |
      ---------------------
      |   Packed message  |
      ---------------------
      :                   :
      ---------------------
      |  Packed message   |
      ---------------------
      | Packet terminator |
      ---------------------

     The number of packed messages may be 0 or more.
     FIDONEWS 16-13               Page 4                   29 Mar 1999


     2. Packet header

     2.1. General

     The packet header of a packet file of type 2 has the following
     general layout

      Relative byte offset                            Size in bytes
                             -----------------------
      0         00H          |    Origin Node      |  2
                             -----------------------
      2         02H          |  Destination Node   |  2
                             -----------------------
      4         04H          |        Year         |  2
                             -----------------------
      6         06H          |       Month         |  2
                             -----------------------
      8         08H          |        Day          |  2
                             -----------------------
      10        0AH          |        Hour         |  2
                             -----------------------
      12        0CH          |       Minute        |  2
                             -----------------------
      14        0EH          |       Second        |  2
                             -----------------------
      16        10H          |      Baud Rate      |  2
                             -----------------------
      18        12H          |     Packet Type     |  1
                             -----------------------
      20        14H          |     Origin Net      |  2
                             -----------------------
      22        16H          |   Destination Net   |  2
                             -----------------------
      24        18H          |    Product Code     |  1
                             -----------------------
      25        19H          |    Serial Number    |  1
                             -----------------------
      26        1AH          |      Password       |  8
                             -----------------------
      34        22H          |     Origin zone     |  2
                             -----------------------
      36        24H          |  Destination zone   |  2
                             -----------------------
      38        26H          |      Reserved       |  20
                             -----------------------

     The total size of the packet header is 58 bytes.


     2.2. Origin Node
     This field contains information about the node number of the system
     having created the packet. The field contains a 16-bit binary unsigned
     integer in the range 0-65535.

     See notes 1 and 2.

     FIDONEWS 16-13               Page 5                   29 Mar 1999


     2.3. Destination Node
     This field contains information about the node number of the system
     for which the packet was created. The field contains a 16-bit binary
     unsigned integer in the range 0-65535.

     See notes 1 and 2.

     2.4. Year
     This field contains information about the year when the packet was
     created. The field contains a 16-bit binary unsigned integer in the
     range 0-66535.

     See notes 2 and 3.

     2.5. Month
     This field contains information about the month when the packet was
     created. The field contains an 8-bit binary unsigned integer in the
     range 0-11. The following representation is used:

       Month                 represented as
       January               0
       February              1
       March                 2
       April                 3
       May                   4
       June                  5
       July                  6
       August                7
       September             8
       October               9
       November              10
       December              11

     See note 3.

     2.6. Day
     This field contains information about the day when the packet was
     created. The field contains an 8-bit binary unsigned integer in the
     range 1-31.

     See note 3.

     2.7. Hour
     This field contains information about the hour when the packet was
     created. The field contains an 8-bit binary unsigned integer in the
     range 0-23.

     See note 3.

     2.8. Minute
     This field contains information about the minute when the packet was
     created. The field contains an 8-bit binary unsigned integer in the
     range 0-59.

     See note 3.

     FIDONEWS 16-13               Page 6                   29 Mar 1999


     2.9. Second
     This field contains information about the second when the packet was
     created. The field contains an 8-bit binary unsigned integer in the
     range 0-59.

     See note 3.

     2.10. Baud Rate
     This field is filled with the 16-bit binary unsigned integer 0 by the
     system creating the packet. Any system receiving the packet may ignore
     the value of this field. For historical reasons this field is called
     Baud Rate.

     See note 2.

     2.11. Packet Type
     This field is filled with the 16-bit binary unsigned integer 2 by the
     system creating the packet. Any system receiving the packet should
     check the contents of this field. If it does not contain the 16-bit
     binary unsigned integer 2 it is recommanded that the receiving system
     regards it unsafe to unpack this packet according to the format
     specification for packet type 2. Any further actions by the receiving
     system in this case are left to the implementation.

     See note 2.

     2.12. Origin Net
     This field contains information about the net number of the system
     having created the packet. The field contains a 16-bit binary unsigned
     integer in the range 1-65535.

     See notes 1 and 2.

     2.13. Destination Net
     This field contains information about the net number of the system for
     which the packet was created. The field contains a 16-bit binary
     unsigned integer in the range 1-65535.

     See notes 1 and 2.

     2.14. Product Code
     This field contains information about the product code assigned to the
     programme creating the packet. The field contains an 8-bit binary
     unsigned integer in the range 0-255.

     Product codes are assigned to programmes by the FTSC. See FTA-1005.
     That document also contains information about what product codes to
     use by programmes which have not yet been assigned a product code by
     the FTSC.

     2.15. Serial Number
     This field may contain information about the serial number of the
     programme creating the packet. The field contains a 8-bit binary
     unsigned integer in the range 0-255. If a programme does not want to
     assign any serial number to this field it should fill this field with
     the 8-bit binary unsigned integer 0.
     FIDONEWS 16-13               Page 7                   29 Mar 1999


     2.16. Password
     This field contains information about a packet level password. The
     field contains an array of 0-8 ASCII characters, each in the range
     '0'..'9', 'A'..'Z'. The programme creating the packet should fill all
     unused bytes in this field with the 8-bit binary unsigned value 0. Any
     programme receiving a packet should ignore any bytes in this field
     after the first occurence of an byte with the value 0. The comparison
     of passwords in a received packet file is done case insensitively.

     Any programme receiving a packet with a password differing from the
     password set up between the system having created the packet and the
     system receiving it (including the absence of a password when one has
     been agreed upon) should consider the information contained in the
     packet about the system that has created as unreliable. Any further
     actions by the receiving system in this case are left to each
     implementation.

     See note 5.

     2.17. Origin Zone
     This field may contain information about the zone number of the system
     having created the packet. The field contains a 16-bit binary unsigned
     integer in the range 1-65535. If a programme does not wish to enter a
     zone number into this field it should fill it with the 16-bit binary
     unsigned value 0.

     See notes 1, 2 and 4.

     2.18. Destination Zone
     This field may contain information about the zone number of the system
     for which the packet was created. The field contains a 16-bit binary
     unsigned integer in the range 1-65535. If a programme does not wish to
     enter a zone number into this field it should fill it with the 16-bit
     binary unsigned value 0.

     See notes 1, 2 and 4.

     2.19. Reserved
     This field is filled by the programme creating the packet with an
     array of bytes with the 8-bit binary unsigned value 0. Any programme
     receiving a packet should ignore the contents of this field.


     3. Packed message format

     3.1. General
     The packed message in a packet file of type 2 has the following
     general layout

      Relative byte offset
                             -----------------------
      0         00H          |     Packet Type     |
                             -----------------------
      2         02H          |    Origin Node      |
                             -----------------------
      4         04H          |  Destination Node   |
     FIDONEWS 16-13               Page 8                   29 Mar 1999


                             -----------------------
      6         06H          |     Origin Net      |
                             -----------------------
      8         08H          |   Destination Net   |
                             -----------------------
      10        0AH          |      Attribute      |
                             -----------------------
      12        0CH          |        Cost         |
                             -----------------------
      14        0EH          |    Date and Time    |
                             -----------------------
      34        22H          |       To-name       |
                             -----------------------
                             |      From-name      |
                             -----------------------
                             |       Subject       |
                             -----------------------
                             |    Message body     |
                             -----------------------

     The total size of the packed message is variable.

     3.2. Packet Type
     This field is filled with the 16-bit binary unsigned integer 2 by the
     system creating the packet. Any system receiving the packet should
     check the contents of this field. If it does not contain the 16-bit
     binary unsigned integer 2 it is recommanded that the receiving system
     regards it unsafe to unpack this packet according to the format
     specification for packet type 2. Any further actions by the receiving
     system in this case are left to the implementation.

     See note 2.

     3.3. Origin Node
     This field contains information about the node number of the system
     having created the message. The field contains a 16-bit binary
     unsigned integer in the range 0-65535.

     See notes 1 and 2.

     3.4. Destination Node
     This field contains information about the node number of the system
     for which the message was created. The field contains a 16-bit binary
     unsigned integer in the range 0-65535.

     See notes 1 and 2.

     3.5. Origin Net
     This field contains information about the net number of the system
     having created the message. The field contains a 16-bit binary
     unsigned integer in the range 1-65535.

     See notes 1 and 2.

     3.6. Destination Net
     This field contains information about the net number of the system for
     FIDONEWS 16-13               Page 9                   29 Mar 1999


     which the message was created. The field contains a 16-bit binary
     unsigned integer in the range 1-65535.

     See notes 1 and 2.

     3.7. Attribute
     This field contains information about the attributes assigned to the
     message in question. This field is treated as a 16-bit bit mapped flag
     field with the following assignments:

             Bit             Meaning
             ---             -------
             0               Private
             1               Crash
             4               File Attached
             10              Reserved
             11              File Request
             12              Return Receipt Request
             13              Is Return Receipt
             14              Audit Request
             15              File Update Request

     See note 2.

     3.7.1. Private
     When this attribute is set the message is considered private and
     intended for the addressee only. See a separate document for the use
     of the Private attribute in echomail messages.

     3.7.2. Crash
     When this attribute is set the message is considered high-priority. A
     system that encounters a message with the Crash attribute set normally
     makes an effort to speed the delivery of the message in question if it
     is not intended for the own system. However, the actions actually to
     be taken upon receipt of a message with the Crash attribute set is
     left to each implementation.

     3.7.3. File Attached
     When this attribute is set it is supposed that one or more files are
     attached to the message. The files are transferred separately from the
     packet file in which the message with the File Attached attribute is
     contained. See also 3.12.1.

     A message with the File Attached attribute set may contain a message
     body.

     Normally a message with the File Attached attribute set must be sent
     directly to the destination system since ftn systems usually are not
     set up for the routing of non-mail files.

     3.7.4. Reserved
     This attribute bit is reserved for future use. It should not be
     checked by a programme receiving a type 2 packet.

     3.7.5. File Request
     When this attribute is set it is supposed that one or more files are
     FIDONEWS 16-13               Page 10                  29 Mar 1999


     requested from the desination system of to the message. See also
     3.12.1.

     A message with the File Request attribute set may contain a message
     body.

     Normally a message with the File Request attribute set must be sent
     directly to the destination system since ftn systems usually are not
     set up for the routing of non-mail files.

     3.7.6. Return Receipt Request
     When this attribute is set it is assumed that the sender of the
     message requests a return receipt. A Return Receipt in this connection
     means a receipt from the final destination system that the message has
     arrived there. It is left to each implementation what steps to take
     when a message with the Return Receipt Request attribute bit is
     received.

     3.7.7. Is Return Receipt
     When this attribute is set it is assumed that the message in question
     is a return receipt. It is left to each implementation what steps to
     take when a message with the Is Return Receipt attribute bit is
     received.

     3.7.8. Is Audit Request
     When this attribute is set it is assumed that the sender of the
     message requests audit receipts. An Atuidt Receipt in this connection
     means a receipt from each of the systems transporting the message in
     question on its way to the final destination that the message has
     passed there. It is left to each implementation what steps to take
     when a message with the Is Audit Request attribute bit is received.

     3.7.9. File Update Request
     When this attribute is set it is supposed that a file update is
     requested from the desination system of to the message. See also
     3.12.1.

     A message with the File Update Request attribute set may contain a
     message body.

     Normally a message with the File Update Request attribute set must be
     sent directly to the destination system since ftn systems usually are
     not set up for the routing of non-mail files.

     3.7.10. Attribute bits 2-3, 5-9
     Any programme creating a packet may set bits 2-3 and 5-9 in the
     message attribute field to 0. They should not be checked by a
     programme receiving a type 2 packet.

     These attribute bits are normally only used for information
     interchange between different programmes on the system where the
     message in question is created.

     3.8. Cost
     This field is filled with the 16-bit binary unsigned integer 0 by the
     system creating the packet. Any system receiving the packet may ignore
     FIDONEWS 16-13               Page 11                  29 Mar 1999


     the value of this field. For historical reasons this field is called
     Cost.

     See note 2.

     3.9. Date and Time
     This field is filled with a <NUL>-terminated ASCII character string
     representing the date and the time when the message in question was
     created.

     The string has the following format

      DD " " Month " " YY " " " " HH ":" MM ":" SS <NUL>

     where

      DD         = "01" | "02" | "03" | ... | "31"
      Month      = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
                   "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
      YY         = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
      HH         = "00" | .. | "23"
      MM         = "00" | .. | "59"
      SS         = "00" | .. | "59"

     The representation of the year contains the two last digits of the
     year in question. E.g. the year 1999 is represented as "99" and the
     year 2000 as "00".

     Considering the time when packet type 2 was first put into use, values
     "80".."99" is assumed to represent 1980..1999 and values "00".."79" is
     assumed to represent 2000..2079.

     The length of the string is 20 characters including the <NUL>
     termination.

     See note 3.

     3.10. To-name
     This variable length field is filled with the <NUL>-terminated
     character string representing the name of the addressee of the message
     in question. In the case the programme creating the packet does not
     want to put any actual name there, the field should be filled with a
     single <NUL> character. The maximum length of the string is 36
     characters including the <NUL> termination. E.g. the name Jim Brown is
     represented as "Jim Brown"<NUL>.

     The character set used in this field is the same as given in the
     message body (see a separate document). If no character set is given
     there, the ASCII character set is used.

     Character codes 1..31 may not be used within this field.

     3.11. From-name
     This variable length field is filled with the <NUL>-terminated
     character string representing the name of the sender of the message in
     question. In the case the programme creating the packet does not want
     FIDONEWS 16-13               Page 12                  29 Mar 1999


     to put any actual name there, the field should be filled with a single
     <NUL> character. The maximum length of the string is 36 characters
     including the <NUL> termination. E.g. the name Jim Brown is
     represented as "Jim Brown"<NUL>.

     The character set used in this field is the same as given in the
     message body (see a separate document). If no character set is given
     there, the ASCII character set is used.

     Character codes 1..31 may not be used within this field.

     3.12. Subject
     This variable length field is filled with the <NUL>-terminated
     character string representing the subject of the message in question.
     In the case the programme creating the packet does not want to put any
     actual subject there, the field should be filled with a single <NUL>
     character. The maximum length of the string is 72 characters including
     the <NUL> termination. E.g. the subject "FTS-0001" is represented as
     "FTS-0001"<NUL>.

     The character set used in this field is the same as given in the
     message body (see a separate document). If no character set is given
     there, the ASCII character set is used.

     Character codes 1..31 may not be used within this field.

     3.12.1. File specifications
     When the attribute field has bit 4, 11 and/or 15 set, the message
     subject field normally is replaced by a list of file specifications
     containing the file names the system where the message was created
     (directory, path and time information etc are discarded).

     These file specifications are transmitted to the receiving system
     according to separate documents.

     It should be noted that if the message is accompanied by an attached
     file which is to be routed via other systems before reaching the
     ultimate destination system, it may be essential for the intermediate
     systems that the message is indeed transmitted even if it is empty. By
     doing so, the intermediate systems will have a way of finding out the
     intended destination of the attached file.

     It should also be noted that especially in the case of routed file
     attaches it is essential that file names are chosen so that they can
     be directly and easily handled under the same names by the respective
     host operating systems at the intermediate systems.

     3.13. Message body
     This variable length field is filled with the <NUL>-terminated
     character string representing the message text of the message in
     question. In the case the programme creating the packet does not want
     to put any actual text there, the field should be filled with a single
     <NUL> character. The maximum length of the string is unlimited. E.g.
     the text "FTS-0001" is represented as "FTS-0001"<NUL>.

     See note 7.
     FIDONEWS 16-13               Page 13                  29 Mar 1999


     The character set used in this field is the same as given in the
     message body (see a separate document). If no character set is given
     there, the ASCII character set is used.

     Character codes 2..9,11..12,14..31 may not be used within this field.

     Character code 141 may be used within this field irrespective of the
     character set used.

     Character code 1 may be used only for the purpose given below.

     Special considerations about certain character codes apply:

     3.14. Character code 1, <SOH>
     To include extra addressing and control information, the message body
     may contain so called kludges.

     Each kludge is contained within a separate paragraph of text as
     defined in 3.16. A paragraph containing a kludge may not contain any
     other message text.

     Each paragraph containing a kludge starts with <SOH> character. The
     <SOH> character must not appear in any other position of a paragraph.

     The general format of a paragraph containing a kludge is

       <SOH><Kludge tag>": "<string><CR>

     where <string> is some sort of value related to the kludge in
     question.

     If no such value is required for a certain kludge, the general format
     of a paragraph containing such a kludge is

       <SOH><Kludge tag>":"<CR>

     Developers may introduce new kludges on an experimental basis as they
     see fit. Kludge tags which are documented in FTS documents must
     however not be used in any other way than according to those FTS
     documents. Kludge tags which are documented in FSP or FSC documents
     should not be used in any other way than according to those documents.

     Consequently each programme receiving a type 2 packet file should
     retain any unknown kludge verbatim and at an unchanged a position
     within the message body as possible. This is particularly essential
     for messages which are to be routed to another system.

     The ASCII character set is used in paragraphs containing kludges.

     This document describes three kludges: FMPT, TOPT and INTL.

     3.14.1. FMPT
     The FMPT kludge is used to give information about the point number of
     the sender of a message if that point number is not 0. If the point
     number of the sender of a message is 0 that message should not contain
     any FMPT kludge.
     FIDONEWS 16-13               Page 14                  29 Mar 1999


     The format of a paragraph containing a FMPT kludge is

       <SOH>"FMPT <point number>"<CR>

     where <point number> is the ASCII representation of the point number
     of the sender. The point number is an unsigned integer in the range
     1-65535. See note 1.

     E.g. a message from point number 1 of a certain node contains the
     following FMPT kludge

       <SOH>"FMPT 1"<CR>

     Note that the format of a paragraph containing a FMPT kludge deviates
     from the general format given above in that it does not contain any
     colon after the kludge tag.

     3.14.2. TOPT
     The TOPT kludge is used to give information about the point number of
     the addressee of a message if that point number is not 0. If the point
     number of the addressee of a message is 0 that message should not
     contain any TOPT kludge.

     The format of a paragraph containing a TOPT kludge is

       <SOH>"TOPT "<point number><CR>

     where <point number> is the ASCII representation of the point number
     of the sender. The point number is an unsigned integer in the range
     0-65535. See note 1.

     E.g. a message to point number 1 of a certain node contains the
     following TOPT kludge

       <SOH>"TOPT 1"<CR>

     Note that the format of a paragraph containing a FMPT kludge deviates
     from the general format given above in that it does not contain any
     colon after the kludge tag.

     3.14.3. INTL
     The INTL kludge is used to give information about the zone numbers of
     the sender and the addressee of a message.

     The format of a paragraph containing a INTL kludge is

       <SOH>"INTL "<destination address>" "<origin address><CR>

     where <destination address> is the ASCII representation of the
     destination address and <origin address> is the ASCII representation
     of the origin address of the message in question. These addresses is
     given on the form <zone>:<net>/<node> where <zone> is the ASCII
     representation of the zone number, <net> is the ASCII representation
     of the net number and <node> is the ASCII representation of the
     node number. Any point number information is given in FMPT and TOPT
     kludges.
     FIDONEWS 16-13               Page 15                  29 Mar 1999


     E.g. a message from address 1:123/4.5 to 2:345/6.7 node contains the
     following INTL kludge

       <SOH>"INTL 2:345/6 1:123/4"<CR>

     Note that the format of a paragraph containing a INTL kludge deviates
     from the general format given above in that it does not contain any
     colon after the kludge tag.

     INTL kludges are also often used even when both the originating and
     the destination systems are in the same zone. This gives both the
     originating system and the destination system as well as any
     intermediate routing systems unambiguous zone information even in a
     situation where one system may be active in a number of different
     zones.

     However, it is known that some programmes may route messages
     incorrectly if the INTL kludge is present in messages where both the
     originating and the destination systems are in the same zone.

     3.15. Character code 10, <LF>
     Programmes creating packet files may put <LF> characters into the
     message body. These characters should be disregarded by any programmes
     displaying the message to a user. Instead text should be formatted
     according to local conditions such as user preferences and/or
     physical/logical constraints of display equipment.

     Use of <LF> characters in the message body is discouraged. However
     <LF> characters should not be removed from the message body of
     in-transit messages.

     3.16. Character code 13, <CR>
     The <CR> character is used for the purpose of terminating paragraphs
     of text. Any programme displaying the message to a user should format
     the text accordingly.

     3.17. Character code 141, soft-<CR>
     Programmes creating packet files may put soft-<CR> characters into the
     message body. These soft-<CR> characters are usually used to prescribe
     local formatting on the system where the message in question was
     created. These characters should be disregarded by any programmes
     displaying the message to a user.

     Use of soft-<CR> characters in the message body is discouraged.
     However soft-<CR> characters should not be removed from the message
     body of in-transit messages.

     In certain character sets, character code 141 may be used for a vital
     part of the character set. If it can be assumed that the message is
     written in such a character set, character code 141 may be used and
     displayed.


     4. Packet file names
     The name of a packet file when transmitted to another system is of the
     form
     FIDONEWS 16-13               Page 16                  29 Mar 1999


      HHHHHHHH.PKT

     where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII
     character set and .PKT is the literal ".PKT" also in the ASCII
     character set.

     The value for HHHHHHHH is chosen so as to minimize the risk of any
     system receiving several packet files with the same name before all
     the previously received files of that name have been processed.


     5. Arcmail
     To minimize the storage requirements for packet files and the time and
     cost for their transmission from system to system, zero or more packet
     files may be aggregated into compressed archives (Arcmail bundles)
     using lossless compression programmes. This scheme is normally called
     Arcmail after the programme once produced by System Enhancement
     Associates.

     Such compression programmes are not specified by this standard but are
     generally available for a number of platforms.

     However, the availability of suitable decompression programmes on a
     certain system cannot be guaranteed. Therefore Arcmail should only be
     used after prior agreement between the operators of the two systems
     involved.

     When Arcmail bundles are to be used their file names when transmitted
     to another system is of the form

      HHHHHHHH.DDN

     where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII
     character set and .DD is one of the following literals

      ".MO", ".TU", ".WE", ".TH", ".FR", ".SA", ".SU"

     in the ASCII character set and N is a the ASCII representation of
     decimal digit 0-9.

     See note 6.


     7. Address interpretation
     Packet type 2 has been in use during a long period of time during
     which the number and the complexity of ftn networks have increased
     greatly.

     The addressing requirements during this period have increased. Some of
     these additional requirements have been met in packet type 2 by adding
     kludges as defined above.

     The following guidelines can be given for the interpretation of the
     ftn addresses of type 2 packet files:

     1. The origin and destination zone numbers are given explicitly in the
     FIDONEWS 16-13               Page 17                  29 Mar 1999


     packet header if they are different from 0 and the packet is created
     by a programme that is known to put that information there. One such
     programme is QMail.
     2. The origin net and node numbers are given explicitly in the packet
     header.
     3. The destination net and node numbers are given explicitly in
     the packet header.
     4. The origin and destination point numbers cannot be found in a type
     2 packet. (For the case of Fakenets see section 8.)

     The following guidelines can be given for the interpretation of the
     ftn addresses of messages in type 2 packet files:
     1. The origin and destination zone numbers are given explicitly in an
     INTL kludge in the message body if there is such a kludge. (For the
     case of Zone Gating see section 8.)
     2. If there is no INTL kludge in the message body or there is an INTL
     kludge that is not conformant with this specification the missing zone
     numbers may be assumed to be equal to the originating zone number in
     the packet header if that information is available. (For the case of
     Zone Gating see section 8.)
     3. If any zone number cannot be determined in steps 1 and 2 it may be
     assumed to be equal to the zone number of the main address of the own
     system. (For the case of Zone Gating see section 8.)
     4. The origin net and node numbers are given explicitly in the
     message header.
     5. The destination net and node numbers are given explicitly in the
     message header. (For the case of Zone Gating see section 8.)
     6. The originating point number is given in the FMPT kludge in the
     message body if there is such a kludge.
     7. If there is no FMPT kludge in the message body or there is a FMPT
     kludge that is not conformant with this specification the originating
     point number may be assumed to be 0.
     8. The destination point number is given in the TOPT kludge in the
     message body if there is such a kludge. (For the case of Zone Gating
     see section 8.)
     9. If there is no TOPT kludge in the message body or there is a TOPT
     kludge that is not conformant with this specification the destination
     point number may be assumed to be 0. (For the case of Zone Gating see
     section 8.)


     8. Fakenets
     Some existing programmes have limited support for point addressing.

     In order to still allow for points when such programmes are in use,
     sometimes a system called Fakenets or Fakenet Addressing is used.

     The operator of a ftn node using Fakenets defines a special net
     number, not included in the general nodelist, for the points under
     that node.

     That ftn node itself assumes the role of host for that net, i.e.
     assumes the address <fakenet>/0. The point systems are then assigned
     node numbers within that Fakenet. These node numbers are usually equal
     to the point numbers which they have been assigned. There may or there
     may not be a zone number assigned to the Fakenet. If a zone number is
     FIDONEWS 16-13               Page 18                  29 Mar 1999


     assigned it usually is the zone number in which the ftn node itself is
     active.

     A ftn node operating a Fakenet should use programmes which do the
     readdressing of messages so that systems outside of the Fakenet need
     not be aware of the address allocations within the Fakenet.

     E.g. assume that node 1:234/5 operates a fakenet with net number
     23450. Programmes at 1:234/5 are then expected to readdress any
     message to 1:234/5.1 to whatever node number that point system has
     within the fakenet (usually 1:23450/1). Likewise, programmes at
     1:234/5 are expected to readdress any messages from 1:23450/1 to a
     destination outside the fakenet so that they appear to originate from
     1:234/5.1 (providing that is the 4-dimensional point address which
     Fakenet node 1:23450/1 has).


     9. Zone Gating
     When two zones cover different geographical areas such as two
     different continents the technical difficulties and costs of
     establishing direct communications between two systems, one in each of
     these zones, may be considered a problem.

     For that purpose there may by administrative decisions be appointed
     one or more zone gates for message traffic from one zone to the other.
     The zone gates are systems whose operators have taken on the task of
     collecting and transmitting message traffic from the own zone to the
     foreign zone.

     To allow for such zone gating the following addressing guidelines
     apply.

     The origin address and the final destination address is given with the
     help of INTL, FMPT och TOPT kludges in the message body.

     The message header contains the node and net numbers of the
     originating system and the node and network numbers of the zone gate.


     Notes

     Note 1
     It may be noted that certain existing programmes may represent point,
     node, net and zone numbers as signed integers on the user interface
     level. E.g. node number 65535 may be represented as -1.

     Note 2
     Big-endian byte order (also known as Intel byte order) is used for 16-
     bit binary integers.

     Each field containing a 16-bit binary integer is composed of two bytes
     O0 and O1:

     +----+----+
     ! O0 ! O1 !
     -----+----+
     FIDONEWS 16-13               Page 19                  29 Mar 1999


     where O0 contains bits 0-7 and O1 bit 8-15 of the 16-bit binary
     integer.

     Bit 0 is the least significant bit and bit 15 is the most significant
     bit of the 16-bit binary integer.

     Note 3
     It may be noted that this document does not contain any information
     about how to decide the time zone used in the fields for date and time
     in a packet. It is however expected that most programmes use the local
     system time in these fields.

     Note 4
     It may be noted that certain existing programmes put additional
     restrictions on the range of valid zone numbers. E.g. the zone numbers
     may be restricted to 1-255 or 1-4095.

     Note 5
     There are a number or programmes in current use which allow also
     non-ASCII characters to be entered into the packet level password.
     E.g. character codes 128-255. There is no way within the framework of
     this common ftn practice to tell what character set is used in this
     case. Therefore it is also not possible for a programme to implement a
     general case translation algorithm for such characters.

     Note 6
     Certain existing programmes are known to produce Arcmail bundles with
     file names when transmitted where N may be an ASCII character in the
     range '0'..'9', 'A'..'F'.

     Certain other existing programmes are known to produce Arcmail bundles
     with file names when transmitted where N may be an ASCII character in
     the range '0'..'9', 'A'..'Z'.

     The capability of processing Arcmail bundles with such extended file
     names is not required by this specification and they should therefore
     only be used after prior agreement between the operators of the two
     systems involved.


     Note 7
     This specification specifies the size of the message body as
     unlimited.

     For obvious reasons, each system has some maximum size for a message
     body and for a packet file. Furthermore the file transfer protocols
     specified for ftn sessions separately may also impose maximum sizes on
     files to be transferred from one ftn system to another.

     Finally some existing programmes/platforms may have their own limits
     as to the maximum size of a message and to the maximum size of a
     packet file. E.g. some computer architectures use segmented memory and
     then the developer of a certain existing programme may have chosen to
     see to it that each data structure fits within one such segment, e.g.
     64 kilobytes. Other existing programmes may have internal limits to
     the size of the message body, e.g. 10 or 32 kilobytes.
     FIDONEWS 16-13               Page 20                  29 Mar 1999


     Procedures for splitting and recombining large messages are specified
     in other FTSC documents.


     -----------------------------------------------------------------

     FIDONEWS 16-13               Page 21                  29 Mar 1999


     =================================================================
                                  COLUMNS
     =================================================================


     What's Not Happening: Tag-Teams

          .-- -- -- -- -- -- WHAT'S NOT HAPPENING -- -- -- -- -- --.
          | There isn't always something happening on Fidonet, but |
          | there's always something which isn't happening.  This  |
          | column is dedicated to the lost causes which make Fido |
          | what it isn't today.  Published semi-occasionally...   |
          `-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --'

     Tag-Teams
     Douglas Myers, 1:270/720
     doug@mdtnbbs.com

     Occupying center ring in Fido's Circus of Lost Causes is Bob
     Morasvik's elaborate game of Tag.  The objective is to find a game
     which is already being played, and then take over the game by
     declaring himself "it."  The rank and file of Fidonet have countered
     this initiative by largely ignoring it.  This demonstration of
     applied apathy seems to be prevailing despite loud "it-fits"
     cross-posted to multiple echoes by J. Kershaw, Defensive Coordinator
     for the Morasvik team.

     The game of Tag derives its name from the practice, mostly in Zone
     1, of listing an echotag with the Elist Robot operated by Thom
     Lacosta as a prelude to distributing echomail throughout the zone.
     This elist is used by distribution systems (and anyone else
     interested) to identify the moderator of an echo and to help reduce
     the instance of duplicate echotags.

     Tag, the game, takes advantage of the fact that not all echotags are
     listed.  Many echo areas are distributed by private arrangement with
     the nodes involved and don't need to be listed, and many more are
     listed, but not necessarily with Thom LaCosta's system.  Thom's
     elist service is usually targeted by Tag players, though, because
     the North American Backbone uses this service.

     The game of Tag is played by searching for existing echoes which are
     either unlisted or listed elsewhere, and then listing the echotag
     with Thom's service, but naming oneself as moderator.  The most
     common source of unlisted existing echoes is echoes which were
     previously listed, but where the moderator has failed to keep the
     listing current.  Many moderators have found their echoes
     effectively "taken over" in this manner.

     In the past, Bob Morasvik has proven himself an adept player at this
     form of echo hijacking by such maneuvers as listing all of the
     Region 13 conferences, leaving the Region 13 coordinators the
     alternatives of either establishing new conferences or recognizing
     him as moderator of the existing conferences.

     In his latest attempt to retain top seed in the world of Tag
     FIDONEWS 16-13               Page 22                  29 Mar 1999


     players, Bob elisted ZCC-Public, an echo originating in Zone 2 but
     never elisted in Zone 1.  After successfully listing the echo with
     Thom's robot, Bob attempted to control Zone 1 distribution of the
     echo on the basis that he was the elisted moderator.  He's
     officially cut the echo from Z1B distribution, but John Souvestre
     (principle Z1B hub) simply distributes the Zone 2 echo.  Bob's
     request to have his version of ZCC-Public carried on NAB
     distribution was denied on the basis that the tag is already in use
     by many of the hubs comprising the NAB.  The net result is that Bob
     has been largely ignored.

     I'm not sure how this affects his standing as a Tag player, but Bob
     Morasvik is no longer "It," and heads the list of What's Not
     Happening on Fido.

     -----------------------------------------------------------------

     FIDONEWS 16-13               Page 23                  29 Mar 1999


     =================================================================
                                  NOTICES
     =================================================================

                       Future History

       12 May 1999
          12th Anniversary of Fido Operations in Zone 4;
          10th Anniversary of the creation of FidoNet Zone 4.

       14 - 16 May 1999
          V. BBachCon in Bleichenbach, Germany.
          For further information see: www.bbachcon.de

       24 Jul 1999
          XIII Pan American Games [through 8 Aug 99].

        9 Jun 1999
          Tenth Anniversary of the adoption of FidoNet Policy 4.07.

       10 Sep 1999
          10th anniversary of Zone 5 operations.

       26 Oct 1999
          Thirty years from release Abbey Road album by the Beatles.

       31 Dec 1999
          Hogmanay, Scotland. The New Year that can't be missed.

        1 Jan 2000
          The 20th Century, C.E., is still taking place thru 31 Dec.

        1 Jun 2000
          EXPO 2000 World Exposition in Hannover (Germany) opens.

       15 Sep 2000
          Sydney (Australia) Summer Olympiad opens.

       21 Sep 2000
          10 years of FidoNet in +7 (xUSSR)

        1 Jan 2001
          This is the actual start of the new millennium, C.E.

       -- If YOU have something which you would like to see in this
             Future History, please send a note to the FidoNews Editor.

     -----------------------------------------------------------------

     FIDONEWS 16-13               Page 24                  29 Mar 1999


     =================================================================
                            FIDONET BY INTERNET
     =================================================================

     This is a list of all FidoNet-related sites reported to the
     FidoNews Editor as of this issue; see the notice at the end.

     FidoNet:

     Homepage    http://www.fidonet.org
     FidoNews    http://www.fidonews.org             [HTML]
                 http://209.77.228.66/fidonews.html  [ASCII]
     WWW sources http://travel.to/fidonet/
     FTSC page   http://www.ftsc.org/
     Echomail    [pending]
     General     http://owls.com/~jerrys/fidonet.html
                 http://www.nrgsys.com/orb/foti
     List servers:
                 http://www.onelist.com/subscribe.cgi/fidonet-discussion

     ============

     Zone 1:       http://www.z1.fidonet.org

       Region 10:  http://www.psnw.com/~net205/region10.html

       Region 11:  http://oeonline.com/~garyg/region11/

       Region 13:  http://www.net264.org/r13.htm

         Net 264:  http://www.net264.org/

       Region 14:

         Net 282:  http://www.rxn.com/~net282/

       Region 17:  http://www.nwstar.com/~region17/

       Region 18:  http://techshop.pdn.net/fido/

       Region 19:  http://members.home.net/hbh3/r19

     Zone 1 Elist  http://www.baltimoremd.com/elist/

     Not sure where the following should be placed:

                   http://www.angelfire.com/biz/snwvlly/fido.html

     ============

     Zone 2:       http://www.z2.fidonet.org

     ZEC2:
     Zone 2 Elist: http://www.fbone.ch/echolist/

       Region 20:  http://www.fidonet.pp.se (in Swedish)
     FIDONEWS 16-13               Page 25                  29 Mar 1999


       Region 23:  http://www.fido.dk (in Danish)

       Region 24:  http://www.swb.de/personal/flop/gatebau.html (German)
         Fido-IP:  http://home.nrh.de/~lbehet/fido (English/German)

       Region 25:  http://www.bsnet.co.uk/net2502/net/

        Region 26: http://www.nemesis.ie
           REC 26: http://www.nrgsys.com/orb

       Region 27:  http://telematique.org/ft/r27.htm

       Region 29:  http://www.rtfm.be/fidonet/  (French)

       Region 30:  http://www.fidonet.ch  (German)

       Region 33:  http://www.fidoitalia.net (Italian)

       Region 34:  http://www.pobox.com/cnb/r34.htm  (Spanish)
           REC34:  http://pobox.com/~chr

       Region 36:  http://www.geocities.com/SiliconValley/7207/

       Region 38:  http://public.st.carnet.hr/~blagi/bbs/adriam.html

       Region 41:  http://www.fidonet.gr (Greek/English)

       Region 42:  http://www.fido.cz

       Region 48:  http://www.fidonet.org.pl

       Region 50:  http://www.fido7.com/  (Russian)
        Net 5010:  http://fido.tu-chel.ac.ru/  (Russian)
        Net 5015:  http://www.fido.nnov.ru/  (Russian)
        Net 5030:  http://kenga.ru/fido/  (Russian & English)
        Net 5073:  http://people.weekend.ru/soa/  (Russian)

     ============

     Zone 3:       http://www.z3.fidonet.org

     ============

     Zone 4:

       Region 90:  http://visitweb.com/fidonet
         Net 903:  http://www.playagrande.com/refugio
         Net 904:  http://members.tripod.com/~net904 (Spanish)

     ============

     Zone 5:       http://www.eastcape.co.za/fidonet/index.htm

     ============

     Zone 6:       http://www.z6.fidonet.org
     FIDONEWS 16-13               Page 26                  29 Mar 1999


       Region 65:  http://www.cfido.com/fidonet/cfidochina.html (Chinese)

     ============

     Pages listed above are as submitted to the FidoNews Editor,
     and generally reflect Zone and Regional Web Page sites.  If
     no Regional site is submitted, the first Network page from
     that Region is used in its place.  Generally, Regional pages
     should list access points to all Networks within the Region.

     TCP/IP accessible node access information should be submitted
     to the FidoNews Editor for inclusion in their Region or Zone.

                      -----------oOo-------------

                       Fidonet Via Internet Hubs

     Node#      | Operator          | Facilities (*) | Speed | Basic Rate
     -----------+-------------------+----------------+-------+------------
     1:12/12    | Ken Wilson        | FTP            | T1    | $24mo.
     1:13/25    | Jim Balcom        | FTP            | 56k   | $20mo.
     1:106/1    | Matt Bedynek      | FTP,VMoT,UUE   | 64k   | $5/$15mo.
     1:106/6018 | Lawrence Garvin   | FTP,VMoT       | 64k   | $5/mo.
     1:107/451  | Andy Knifel       | FTP, VMoT, UUE | 33.6  | n/c
     1:140/12   | Bob Seaborn       | FTP            | T1    | $5/$20
     1:270/101  | George Peace      | FTP            | T1    | $30mo.
     1:271/140  | Tom Barstow       | UUE            | T1    | n/c
     1:275/1    | Joshua Ecklund    | UUE            | 28.8  | $10/yr.
     1:280/169  | Brian Greenstreet | FTP            | 33.6  | $2mo.
     1:2401/305 | Peter Rocca       | FTP,UUE        | T1    | unkn
     1:2424/10  | Alec Grynspan     | FTP,UUE        | T1    | n/c
     1:2604/104 | Jim Mclaughlin    | FTP,VMoT,UUE   | 33.6  | $1mo.
     1:2624/306 | D. Calafrancesco  | VMoT           | 33.6  | $15yr.
     1:345/0    | Todd Cochrane     | FTP            | T1    | n/c
     1:346/250  | Aran Spence       | FTP,UUE        | T1    | $10mo.
     1:396/45   | Marc Lewis        | UUE            | 33.6  | $26/yr.
     1:3651/9   | Jerry Gause       | FTP,VMoT       | 33.6  | $3/$6
     1:396/1    | John Souvestre    | FTP,VMoT       | T1    | $15mo.
     2:335/535  | Mario Mure        | VMoT,UUE       | 64k   | n/c
     2:254/175  | Alex Kemp         | UUE            | 56k   | n/c
     2:284/800  | Jeroen VanDeLeur  | FTP,UUE        | 64k   | n/c
     2:335/610  | Gino Lucrezi      | UUE            | 33.6  | n/c
     2:469/84   | Max Masyutin      | VMoT           | 256k  | n/c
     2:2411/413 | Dennis Dittrich   | UUE            | 64k   | n/c
     2:2474/275 | Christian Emig    | UUE            | 64k   | unkn
     3:633/260  | Malcolm Miles     | FTP            | 33.6  | n/c
     4:905/100  | Fabian Gervan     | VMoT, UUE      | ???   | n/c
     5:7104/2   | Henk Wolsink      | FTP            | 28.8  | n/c
     --
     * FTP  = Internet File Transfer Protocol
     * VMoT = Virtual Mailer over Telnet (various)
     * UUE  = uuencode<->email type transfers
     [I'm only cataloging transfer methods, eg, ftp, email, telnet.
     Specific programs using these protocols are no longer being listed.
     Contact the system operators for details of which programs they have
     available.]
     FIDONEWS 16-13               Page 27                  29 Mar 1999


     Compiled by C. Ingersoll, 1:2623/71, (609)814-1978, fbn@dandy.net
     Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews.

     -----------------------------------------------------------------

     FIDONEWS 16-13               Page 28                  29 Mar 1999


     =================================================================
                           FIDONEWS INFORMATION
     =================================================================


      ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------

       Editor: Henk Wolsink

       Editors Emeriti: Tom Jennings, Thom Henderson, Dale Lovell,
                        Vince Perriello, Tim Pozar, Sylvia Maxwell,
                        Donald Tees, Christopher Baker, Zorch Frezberg

       "FidoNews Editor"
           FidoNet  5:5/23
           BBS  +27-41-581-5913,  2400/9600/V34

        more addresses:
           Henk Wolsink -- 5:7104/2,    hwolsink@catpe.alt.za

        (Postal Service mailing address)
           FidoNews Editor
           P.O. Box 12325
           Port Elizabeth,
           6006
           South Africa

         ------------------------------------------------------

     FidoNews is published weekly by and for the members of the FIDONET
     INTERNATIONAL AMATEUR ELECTRONIC MAIL system.  It is a compilation
     of individual articles contributed by their authors or their
     authorized agents.  The contribution of articles to this compilation
     does not diminish the rights of the authors.  OPINIONS EXPRESSED in
     these articles ARE THOSE OF THE AUTHORS and not necessarily those of
     FidoNews and/or the Editor.

     Authors retain copyright on individual works; otherwise FidoNews is
     Copyright (C) 1999 Henk Wolsink.  All rights reserved.  Duplication
     and/or distribution permitted for noncommercial purposes only.  For
     use in other circumstances, please contact the original authors, or
     the Editor.

                             =*=*=*=*=*=*=*=*=

     OBTAINING COPIES: The most recent issue of FidoNews in electronic
     form may be obtained from the FidoNews Editor via manual download or
     file-request, or from various sites in FidoNet and the Internet.
     PRINTED COPIES may be obtained by sending SASE to the above postal
     address.  File-request FIDONEWS for the current Issue.  File-request
     FNEWS for the current month in one archive.  Or file-request specific
     back Issue filenames in distribution format [FNEWSGnn.ZIP] for a
     particular Issue.  Monthly Volumes are available as FNWSmmmy.ZIP
     where mmm = three letter month [JAN - DEC] and y = last digit of the
     current year [9], i.e., FNWSJAN9.ZIP for all the Issues from Jan 99.

     FIDONEWS 16-13               Page 29                  29 Mar 1999


     Annual volumes are available as FNEWSn.ZIP where n = the Volume number
     1 - 16 for 1984 - 1999, respectively. Annual Volume archives range in
     size from 48K to 1.4M.


        INTERNET USERS: FidoNews is available via:

                        http://www.fidonews.org
                **      http://www.fidonet.org/fidonews.htm
                **      ftp://ftp.fidonet.org/pub/fidonet/fidonews/
                        ftp://ftp.irvbbs.com/fidonews/
                        ftp://ftp.nwstar.com/Fidonet/Fidonews

        And in non-English formats via:

                **      http://www.hvc.ee/pats/fidonews (Estonian)
                        http://www.fidonet.pp.se/sfnews (Swedish)

       **  LINK HAS NOT BEEN UPDATED

                                   *=*=*

     You may obtain an email subscription to FidoNews by sending email to:

                        jbarchuk@worldnet.att.net

     with a Subject line of: subscribe fnews-edist

     and no message in the message body. To remove your name from the
     email distribution use a Subject line of: unsubscribe fnews-edist
     with no message to the same address above.

                                      *

     You may retrieve current and previous Issues of FidoNews via FTPMail
     by sending email to:

                        ftpmail@fidonews.org

     with a Subject line of: help

     and FTPMail will immediately send a reply containing details and
     instructions. When you actually make a file request, FTPMail will
     respond in three stages. You find a link for this process on
     www.fidonews.org.

                                    *=*=*

     You can read the current FidoNews Issue in HTML format at:

                        http://www.fidonews.org

     and    http://www.fidonet.dynip.com/public/fidonews/default.htm

     and in the FIDONEWS echo.

     FIDONEWS 16-13               Page 30                  29 Mar 1999


     STAR SOURCE for ALL Past Issues via FTP and file-request -
     Available for FReq from 1:396/1 or by anonymous FTP from:

                        ftp://ftp.sstar.com/fidonet/fnews/

     Each yearly archive also contains a listing of the Table-of-Contents
     for that year's issues.  The total set is currently about 13 Megs.

                                  =*=*=*=

     The current week's FidoNews are now also available almost immediately
     after publication on the FidoNews Editor homepage on the World Wide
     Web at:

                        http://209.77.228.66/fidonews.html

     There are also links there to jim barchuk's HTML FidoNews source and
     to John Souvestre's FTP site for the archives.  There is also an
     email link for sending in an article as message text.  Drop on over.

                            =*=*=*=*=*=*=*=*=

     SUBMISSIONS: You are encouraged to submit articles for publication in
     FidoNews. Article submission requirements are contained in the file
     ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
     from 5:5/23 [5:7104/2] as file "ARTSPEC.DOC".  ALL Zone Coordinators
     should have copies of ARTSPEC.DOC. Please read it.

     "Fido", "FidoNet" and the dog-with-diskette are U.S. registered
     trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
     and are used with permission.

                  "Disagreement is actually necessary,
                   or we'd all have to get in fights
                   or something to amuse ourselves
                   and create the requisite chaos."
                                     -Tom Jennings

     -----------------------------------------------------------------

