• Fido.doc cont

    From Jeff Binkley@1:226/600 to All on Mon Oct 22 05:26:00 2007
    Routing Mail to Your Hub
    Normally, netmail is sent directly from one site to another. While this
    is fast, it can also be expensive. A majority of Fido nodes will opt to
    route the mail through their hub on the assumption his hub will route
    it to the next step and so on. While it is slower way to pass the mail
    it is certainly more cost effective.

    How do I tell PCBoard to route the mail. To answer that question we
    must revisit the event setup in PCBoard. You'll recall we setup the
    zone mail hour as an event. Well, we will do something very similar
    in order to route mail. Add the following event to your system:

    Batch Begin End Last
    Act Mod File Time Time SMTWTFS Date Date
    ═══ ═══ ════════ ═════ ═════ ═══════ ════════ ════════
    1) Y F ALLDAY 00:00 23:59 YYYYYYY 00-00-00

    Notice the "Mod" column has an F for (F)ido Event. With a Fido event
    you are defining the way PCBoard will behave during the begin time and
    the end time of the event (midnight to 11:59pm in this example). In
    other words, we are going to alter the way PCBoard behaves during this
    time period. How are these actions defined? Good question and one that
    is answered by pressing F2 while the selection bar or cursor is on this
    line. When you press F2 you see a screen like the following:

    Fido Verb Parameters
    ═══════════════════ ════════════════════════════════════════════

    This is the screen where the activities or characteristics of the event
    is defined. Pressing F2 while the selection bar is in the Fido Verb
    column brings up a list of valid Fido verbs. Press F2 to see this list.

    │Allow-Route-To │
    │Poll │
    │Hold │
    │Crash │
    │Route-To │
    │FREQ │

    Cursor down to "Route-To" and press ENTER. Now TAB over to the
    Parameters column. In this column we tell it how to route the mail by
    listing what mail will be routed and where it is to be routed. We want
    to route all mail so we use the wildcard (*:*/*). The mail will be
    routed to our hub which for the sake of this example is 1:311/0. Our
    entry now looks like this:

    Fido Verb Parameters
    ═══════════════════ ════════════════════════════════════════════
    1) Route-To *:*/* 1:311/0

    Notice how we separated the two addresses with a space. This is
    IMPORTANT. It is also important to list both addresses. If you do not,
    PCBoard will not route the netmail.

    Exit the editor by pressing ESC and choosing to save changes. Also do
    the same in the event editor. Finally, return back to the call waiting
    screen where we can begin testing the netmail to make sure it is routing

    Log in to the system, join the netmail conference and leave the
    following message:

    TO: SYSOP@1:311/40
    SUBJ: Testing Route Capabilities
    Testing 1...2...3...

    Exit and save the message. Now logoff. While at the call waiting
    screen press ALT-F for the Fido Menu and finally select "Scan for
    outbound mail." After a brief pause and a screen flash you will be
    return back to the call-waiting screen. Press 5 to view the outbound
    queue where and entry resembling the following appears:

    ║ View/Modify Outbound Queue ║
    ║ 1 ║
    ║ Filename : 03172429.PKT ║
    ║ Address : 1:311/0 ║ <--- Notice where this packet
    ║ ║ is being sent.
    ║ F) Flag : NORMAL ║
    ║ S) Send This Packet ║
    ║ D) Delete ║
    ║ N) Next ║
    ║ P) Previous ║
    ║ C) Clear Failed Connect 0 ║
    ║ ║
    ║ Enter selection : ║

    Look at the address where PCBoard will send the packet. Is it your hub?
    If not, you've misconfigured something in the event; Double check the

    Once the address is verified to be correct, go ahead an delete this
    packet. There is no sense in sending out this message because it really
    lacks any purpose other than for verification of your configuration.
    Congratulations on a job well done.

    Setting Up Echo Mail Areas
    The procedure for adding the conferences for Fido echo areas include the
    following steps:

    1. Get a FIDONET.NA file from your coordinator.
    2. Determine what areas you want to carry
    3. Prepare PCBoard to handle the increased conference load
    4. Use UUUTIL.EXE to add the additional conferences.

    That is the shortened list of what you have to do. Over the next few
    paragraphs, detailed descriptions of each task is given.

    1. Talk to your net coordinator. He or she will have a copy of the
    FIDONET.NA file which lists echo areas available. Preferably, the
    copy of the file received contains only those areas carried by the
    hub. If not, ask for a list of those too.

    2. The FIDONET.NA file is nothing more than an ASCII file with each
    line dedicated to an echo area. On the left of the line is the
    shortened name for the area. This particular name is commonly
    referred to as the AREA TAG. On the right is a brief description
    of the area and what topics are discussed there.

    The next task is to trim down the .NA list to include only those
    areas which interest you or your callers. Don't be afraid to be
    picky here as there are costs involved for your hub and maybe
    yourself for pulling in a feed. Trimming down the .NA list is done
    by loading the file into a text editor--any editor will do. When
    you see an area you do not want, delete the line (CTRL-Y usually
    works). When done, save the file and exit the editor. That's all
    there is to it.

    Look at this sample segment of the FIDONET.NA file:

    ALTMED Alternative Medicine
    AMIGA Amiga International Echo
    AMIGAGAMES Amiga Games
    AMIGASALE Amiga Hardware and Software ForSale Conference
    AMIGA_CDROM International AMIGA Discussions

    Deciding I do not want the AMIGAGAMES area, I'll use the text editor
    to make this section resemble the following:

    ALTMED Alternative Medicine
    AMIGA Amiga International Echo
    AMIGASALE Amiga Hardware and Software ForSale Conference
    AMIGA_CDROM International AMIGA Discussions

    See how easy that was!

    3. Next we must confirm the PCBoard setup is properly configured for
    the hundred or maybe even 700 new conferences. Make a
    determination for a starting conference number; most SysOps elect
    to start at an even number of 100. Say for example the highest
    conference currently in use is 78. The common thing to do is to
    start the Fido conferences at 100.

    Once the starting conference number is determined, find out how
    many areas you'll be carrying and add it to the starting conference
    number. As an example let's assume you'll start the Fido
    conferences at 200 and will be adding 212 areas. This makes your
    highest conference 412 so check PCBSetup | Configuration Options |
    Messages to see if the "Highest Conference Desired" is set to the
    an appropriate value.

    If you have to change the number, load System Manager | User Info
    File Maintenance | Change Conference Allocation to ensure the
    USERS.INF file is up-to-date is upgraded too.

    4. A utility is included with the PCBoard package called UUUTIL. With
    this utility the tedious task of setting up conferences is greatly
    simplified. Consult the following checklist before continuing:

    1. You have a FIDONET.NA file and have trimmed it down to list
    only those areas you desire to carry.

    2. An adequate number of conferences is configured in PCBSetup |
    Configuration Options | Messages.

    3. You know the starting conference number for the Fido

    4. You have a copy of UUUTIL.EXE and know its location.

    Now you're ready to import the new Fido conferences to your system.
    The command line for UUTIL will be:

    UUUTIL /START:[conf] /FIMPORT:[fidonet.na] /MSGS:[path]

    The conference number entered after the /START parameter must be
    your starting conference number for the Fido conferences.

    The next parameter passed is /FIMPORT. This parameter tells UUUTIL
    where it can find the FIDONET.NA file. The .NA file has
    information about conference descriptions and tagnames. The
    tagname is used to generate the message base filenames, while the
    descriptions of each tag are used for the actual conference names.

    Finally, the last parameter tells UUUTIL where to store the message
    bases for the new conference. The following structure will be used


    Therefore, if you tell UUUTIL to store the messages in D:\FIDO\,
    the message base for the ALTMED tag is stored in the D:\FIDO\A\
    subdirectory because the tag begsins with an A.

    NOTE: If you run UUUTIL and the screen clears but nothing seems to
    have happened, make sure you are running UUUTIL from a
    directory where a valid PCBOARD.DAT for your system exists.

    When UUUTIL is running, you will see text indicating the progress
    of the import which resembles the following:

    Checking conference 100 ...
    Inserting (!CHINESE) as conference 100 ...

    Checking conference 101 ...
    Inserting (12_STEPS) as conference 101 ...

    Checking conference 102 ...
    Inserting (4DOS) as conference 102 ...

    Checking conference 103 ...
    Inserting (60S_70S_PROGROCK) as conference 103 ...

    Once a conference is "inserted" by UUUTIL, the following has

    1) The conference name has been updated

    2) The message base location has been updated. The format for
    the messages file location is the first 5 characters of the
    tag name followed by the conference number (e.g. TTTTT###).
    Assuming the MSGS path was specified as D:\FIDO\, the message
    base for the ALTMED conference is D:\FIDO\A\ALTME109.

    3) The "Echo Mail in Conference" field is set to Y and the "Type
    of Netmail Conference" field is set to 5.

    4) Fido's configuration file has been updated with the
    appropriate tag information.

    What AreaFix Is and How to Use It
    AreaFix is a function of hubs allowing you to subscribe and unsubscribe
    to Fido areas via netmail. The benefits to using this method are

    * The request is handled automatically which means you are not waiting
    for the coordinator to process it.

    * A current list of conferences you ARE carrying and those you CAN
    carry is always available.

    * You can make changes as often as you desire. All that is required
    is for you to send a netmail message to your hub.

    We mention that an AreaFix request is simply a netmail message. If that
    is the case, there must be something special that allows the hub to
    differentiate this netmail message from others. Addressing the message
    to "AREAFIX" is the key.

    Because AreaFix requests alter your configuration, they are typically
    protected by passwords different from your logon password. The AreaFix
    password is passed in the subject line of the message. It's that

    The following example illustrates how to address an AREAFIX request to
    the hub at 1:311/0:

    TO: AREAFIX@1:311/0
    SUBJ: mypassword

    Now that we know how to get the message to the hub all that is left to
    understand is how to compose the request to do what we need to do. PCBoard
    supports the following AreaFix commands:

    +<areaname> Subscribe to <areaname>
    -<areaname> Stop receiving mail from tag <areaname>
    %HELP Request a help message listing available AreaFix commands
    %LIST Request a list of areas available to you
    %QUERY Request a list of areas to which you have selected
    %UNLINKED Request a list of areas to which you have not selected
    %+ALL Select all areas available to you
    %-ALL De-select all areas (stop receiving echo mail)

    These commands must be entered beginning on the first line of the message
    and at the beginning of a line. For example, to get a list of areas
    which are available to us but we have not selected for importing, send
    the following netmail message:

    TO: AREAFIX@1:311/0
    SUBJ: mypassword

    That's all there is to it. See how simple that is. Realize that you
    can specify more than one command per message. All that is required
    is for the command to be at the beginning of a line.

    NOTE: Some AreaFix processors do not like the messages to be addressed
    in the manner AREAFIX@1:311/0. Instead, they would much rather see
    the hub information in the message body as shown in this example:


    --- PCBoard (R) v15.3/M 10
    * Origin: (1:226/600)