• FidoNews 31:45 [00/08]: The Front Page

    From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    The F I D O N E W S Volume 31, Number 45 10 Nov 2014 +--------------------------+-----------------------------------------+
    | |The newsletter of the | | |
    | | FidoNet community. | | Netmail attach to (POTS): |
    | | | | Editor @ 2:2/2 (+46-31-960447) |
    | | ____________| | |
    | | / __ | Netmail attach to (BinkP): |
    | | / / \ | Editor @ 2:203/0 |
    | | WOOF! ( /|oo \ | |
    | \_______\(_| /_) | Email attach to: |
    | _ @/_ \ _ | b @ felten dot se |
    | | | \ \\ | |
    | | (*) | \ ))| |
    | |__U__| / \// | Editor: Bj”rn Felten |
    | ______ _//|| _\ / | |
    | / Fido \ (_/(_|(____/ | Newspapers should have no friends. |
    | (________) (jm) | -- JOSEPH PULITZER | +--------------------------+-----------------------------------------+


    Table of Contents
    1. FOOD FOR THOUGHT ......................................... 1
    2. FTSC INFORMATION ......................................... 2
    FTSC standing member elections, call for votes ........... 2
    Publication: FTS-5005 ................................. 4
    3. LIST OF FIDONET IPV6 NODES ............................... 14
    List of IPv6 nodes ....................................... 14
    4. JAMNNTPD SERVERS LIST .................................... 15
    The Johan Billing JamNNTPd project ....................... 15
    5. FIDONEWS'S FIDONET SOFTWARE LISTING ...................... 16
    FidoNet Software References .............................. 16
    6. SPECIAL INTEREST ......................................... 21
    Nodelist Stats ........................................... 21
    7. FIDONEWS INFORMATION ..................................... 23
    How to Submit an Article ................................. 23
    Credits, Legal Infomation, Availability .................. 25

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    FOOD FOR THOUGHT =================================================================

    Be kind to unkind people. They need it the most.

    -- RawForBeauty.com

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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    FTSC INFORMATION =================================================================


    FTSC standing member elections, call for votes
    ==============================================


    Voting for FTSC standing members commences on Sunday, 9 November,
    2014, 20:00 UTC.

    All RCs are entitled to vote. Each voter may cast one "yes"
    or one "no" vote for each candidate. Voters need not vote for all can-
    didates, a non vote will be regarded as "abstain" for that candidate
    Candidates must receive more "yes" than "no" votes to be elected.

    Although not required, voters are encouraged to consult their
    constituency before casting their votes. Debate with the candidates
    is also encouraged. No need to hurry.

    Voting ends on Sunday 23 November 2014, 20:00 UTC.

    The status of RC's will be determined by nodelist.313 for Zones that
    issue a daily nodelist. For other zones by nodelist.311. In both cases
    by the list as issued by the ZC in the zone where they reside.


    This is the list of candidates:

    Name Node nr. Nmntd by Accepted

    Ivan Agarkov 2:5020/848 RC50 Yes
    Stas Degteff 2:5080/102 RC16 Yes
    Andrew Leary 1:320/119 RC28 Yes
    mark lewis 1:3634/12 RC16 Yes
    Fred Riccio 1:132/174 RC16 Yes
    Carol Shenkenberger 1:275/100 RC16 Yes
    Alexey Vissarionov 2:5020/545 RC16 Yes

    Voters are requested to copy and paste the form below, mark a
    cross for each candidate in the "yes" or the "no" column for all
    candidates they wish to cast a vote for and post it in FTSC_PUBLIC
    addressed to "Election Coordinator with a subject of "vote".

    Once again, voters need not vote for all candidates.

    ----------------------------------------------
    | Name | Node nr | Yes| No |
    |----------------------|-------------|----|----|
    | Ivan Agarkov | 2:5020/848 | | |
    | Stas Degteff | 2:5080/102 | | |
    | Andrew Leary | 1:320/119 | | |
    | mark lewis | 1:3634/12 | | |
    | Fred Riccio | 1:132/174 | | |
    | Carol Shenkenberger | 1:271/100 | | |
    | Alexey Vissarionov | 2:5020/545 | | |
    ----------------------------------------------


    Michiel van der Vlist
    FTSC Election Coordinator 2:2/20


    -----------------------------------------------------------------
    Publication: FTS-5005
    Revision: 1
    Title: Advanced BinkleyTerm Style Outbound flow and control
    files.
    Authors: Igor Romanovsky
    Administrator and FTSC members

    Date: 2014-11-09 ---------------------------------------------------------------------- Contents: 0. Status of this document.
    1. Introduction.
    2. Definitions.
    3. Flow files.
    4. Control files.
    5. References.
    6. Contact Info. ----------------------------------------------------------------------

    0. Status of this document
    --------------------------


    This document is a Fidonet Technical Standard (FTS) - it specifies
    the current technical requirements and recommendations for FTN
    software developers, coordinators and sysops of the Fidonet network
    and other networks using FTN technology.

    This document is released to the public domain, and may be used,
    copied or modified for any purpose whatever.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in FTA-1006.


    1. Introduction
    ---------------

    BinkleyTerm Style Outbound (BSO) flow and control files have been
    used for a long time but still are not fully documented. This has
    led to software developers using different approaches that make
    changing the mailer on a FTN station rather sophisticated.
    This document combines the original ideas, introduced by Vince
    Perriello and Bob Hartman (BinkleyTerm), and Andy Elkin (T-Mail).


    2. Definitions
    --------------

    Filename case sensitivity - the case of the BSO filenames depends on
    the OS file system. Lower case filenames are prefered if supported
    by the file system. If the OS file system supports lower and upper
    case filenames, the software should be able to handle both for
    maximum compatibility. That behaviour might be controlled by a
    configuration option.

    Outbound directory (outbound) - directory where flow and control
    files are stored. Outbound directory names will have the format
    <path>[.zzz], for example F:\Mailer\Out.002\ for the zone 2
    outbound.

    Default Outbound - The Outbound directory for your zone. In this
    case a directory generic name without a quasi extension is
    functionally equal to a directory with a quasi extension equal to
    your own zone number. If we consider node 1:234/5, the default
    zone is 1, thus "outbound" and "outbound.001" are both valid
    directories for storing flow and control files and it is recommended
    to check both of them but create flow and control files only in
    first, "outbound".

    For supporting point systems an outbound sub-directory is created
    with name "<nff>.pnt", where <nff> - name of flow file as described
    below. In this directory flow and control files are created with
    name formed from point number as 8 hexadecimal digits zero-padded
    on the left. Thus information concerning to point 104/36.45 is
    stored in subdirectory "outbound\00680024.pnt" in flow and control
    files with the name"0000002d.*".

    For supporting communications with systems from a different zone, a
    number of directories are created with the same generic name chosen
    for the default directory, plus a quasi extension equal to the zone
    number expressed as 3 hexadecimal digits zero-padded on the left.
    If the zone number > 4095 then 4 hexadecimal digits are used in
    quasi extension. The last can be implemented *only* with a modern
    OS. Thus information concerning node 2:104/36 is stored in directory
    "outbound.002" in flow and control files with name "00680024.*".
    "outbound" is assumed to be a generic name.

    Domain Addressing - is an extended method of designating various
    FTNs as compared with the zone-only method previously used. Domain
    addressing adds an additional "layer" to address designation that
    represents a particular FTN. Within that FTN, zones and nets can be
    specified without conflicting with identical zones and nets in other
    FTNs. Domain Addressing is only needed if you operate in two or more
    Fido Technology Networks (FTNs) using the same Zone numbers, or you
    wish to keep different Domains' compiled nodelists separate.

    How should Outbound Areas be named when domains are used?
    As always, the outbound area for your primary address (including
    domain) is the default outbound.

    Separate Outbound Areas are needed for each Zone in each Domain.
    These take an identical stem path to the primary outbound, except
    that the name of the last sub-directory is changed to the
    <abbreviation> parameter, plus the zone extension.

    For example, if your default outbound is C:\BINKLEY\OUTBOUND
    for the outbound holding area (and you are in FidoNet), Alternet
    (zone 7) outbound mail would be held in the C:\BINKLEY\ALTERNET.007
    directory instead. Note that outbound areas for domains other than
    your primary will ALWAYS have a zone extension, and that zone
    extensions are always specified in Hexadecimal, up to .FFF (4095).
    The outbound holding areas (for Zone 1 FidoNet) would then be as
    follows:

    c:\bink\outbound (Default Outbound)
    c:\bink\outbound.002 (FidoNet Zone 2)
    c:\bink\outbound.003 (FidoNet Zone 3)
    c:\bink\outbound.004 (FidoNet Zone 4)
    c:\bink\outbound.005 (FidoNet Zone 5)
    c:\bink\outbound.006 (FidoNet Zone 6)
    c:\bink\alternet.007 (Alternet Zone 7)
    c:\bink\alternet.059 (Alternet Zone 89)
    c:\bink\eggnet.063 (Eggnet Zone 99)

    Flow file - a file with specific name and various extension that
    contains extension specific information to be sent to remote side.

    The name of flow file is formed from network and node number of the
    remote system, expressed as 4 hexadecimal digits each, zero-padded
    on the left. Thus information concerning node 104/36 is stored in
    flow and control files with name "00680024" but with different
    extension.

    Control file - same as flow for file but usually does not contain
    any information inside. Its purpose is to control behavior all
    software dealing with BSO. A reduced flow file (file does not
    contain any information inside or is of zero length) also may be
    considered as a control file.

    Restrictions - time intervals when it is not desirable to call the
    remote system. Restrictions may be external, introduced, for example
    by nodelist's information or internal due to economical or
    organizational reasons.


    3. Flow files
    -------------

    Flow files contain references to information to be sent to remote
    system. The address of remote system and name of this file has
    one-to-one correspondence. Flow files are divided by type and
    flavour.

    3.1. Types of flow file

    There are 3 types of flow files: netmail, file reference, file
    request.

    Netmail flow files are an FTS-0001 packet containing packed
    netmail as described in FTS-0001. This flow file has
    signature "ut" as 2nd and 3rd letters in extension. During a
    session this file must be dynamically renamed at the moment
    of sending to a remote system with a unique name and extension
    "pkt". The method of creating unique names is implementation
    dependent.

    This file must be transferred to the remote system at any
    successful session. If the session is terminated accidentally
    during sending, this file must be resent in the next session
    from the beginning. After successful transmission this file
    must be deleted from the outbound directory.

    Reference files consist of a number of lines (terminated by
    0x0a or 0x0d,0x0a) each consisting of a one char directive
    followed by the name of the file to transfer to the remote
    system. It has signature "lo" as 2nd and 3rd letters in the
    extension.


    Reference files consist of a number of lines (terminated by
    0x0a or 0x0d,0x0a) each consisting of the name of the file
    to transfer to the remote system. It has signature "lo" as
    2nd and 3rd letters in the extension.

    The file name is optionally prefixed with a one character
    directive that indicates what to do with the file after a
    succesful transfer.


    The following directives are documented as a standard:

    "#" - Indicates that the files should be truncated to zero-
    length after successfully sending the file to the remote
    system. This is normally only employed when sending compressed
    mail (archived mail) to the remote.

    "^" - delete the file after successfully sending the file to
    the remote system.

    "~" - skip the line from treatment. It may be useful to mark
    an already processed line.

    <none> - indicates that the file should be sent and neither be
    truncated nor deleted after sending. Listing the file with the
    full path circumvents problems with files that have a name
    starting with a character that is a known directive.


    Software may optionally recognise the following directives:

    "-" As an alternate for "^"

    "!" As an alternate for "~"

    "@" Send file, do not truncate or delete.

    It is recommended that for maximum compatibility new implemen-
    tations recognise the above directives as documented, but do
    not use them when creating reference files.

    If an indicated file does not show a path, the result depends
    on the implementation. The implementation may assume that it
    resides in the same directory as the flow file, the working
    directory or some other directory. Also, programs running in
    different tasks may make different assumptions about what is
    the default directory. Therefore it is highly recommended to
    always use the full path in reference files.

    If a file is not found, software must ignore the line and
    continue processing.

    Whether the mailer does or does not send the files listed in
    the reference file during the successful session depends on the
    flavour of the reference file.

    After successful transmission of the listed files the flow file
    must be deleted from the outbound. (But see below.) Should the
    session be terminated accidentally while sending the listed
    files, the flow file must be processed in the next session from
    the beginning.

    A file request has "req" as an extension. Information in
    request file is described in FTS-0006. File requests have the
    flavour "direct" with possible additional restrictions specific
    to the file request. Normally this file is deleted after
    receiving the requested files.

    Reduced request file has no meaning and must be ignored.

    3.2. Flavours of flow file

    THe flavour of a flow file controls mailer's behavior. It can
    initiate a poll to a remote system. Especially it is useful
    with a reduced flow file. Creating such a flow file may force
    the mailer to execute actions that are not specified in normal
    mode of operation.

    It is recommended to use only reference files for reduced flow
    files and to use the method of "touch"ing a file; creating a
    new file if there isn't one already, or changing the file date
    to current if there is a file already. The difference in mailer
    behaviour for flow and reduced flow files is described later.


    There are 5 flavours.

    Immediate has "i" as the first char in the extension. Thus the
    full extension of a netmail file is "iut" and for a reference
    file is "ilo". If a flow file with such a flavour exists the
    mailer must try to poll a remote system without taking in
    consideration any external and internal restrictions. During a
    successful session files listed in "ilo" file must be sent to
    the remote system. It is assumed that information mentioned in
    "iut" and "ilo" will be sent to the specific system. Very often
    a reduced form is used only for making a poll.

    Continuous has "c" as the first char in the extension. Thus
    the full extension of netmail file is "cut" and for a reference
    file is "clo". If a flow file with such flavour exists the
    mailer must try to poll a remote system taking in consideration

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    internal restrictions but not external ones (assuming that the
    remote system carries a CM flag). During a successful session
    files listed in "clo" file must be sent to the remote system.
    It is assumed that information mentioned in "cut" and "clo"
    will be sent to the specific system. Very often a reduced form
    is used for making a poll.

    Direct has "d" as the first char in the extension. Thus the
    full extension of a netmail file is "dut" and for a reference
    file is "dlo". If a flow file with such flavour exists the
    mailer must try to poll a remote system taking into considera-
    tion both external and internal restrictions. During a success-
    ful session files listed in "dlo" file must be sent to the
    remote system. It is assumed that information mentioned in
    "dut" and "dlo" will be sent to the specific system. Very often
    a reduced form is used for making a poll.

    Normal has "o" as the first char in extension for netmail and
    "f" for a reference file (using of "n" is considered as
    outdated). Thus the full extension of netmail file is "out" and
    for a reference file is "flo". If a flow file with such flavour
    exists the mailer must try to poll a remote system taking in
    consideration both external and internal restrictions. During a
    successful session files listed in "flo" file must be sent to
    the remote system. It is assumed that information mentioned in
    "out" and "flo" may be rerouted by specific programs (such as
    a netmail tracker) to another system.

    Hold has "h" as the first char in extension. Thus the full
    extension of a netmail file is "hut" and for a reference file
    is "hlo". A flow file with such flavour instructs the mailer
    to wait for a poll from the remote system. During a successful
    session files listed in "hlo" file must be sent if the remote
    system is the initiator of the session. If the remote system is
    not the initator of the session, it is implementation dependant
    whether the files are send or not. It is assumed that
    information mentioned in "hut" and "hlo" may be rerouted by
    specific programs (such as a netmail tracker) to another
    system.

    When flow files of more than one flavour are present for a
    particular AKA of a remote system, they should be processed in
    the following order:

    Immediate ("iut" or "ilo")
    Continuous ("cut" or "clo")
    Direct ("dut" or "dlo")
    Normal ("out" or "flo")
    Hold ("hut" or "hlo")


    3.3. Simple time chart.

    Suppose our node has working hours from 21:00 till 09:00, and
    the remote system has working hours from 17:00 till 07:00. This
    time chart indicates when a poll would be produced for
    different flavours:

    -------------------------------------------------------------------
    |12|13|14|15|16|17|18|19|20|21|22|23|00|01|02|03|04|05|06|07|08|09|
    -------------------------------------------------------------------
    i |xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|
    c |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|
    d |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--|
    f |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--|
    h |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
    -------------------------------------------------------------------

    3.4. Differences in flow and reduced flow files.

    "Real" flow file means that the system has a portion of
    information to be sent while a reduced flow file only
    expresses a desire to make a poll.

    Thus if a mailer detects a flow file in the directory, it
    must determine whether this is a real flow file or just a
    control file.

    If it is a real flow file the mailer must make a poll accor-
    ding to the flavour, send information to the remote according
    to the type of flow file and delete the flow file after
    sending all information. The mailer should not wait for the
    end of the session when deleting the flow file.

    Thus if a session is terminated accidentally or deliberately
    after sending the flow file information the mailer will return
    to its previous state without a priority flow file in the
    outbound.

    If it is a reduced flow file the mailer must make a poll
    according its flavour. The mailer has nothing to send from the
    control file and it must delete the flow file after the
    successful end of session.

    Thus if a session is terminated accidentally or deliberately
    while sending information, the mailer will return to its
    previous state with the priority flow file in the outbound.

    That is why it is not a good idea to lock flow files during
    the session.


    4. Control files
    ----------------

    4.1. bsy (busy) control file

    A bsy is a main control file that must be used by any software
    dealing with flow files in BSO. It is named the same way as
    the flow file but with the extension ".bsy".

    Any software must check this file before doing any changes
    in flow files. If a bsy file exists all changes are prohibited
    in any corresponding flow files. What the software must do in
    this case is implementation dependent.

    If a bsy file does not exist software must create it, ensure
    that it was successfully created, and then work with the flow
    files. After completing the job, software must delete the bsy
    file.

    Note to software developers:
    The most common way to create a file in many languages (eg.
    ReWrite, fopen) also quietly overwrites an existing file, so
    there's a race condition between checking, creating and
    checking. Care must be taken to use the right function and/or
    the right options to get the correct behaviour.

    During the session and before sending information from flow
    files the mailer creates the list of all AKAs presented by the
    remote system. The mailer must then check bsy files
    corresponding to the list. If a bsy file is detected the
    corresponding AKA is removed from the list. If all AKAs are
    removed due to this procedure, the session must be terminated
    with an appropriate diagnostic message.

    If a bsy file for the AKA is not present the mailer must
    create it. A bsy file is created by the mailer only after
    a successful connection with the remote mailer.

    After session - successful or not - the mailer must delete all
    created bsy files.

    After restoring the system due to a crash it is recommended to
    run a simple routine to delete all bsy files in all outbounds
    before starting any software dealing with BSO.

    It is also recommended to check the age of bsy files. It is
    reasonable to ignore and delete bsy files with an age more
    than the maximum estimated time of session multiplied on 2.
    An appropriate diagnostic message may be produced in this
    case.

    For information purposes a bsy file may contain one line of
    PID information (less than 70 characters).

    4.2. csy (call) control file

    This control file is created by a mailer when it decides
    to make poll to remote system. It is named the same way as a
    flow file but with the extension ".csy". A csy file is valid
    only for another mailer working together on the same system.
    Note that the remark regarding race conditions when creating a
    bsy file, also applies when creating a csy file.

    csy files are created for all remote AKAs as shown in the
    mailer config.
    The presence of a csy file corresponding to any remote AKA
    indicates that the mailer must stop trying to poll the remote
    system regardless of the presence of flow files.

    After a session - successful or not - and after an unsuccess-
    ful try the mailer must delete all created csy files.

    After restoring a system due to a crash it is recommended to
    run a simple routine to delete all csy files in all outbounds
    before starting any software dealing with BSO.

    It is also recommended to check the age of csy files. It is
    reasonable to ignore and delete csy files with an age more
    than the maximum estimated time of a session multiplied by 2.
    An appropriate diagnostic message may be produced in this
    case.

    For information purposes, a csy file may contain one line of
    PID information (less than 70 characters).

    4.3. hld (hold) control file

    This control file is created by a mailer or other software
    when it decides to stop trying poll a remote system.
    hld file is meaningful only for mailers. It is named the same
    way as a flow file but with the extension ".hld".

    An existing hld file is either replaced by a new one or
    edited.

    A hld file must contain a one line string with the expiration
    of the hold period expressed in UNIX-time.

    The presence an hld file corresponding to any remote AKA
    indicates that the mailer must check the content before trying
    to poll the remote system. If the expiration time is in the
    future, the mailer must stop trying to poll the remote system
    regardless of the presence of any flow files.

    The presence and content of an hld file must be checked before
    each attempt to create a poll.

    If software finds an hld file with an expiration time in past,
    it must delete that hld file.

    For information purposes the second line of an hld file may
    contain one line of PID information. (Less than 70 characters)

    4.3. try control file

    This control file is created by a mailer when a connect
    attempt is finished - successful or not. It is named the same
    way as a flow file but with the extension ".try".

    An existing try file is replaced by a new one.

    A try file must contain one line string with a diagnostic
    message. It is for information purposes only.

    For information purposes the second line of a try file may
    contain one line of PID information. ( < 70 characters)


    5. References
    -------------

    [FTS-0001] A Basic FidoNet(r) Technical Standard
    Randy Bush, 30 Sep 95.

    [FTS-0006] YOOHOO and YOOHOO/2U2
    Vince Perriello, 30 Nov 1991.

    T-Mail. Reference Manual
    Andy Elkin, 1997.

    BinkleyTerm. Reference Manual
    1987-1996 Bit Bucket Software, Co.


    6. Contact Data
    ---------------

    Igor Romanovsky
    Fidonet: 2:5022/60
    E-mail: Igor.Romanovsky@tula.net
    Administrator
    Fidonet: 2:2/20
    E-mail: administrator@ftsc.org

    History
    -------

    This document is based on FSP-1034 by Igor Romanovsky. Some minor
    technical modifications were made by Markus Reschke and other FTSC
    members. Grammer and typographical corrections were made by Dallas
    Hinton and others.


    Rev.1, 2014-11-07: Initial Release.

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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    LIST OF FIDONET IPV6 NODES =================================================================

    List of Ipv6 nodes
    By Michiel van der Vlist, 2:280/5555

    Updated 24 October 2014


    Node Nr. Sysop Type Provider Remark

    1 2:280/464 Wilfred van Velzen Native Xs4All
    2 2:280/5003 Kees van Eeten Native Xs4All
    3 2:5019/40 Konstantin Kuzov T-6in4 he.net PO4
    4 2:240/1661 Markus Reschke Native DTAG
    5 2:280/5555 Michiel van der Vlist T-AYIY SixXs
    6 1:320/219 Andrew Leary T-6in4 he.net
    7 2:221/6 Tommi Koivula T-6to4
    8 2:5053/54 Denis Mikhlevich Native TTK-Volga
    9 2:5034/16 Alexey Ignatov T-6in4 he.net
    10 2:5030/257 Vova Uralsky T-6in4 he.net
    11 1:154/10 Nicholas Bo‰l T-6in4 he.net
    12 1:154/701 Nicholas Bo‰l T-6in4 he.net
    13 2:203/0 Bj”rn Felten T-6in4 SixXs IO
    14 2:280/5006 Kees van Eeten Native Xs4All INO4
    15 3:712/848 Scott Little T-6to4 IO
    16 2:5020/545 Alexey Vissarionov Native ?
    17 2:331/51 Marco d'Itri Native? ?
    18 1:103/17 Stephen Hurd T-6in4 he.net
    19 2:5020/9696 Alexander Skovpen T-6to4

    Tunnel type:

    T-6in4 Static 6in4
    T-AYIY Dynamic AYIYA
    T-6to4 6to4

    Remarks:

    IO Incoming only (Node can not make outgoing IPv6 calls)
    INO4 No IPv4 (Node can not accept incoming IPv4 calls)
    PO4 Prefers Out on 4 (Node can make outgoing IPv6 calls,
    but is configured to try IPv4 first)

    Notes:

    To make an IPv6 connection to a node connected via 6to4 tunneling
    one may have to force the mailer into IPv6 (-6 option in binkd's
    node config). If the destination address is a 6to4 tunnel address
    (2002::/16) Windows defaults to IPv4 if an IPv4 address is present.



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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    JAMNNTPD SERVERS LIST =================================================================

    The Johan Billing JamNNTPd project

    This is a list of known JamNNTPd servers working. They are essentially
    the modern version of Bulletin Board Systems.

    You connect to them using the email client of your choice and you
    don't need any other software installed on your computer -- regardless
    of operating system -- but that favourite mail client of yours.

    Even smart phones can handle this, giving you the opportunity to get
    your daily doses of fidonet on the bus, tram or train on the way to
    your job, school or whatever.



    Updated 2012-03-11


    URL news://felten.yi.org
    Join http://felten.yi.org/join.html
    NETMAIL Yes, 2:203/2

    URL news://the-estar.com:1119
    Join http://www.easternstar.info
    NETMAIL Yes, 1:123/789

    URL news://quinnspost.nodelist.net:60119
    Join mailto:eskimo261&#64;bigfoot.com
    Join Info in group +GETACCESS+
    NETMAIL Yes, 3:640/384

    URL news://nntp.rbb.bbs.fi
    Join Info in group +GETACCESS+
    NETMAIL Yes, 2:221/361

    URL news://news.wpusa.dynip.com
    Join Info in group +GETACCESS+
    NETMAIL Yes, 1:3634/12


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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    FIDONEWS'S FIDONET SOFTWARE LISTING =================================================================

    -=:{ FidoNet Software Reference }:=-

    Type: M=Mailer T=Tosser B=BBS D=Door C=Comm/Terminal
    P=Points E=Editor I=Internet U=Utility ?=Info

    .- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -. |Software: Author |Type |URL, Contact, Ver, Notes Help Node|
    `- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -'

    Argus |MI |http://www.ritlabs.com/argus/ 2:469/84
    | | argus@ritlabs.com Tel: 373-2-246889
    | | v3.210 on Mar 20th 2001

    BinkleyTerm XE |M |http://btxe.sourceforge.net 1:1/102
    | | v2.60XE/Gamma-6 on Nov 11th 1998

    BinkD |MI |http://binkd.grumbler.org/ 2:463/69
    | | v0.9.10 on Oct 2nd 2008

    D'Bridge |MTCPE|http://www.net229.org/dbridge.htm 1:1/130
    Nick Andre |I | v3.99 on Feb 19 2014

    FIDO-Deluxe IP |MPUI |http://www.fido-deluxe.de.vu 2:2432/280
    Michael Haase | | m.haase@gmx.net
    | | v2.4 on Sep 26th 2003

    FrontDoor, FD/APX: |MTPC |http://www.defsol.se 2:201/330
    Definite Solutions | | sales@defsol.se 1:1/101
    | | v2.26SW & v2.33ml FD, v1.15 APX

    Husky Project |MTPUI|http://sf.net/projects/husky/
    | | v1.4 RC5 on Apr 24th 2006

    Mystic BBS |MTBCE|http://www.mysticbbs.com
    |I | v1.10 A31 on Apr 13th 2013

    Radius |MI |http://radius.pp.ru 2:5012/38
    (based on Argus) | | fido5012@zaural.net Tel: 7-3522-469463
    | | Last Release: v4.010 on Jan 3nd 2005

    Taurus |MI |http://taurus.rinet.ru (Russian) 2:461/70
    | |http://www.fidotel.com/taurus (English)
    (based on Radius) | | E-mail: taurus@rinet.ru
    | | v5.000 alpha on Oct 11th 2004

    Tmail |MI |http://www.tmail.spb.ru v2608
    | | Website is in Russian only

    WildCat! Interactive |MTBEI|http://www.santronics.com
    Net Server, Platinum| | sales@santronics.com
    Xpress: Santronics | | Tel: (305) 248-3204
    Software, Inc. | | AUP 451.1 on April 26th 2004
    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    Fidogate |TUI |http://www.fidogate.org
    | | Martin_Junius@m-j-s.net v4.4.10

    FMail |T |http://sourceforge.net/projects/fmail/
    | | 1.66.0.33.gpl (2013-10-17)

    JetMail: JetSys |TU |http://www.jetsys.de js@jetsys.de
    (ATARI ST only) | | v1.01 on Jan 1st 2000

    Squish |T |http://maximus.sourceforge.net/
    | | Lanuis site redirects to above
    | | Squish is part of Maximus.

    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    BBBS |BI |http://www.bbbs.net b@bbbs.net
    | | v4.00MP on Oct 25th 1999 2:22/222

    ELEBBS: The Elevator |B |http://www.elebbs.com
    Software Production | | elebbs@elebbs.com
    | | v0.10.RC1 on Jun 9th 2002

    Hermes II Project |B |http://www.hermesii.org
    | | info@HermesII.org v3.5.9 Beta Final

    Maximus BBS |B |http://maximus.sourceforge.net/
    | | v3.03
    | |Archives back online at:
    | |http://maximus.outpostbbs.net/

    MBSE BBS: |BI |http://mbse.sourceforge.net 2:280/2802
    Michiel Broek | | mbroek@users.sourceforge.net
    | | v0.60.0 on June 5th 2004

    Nexus BBS |B |http://www.nexusbbs.net
    | | groberts@nexusbbs.net
    | | v0.99.41-Beta on Oct 16th 2002
    | | [Note: No Longer under active
    | | development.]

    Proboard BBS |B |http://www.proboard.be
    | | v2.17 on Jun 9th 2002

    RemoteAccess BBS: |B |http://www.rapro.com 1:1/120
    Bruce Morse | | bfmorse@rapro.com
    | | v2.62.2SW

    Spitfire BBS: Buffalo|B |http://www.angelfire.com/ia/buffalo/
    Creek Software | | MDWoltz@aol.com 1:1/150
    | | v3.6 on Aug 20th 1999

    Synchronet BBS |BT |http://www.synchro.net
    | | sysop(at)vert(dot)synchro(dot)net
    | | v3.10L Beta
    Telegard BBS |B |http://www.telegard.net
    | | support@telegard.net
    | | v3.09g2 SP4
    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    Atlantis Software |D |http://www.jimmyrose.com/atlantis/
    | | Last Update: August 2004

    Cheepware |DU |http://outpostbbs.net
    Sean Dennis | | sean@outpostbbs.net 1:18/200

    DDS (Doorware |D |http://www.doorgames.org 1:2404/201
    Distribution System)| | ruth@doorgames.org
    Ruth Argust | |

    DoorMUD |D |http://doormud.com
    | | v0.98 Jun 1st 2002
    | | Website is down after
    | | past the splash page.

    Jibben Software |D |http://www.jibbensoftware.com
    | | scott@jibben.com
    | | 1995-99 Release dates

    John Dailey Software |D |http://www.johndaileysoftware.com
    | | support@johndaileysoftware.com

    Shining Star |D |http://www.shiningstar.net/bbsdoors/
    | | nannette@shiningstar.net

    Sunrise Doors: |D |http://www.sunrisedoors.com
    Al Lawrence | | al@sunrisedoors.com
    | | Tel: (404) 256-9518

    The Brainex System |D |http://www.brainex.com/brainex_system/
    | | stanley@brainex.com 1994-99 Releases

    Trade Wars |D |http://www.eisonline.com/tradewars/
    | | jpritch@eisonline.com
    | | v3.09 (DOS-32) in 2002

    Vagabond Software: |D |http://www.vbsoft.org 1:124/7013
    Bryan Turner | | vagabond@vbsoft.org
    | | last update: Jul 17th 2002

    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    APoint |PI |http://www.apoint-mail.de 2:2426/1210.13
    | |http://www.apoint-mail.de/indexe.htm
    | | (English Version)
    | | dirk.pokorny@apoint-mail.de
    | | v1.25

    CrossPoint (XP) |P |http://www.crosspoint.de (German Only)
    | | pm@crosspoint.de v3.12d Dec 22nd 1999

    FreeXP |P |http://www.freexp.de 2:2433/460
    | | support@freexp.de
    | | v3.40 RC3 Aug 31st 2003 (Snapshot)

    OpenXP/32 |PI |http://www.openxp.com 2:248/2004
    | | (Site is in German Only)
    | | mk@openxp.de v3.8.15 Beta Feb 10th 2004
    | | Download Page comes back 404 not found.

    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    GoldEd+ |E |http://golded-plus.sourceforge.net/
    | | 2:5080/102
    | | stas_degteff@users.sourceforge.net
    | | v1.1.5 Snapshot on Feb 28th 2003

    SqEd32 |E |http://www.sqed.de
    | | v1.15 on Dec 15th 1999

    TimEd |E |http://blizzard.dnsalias.org/fidonet
    | | mail@ozzmosis.com /timed
    | | v1.11.a5 in March 2003 3:633/267

    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    FidoIP |MTPEIU|http://sourceforge.net/projects/fidoip
    | | Maxim Sokolsky 2:5020/828.777
    | | v.0.5_1 on Jan 11 2010

    GiGo |UI |http://www.gigo.com
    | | v0109 on Jan 9th 1997

    Ifmail |UI |http://ifmail.sourceforge.net
    | | crosser@average.org 2:5020/230
    | | Ifmail is a FTN <-> E-Mail/News Gateway
    | | Program.

    Internet Rex: |UI |http://members.shaw.ca/InternetRex/
    Charles Cruden | | telnet://xanadubbs.ca 1:342/806
    (Khan Software) | | v2.29 on Oct 21st 2001

    MakeNL |U | http://hub2000.darktech.org/makenl
    | | fidonet.hub2000 [at] gmail [dot] com
    | | Fido: 1:229/2000
    | | FidoNet Nodelist Processor

    Meltdown-BBS |UI |http://meltdown-bbs.sourceforge.net/
    | | meltdown-bbs.project.petkan
    | | @spamgourmet.com
    | | Fido: 2:350/5
    | | Meltdown-BBS is an FTN <->
    | | Web/PHP/MySQL BBS forum system.

    RNtrack |U |http://sourceforge.net/projects/ftrack-as
    | |2:5080/102
    | |stas_degteff@users.sourceforge.net
    | | v1.1.4 Snapshot on Oct 09 2009

    TransNet |UI |http://www.ressl.com.ar/transnet/
    | | transnet@ressl.com.ar
    | | v2.11 on Jul 18th 1998

    TransX: Multiboard |UI |http://www.start.ca/software/multiboard
    Communications, Inc.| | Unsure about support now but Free Keys
    | | are now available. Donations accepted.
    | | v3.5 (Note: KeyGen is a Windows Program)

    Turquoise SuperStat |U |http://www.softwolves.pp.se/sw/
    | | software/turquoise
    | | peter@softwolves.pp.se
    | | Version: 3.0 on 2008-01-21


    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    National BBS List |? | http://www.usbbs.org

    Hispanic FIDO/BBS's |? | http://www.conecta2.org/pucela_bbs/
    (in Spanish only) | | (Extensive software & BBS Listings)

    +- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+

    File Archives:

    http://archives.thebbs.org http://www.filegate.net
    http://sysopscorner.thebbs.org http://www.juge.com
    http://www.dmine.com/bbscorner/ http://garbo.uwasa.fi
    http://www.simtel.net http://wuarchive.wustl.edu
    http://www.bbsfiles.com http://hobbes.nmsu.edu

    Note: most also provide FTP access
    (use ftp:// instead of http:// above)

    *=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*

    Please send corrections & additions to: Fidonews Editor

    Emeritus: Robert Couture, Ben Ritchey, Todd Cochrane,
    Frank Vest, Peter Popovich

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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    SPECIAL INTEREST =================================================================

    Nodelist Stats

    Input nodelist nodelist.311
    size 266.7kb
    date 2014-11-08

    The nodelist has 1795 nodes in it
    and a total of 2562 non-comment entries

    including 4 zones
    33 regions
    204 hosts
    165 hubs
    admin overhead 406 ( 22.62 %)

    and 195 private nodes
    73 nodes down
    93 nodes on hold
    off line overhead 361 ( 20.11 %)


    Speed summary:

    >9600 = 142 ( 7.91 %)
    9600 = 930 ( 51.81 %)
    (HST = 13 or 1.40 %)
    (CSP = 0 or 0.00 %)
    (PEP = 1 or 0.11 %)
    (MAX = 0 or 0.00 %)
    (HAY = 1 or 0.11 %)
    (V32 = 469 or 50.43 %)
    (V32B = 42 or 4.52 %)
    (V34 = 636 or 68.39 %)
    (V42 = 526 or 56.56 %)
    (V42B = 44 or 4.73 %)
    2400 = 4 ( 0.22 %)
    1200 = 2 ( 0.11 %)
    300 = 717 ( 39.94 %)

    ISDN = 109 ( 6.07 %)

    ----------------------------------------------------------
    File Req Flag Applicable software Number of systems ----------------------------------------------------------
    XA Frontdoor <1.99b 451
    Frontdoor 2.02+
    Dutchie 2.90c
    Binkleyterm >2.1
    D'Bridge <1.3
    TIMS
    Xenia
    --------------------------------------
    XB Binkleyterm 2.0 0
    Dutchie 2.90b
    --------------------------------------
    XC Opus 1.1 0 --------------------------------------
    XP Seadog 0 --------------------------------------
    XR Opus 1.03 13 --------------------------------------
    XW Fido >12M 42
    Tabby
    KittenMail
    --------------------------------------
    XX D'Bridge 1.30 539
    Frontdoor 1.99b
    Intermail 2.01
    T-Mail
    --------------------------------------
    None QMM 750 --------------------------------------

    CrashMail capable = 1034 ( 57.60 %)
    MailOnly nodes = 846 ( 47.13 %)
    Listed-only nodes = 109 ( 6.07 %)
    Other = -194 (-10.81 %)

    [Report produced by NETSTATS - A PD pgm]
    [ Revised by B Felten, 2:203/2]

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

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)
  • From FidoNews Robot@2:2/2 to All on Mon Nov 10 00:31:31 2014
    =================================================================
    FIDONEWS INFORMATION =================================================================

    How to Submit an Article

    If you wish to submit an article for inclusion in the Fidonews, here
    are some guidelines, if you send it as an attached file; the preferred
    method if you want reasonable control over how the published article
    will appear in the Fidonews:

    a) Plain text. If you could type it on your keyboard, it's probably
    quite OK. No line may be longer than 70 characters.

    b) Put a title to the article. Put the title in two times. The first
    time, on the first line, with an * before it. The second time, on
    the second line, without the * and centered. This will help in the
    format since the title with the * is removed and used in the index,
    the second line will become the headline. On the third line, put
    your name and FidoNet address, present or former. If former, you
    may want to add some other address where you can be reached for
    personal comments.

    c) Deadline for article submission is Sunday, 22:00 UTC.

    Help the Editor by following the above guides. Below are some subjects
    and the file extension for the article as set in the configuration
    file for the making of the Fidonews. Please help by putting the file
    extension of the correct subject on the file name if known.

    Ideas for Subject areas:

    Subject File | Subject File ----------------------------------|----------------------------------
    From the *C's *.css | Rebuttals to articles *.reb
    Fidonet Regional News *.reg | Fidonet Net News *.net
    Retractions *.rtx | General Fidonet Articles *.art
    Guest Editorial *.gue | Fidonet Current Events *.cur
    Fidonet Interviews *.inv | Fidonet Software Reviews *.rev
    Fidonet Web Page Reviews *.web | Fidonet Notices *.not
    Getting Fidonet Technical *.ftc | Question Of The Week *.que
    Humor in a Fido Vein *.hfv | Comix in ASCII *.cmx
    Fidonet's Int. Kitchen *.rec | Poet's Corner *.poe
    Clean Humor & Jokes *.jok | Other Stuff *.oth
    Fidonet Classified Ads *.ads | Corrections *.cor
    Best of Fidonet *.bof | Letters to the Editor *.let

    If you don't know or are not sure, send the article anyway. Put a .TXT
    on it and I'll try to figure out where it should be in the Fidonews.

    If you follow these simple guidelines, there should be little problem
    in getting your article published. If your submission is too far out
    of specs for the Fidonews, it will be returned to you and/or a message
    sent informing you of the problem. This DOES NOT mean that your
    article is not accepted. It means that there is something in it that I
    can not fix and I need your help on it.
    Send articles via e-mail or netmail, file attach or message to:

    Bj”rn Felten
    Fidonet 2:2/2 or 2:203/0
    E-Mail b @ felten dot se
    Skype file bfelten

    IMPORTANT! If you send the article via e-mail, make sure you put the
    word "fidonews" somewhere in the subject line! That way it
    will always pass the spam filter, ending up in the proper
    folder.

    Please include a message, telling me that you have sent an article.
    That way I will know to look for it.


    -----------------------------------------------------------------
    Credits, Legal Infomation, Availability

    + -- -- -- -- -- -- -- -- FIDONEWS STAFF - -- -- -- -- -- -- -- +
    | |
    | Editor: Bj”rn Felten, 2:2/2 |
    | |
    + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

    + -- -- -- -- -- -- -- - EDITORS EMERITI - -- -- -- -- -- -- -- +
    | |
    | Tom Jennings, Thom Henderson, Dale Lovell, Vince |
    | Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees, |
    | Christopher Baker, Zorch Frezberg, Henk Wolsink, |
    | Doug Meyers, Warren D. Bonner, Frank L. Vest |
    | |
    + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

    Fidonews is published weekly by and for the members of Fidonet.
    There is no copyright attached to Fidonews, though authors
    retain rights to their contributed articles. Opinions expressed
    by the authors are strictly their own. Noncommercial duplication
    and distribution within Fidonet is encouraged. Authors are
    encouraged to send their articles in ASCII text to the Editor
    at one of the addresses above.

    The weekly edition of Fidonews is distributed through the file
    area FIDONEWS, and is published as echomail in the echo FIDONEWS.

    The different articles are distributed in the file area SNOOZE.
    A service to various projects for making Fidonews available on
    the web with a more pleasing lay-out.

    These sources are normally available through your Network
    Coordinator. The current and past issues are also available from
    the following sources:

    + -- -- -- -- -- -- - FIDONEWS AVAILABILITY - -- -- -- -- -- -- +
    | |
    | File request from 2:2/2 or 2:203/0: |
    | current issue FIDONEWS |
    | back issue, volume v, issue ii FNEWSvii.ZIP |
    | articles, vol.no nn, issue ii INPUnnii.ZIP |
    | |
    | On the web: |
    | http://felten.yi.org/fidonews |
    | http://fidonews.eu |
    | |
    | The Snooze *and* the FIDONEWS echo in your newsreader: |
    | news://felten.yi.org/FIDONEWS |
    | |
    + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

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


    ** Prepared for FNEWS_PUBLISH by Azure/NewsPrep 3.0
    (c) Copyright 1996-1999 Peter Karlsson

    --- Azure/NewsPrep 3.0
    * Origin: Home of the Fidonews (2:2/2.0)