User Tools

Site Tools





Visual Customization

Mystic Utilities (MUTIL)

Scripting Custom Modules

Quick Reference

What's New


Configuring EchoMail Nodes

Echomail nodes are the the external systems your Mystic BBS communicates with in order to send and/or receive echomail, netmail and other files.

This section of the Mystic BBS Configuration System allows you to add/remove Echomail nodes and configure how they are set up.

EchoMail Node Settings

From the opening screen you can see EchoMail Node that have already been created.

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ EchoMail Nodes ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
 ID   Act  Description               SysOp                           Network
 1    Yes  fsxNet HUB (NET 1)        Paul Hayton                    21:1/100
 2    Yes  Agency HUB (FidoNet)      Paul Hayton                     3:770/1

                          Press / for command list

The / key reveals a command list menu.

                             I Insert
                             C Copy
                             D Delete
                             E EchoMail Exports
                             F FileBone Exports
                             1 Send AreaFix
                             2 Send FileFix
                             3 Netmail SysOp

This menu allows you to add or remove EchoMail Nodes from the system.

You can copy an existing EchoMail Node and paste (or move) the copied nodes to elsewhere on the list.

The 'Echomail Exports' option allows you to define which Echomail message bases you want to link to the EchoMail Node.

The 'Filebone Exports' option allows you to define which file bases you want to link to the EchoMail Node.

The next three options allow you to quickly and easily contact an EchoMail node to communicate with the SysOp or to add/remove message and file bases or anything else the Area/Filefix commands allow without having to fumble around with addresses and passwords!

  • 'Send Areafix' option sends a Areafix request via Netmail to the selected EchoMail node.
  • 'Send Filefix' option sends a Filefix request via Netmail to the selected EchoMail node.
  • 'Netmail SysOp' option sends Netmail to the Sysop of the selected EchoMail node.

If you want these options to work correctly for you it pays to set up the next section with the correct information and ensure you complete all the fields you need to.

Pressing the Enter key on an existing EchoMail Node (or a new EchoMail node) reveals the following screen. In this example an EchoMail Node has been set up for the fsxNet HUB (21:1/100) to send/receive EchoMail and Netmail to/from.

Page 1 of 6 - General

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Node ID 1 (21:1/100@fsxnet) ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
 Active         │ Yes                                       1:GENERAL
 Description    │ fsxNet HUB (NET 1)                        2:Security
 SysOp Name     │ Paul Hayton                               3:Groups
 Address        │ 21:1/100                                  4:BinkP
 Domain         │ fsxnet                                    5:FTP
 Session Type   │ BinkP                                     6:Dir Toss
 Archive Type   │ ZIP
 Export Type    │ Crash
 Route Info     │ 21:*
 Max PKT Size   │ 512
 Max ARC Size   │ 2048
 Use Filebox    │ No
 Filebox Dir    │
 Crash Limiter  │ 0
                │                                          Page 1 of 6

There are a number options you can set on page 1.


A simple yes/now setting - unless you set this to 'Yes' it will be ignored by Mystic, Fidopoll and MUTIL when various processes are run.


Define the name of the system you are connecting with.

SysOp Name

Define the name of the system operator running this system. You can set an alias s/he uses or their real name.


Set the Network Zone, Net, Node and Point (not often used) of this EchoMail Node. e.g. 21:1/100


Set the Domain Name of Network. It's best to keep it lowercase and check you spell it correctly. e.g. fsxnet

Session Type

There are three options to choose from:

  • Binkp - Fidpoll will send/receive bundles with this EchoMail Node using the BinkP protocol.
  • FTP - Fidopoll will send/receive bundles with this EchoMail Node using the FTP protocol.
  • Directory - Fidopoll will send bundles to/from locally configured inbound and outbound directories instead of using BINKP or FTP.

Depending on the option you choose here, pages 4, 5, or 6 of the configuration settings will need to be configured also.

Archive Type

Leave this blank if you wish to send raw uncompressed message packets (.PKT) files. Otherwise define the compression archive type you would like Mystic to use when creating bundles of message packets in your outbound directory. The common archive type to use is ZIP but you can define others here if you wish.

Export Type

There are several options you can set here. These determine how Mystic will treat the messages it is creating to send to this EchoMail Node. Should it send them as soon as it can, wait for the EchoMail Node to poll your system to collect Echomail and/or Netmail etc.

The options are:

  • Crash - High priority. Send messages to echonode ASAP next outbound / inbound connection occurs
  • Direct - Messages can only be sent direct to this echonode and not routed elsewhere
  • Hold - Hold all messages for echonode to collect when they next poll your Mystic BBS
  • Normal - Regular priority traffic

Route Info

Routing info is defined in the format of addresses separated by spaces and uses an asterisk (*) as a wildcard. In addition to an address, a “NOT” can be applied to each address by appending a ! and another address mask to it which will then be excluded.

For example if you have are a FidoNet node in zone 1 and you want to route all netmail posted to zones 1 through 5 to a specific downlink, you'd configure the following Routing Info for that echomail node:

Routing Info | 1:* 2:* 3:* 4:* 5:*

For most cases that will do. For networks that only have one zone you'd simply route just that zone. e.g. fsxNet Zone 21 would just have

Routing Info | 21:*

and you are done. But…

If for example, you had two FidoNet uplinks one at (1:123/1) and you wanted to route all Netmail to your first uplink EXCEPT for Netmail specifically addressed to your second uplink's NET you'd do this for your primary uplink:

Routing Info | 1:*!1:123/* 2:* 3:* 4:* 5:*

This will cause ALL zone 1-5 netmail to be routed to that uplink EXCEPT for netmail with a destination to 1:123/*. And then you'd configure your second uplink to route ONLY net 123:

Routing Info | 1:123/*

As usual with routing it can be confusing when you have very specific routing needs but if you have only single uplinks then it can be pretty straight forward.

Netmail messages do not export from MUTIL if their destination address is one of your configured AKA addresses.

NetMail message bases do not need to be linked to any Echomail nodes in order for Mystic to attempt exporting.

Mystic, when routing Netmail, will first compare the destination address against all configured echomail nodes. If there is a direct match Mystic will route the Netmail automatically to that node without reviewing the Route Info.

If there is no direct match, Mystic will then look at the Route Info for each Echomail node (starting at the first entry) until it finds a match and redirect netmail through that system.

Max PKT Size

Define the maximum file size (KB) of each packet Mystic creates. Set this to 0 is you do not want to set any limit.

Max ARC Size

Define the maximum bundle/arcmail file size being created for this EchoMail Node. Set this to 0 if you do not want to set any limit.

Use Filebox

A Filebox is a directory you can place any file in to that will be sent to your EchoMail Node when you next poll it using Fidopoll or it polls your Mystic BBS.

There are three options for this setting

  • No - Don't enable this feature
  • Yes- Send files to EchoMail Node if you Fidopoll it or if it polls your Mystic BBS
  • Hold - Only send files to the EchoMail Node if it polls your Mystic BBS

Note: When you first select Yes as an option Mystic will prompt you if you wish to generate a default filebox. Do not do this until after entering your Zone, Net, Node, Point and Domain details first.

If you say YES to this question Mystic pops up with a dialogue box similar to this:

              █▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Info ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄
              █                                                    █
              █ Create: c:\mystic\filebox\fsxnet_z21n1n100\?       █
              █                                                    █
              █                      YES  NO                       █

You can override this suggestion by answering NO and filling out our preferred file path in the next input field below. Or answer YES to have Mystic auto create the directory for you.

Be sure to check the Filebox status is set to what you want it to be once doing this.

Filebox Dir

Defines the drive and directory pathway that is associated with the Filebox to be used with this EchoMail Node. If the directory does not exist then Mystic will offer to create it.

Crash Limiter

This feature is still being developed. The idea is that when FidoPoll sends files via BINKP it will skip queueing any files for sending larger than this value. It forces EchoMail nodes to poll and collect these files vs a HUB system spending time transferring large files to them. The value is defined in kilobytes.

At present there is no logic built in to this feature. That means if you set say a value of 1000 Mystic will send .TIC files that accompany a hatched file to an EchoMail node but if the actual hatched file is larger than 1000kb it will not send at the same time. This can cause issues for the receiving EchoMail node.

Keep an eye on this section of the Wiki and we'll update it as the feature evolves ;-)

Page 2 of 6 - Security

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Node ID 1 (21:1/100@fsxnet) ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
 PKT Password   │                                           1:General
 FIX Password   │ *****                                     2:SECURITY
 TIC Password   │ *****                                     3:Groups
 Encryption Key │ *****                                     4:BinkP
 Security Level │ 0                                         5:FTP
 Access Flags   │ --------------------------                6:Dir Toss
                │                                          Page 2 of 6

PKT Password

This is an optional password you can set so that messages sent to/from this EchoMail Node contain an additional layer of security when transferring them between your Mystic system and this EchoMail Node.

If set, MUTIL will not toss (import) messages in to your Mystic BBS that do not have a matching password contained in the message packets it has received from this system. Likewise any messages you send to this EchoMail Node will also be sent with this password added to every message packet.

Set if you need to, but otherwise leave blank. It's usually enough to just set a session password in your 'Session Options' section of the EchoMail Node configuration.

FIX Password

This is the password you would set if the EchoMail Node system you are setting up, was to send your Mystic BBS a Allfix or Filefix netmail. Mystic would check the password sent in the netmail addressed to it from this system matched the password set here before acting on the inbound netmail request.

TIC Password

This is the password that your Mystic BBS will use to check against .TIC files that are sent to it from this EchoMail Node.

.TIC files usually accompany files sent to your Mystic BBS by another system. They contain instructions for your Mystic BBS to import the file accompanying the .TIC in to your file areas.

Without this password set your Mystic BBS will ignore the files it receives and/or move them in to the BAD directory defined in the [FileToss] stanza of your MUTIL .ini file

Encryption Key

Echomail nodes now have an “Encryption Key” option. When this option is set to a non-blank value, Mystic will encrypt all of the contents of Netmail messages to this node with an AES-256 encryption. This completes a fully encrypted echomail solution as both transport and private messages are secured.

This is done in a way that is completely transparent to unsupporting systems, meaning that you can still route netmail through systems and they will not harm the encrypted netmails! The encryption also hides the message subject, so when combined with Area/Filefix passwords will no longer be readable. You must have Cryptlib installed for this to work.

The other echomail node must of course have the same key configured for your node in order to decrypt the netmail when it arrives. This works the same way as any other password setting in echomail nodes.

When routing Netmail, Mystic will intelligently re-encrypt the message between routing points when possible. In other words if you have a point system who sends from 555:1/2.1 to 555:1/1 but is routed through 555:1/2, Mystic at 555:1/2 will know that it has an encryption agreement between both 555:1/2.1 and 555:1/1 so it will decrypt the message from 555:1/2.1 and then re-encrypt it for 555:1/1 before routing it.

Security Level

You can set ACS rules for this EchoMail node. Refer to discussion info in the Echomail Node Security section below.

Access Flags

You can set access flags for this EchoMail Node. Refer to discussion info in the Echomail Node Security section below.

Echomail Node Security

Echomail node security is here! The easiest way to think about how this system works is to relate an Echomail node to the way security works for a user in your BBS. Each node will have a security level, access flags, and can be a member of many Echomail groups (up to 65000 echomail groups can be defined).

Different functions throughout the echomail system will eventually have “Echo ACS” strings which work just like the user ACS strings that we're familiar with. For example, you might have “Hatch File EACS” in a file base where you could say that you wanted only echomail nodes within a particular group to be able to hatch files, or a particular security level or access flag(s), or even by static echomail node ID. For example:

   Hatch File EACS: g2|s255|fH|u10

The above would say that any echomail node that is a member of Echomail group 2, OR any node that has a security level of 255 OR any Echomail node that has flag H can hatch files to that file base. The Echomail node with the ID of #10 can also hatch.

The following commands are available within EACS:

    s<level>  : Echomail node must have a Security Level greater than or
                equal to <level>
    g<number> : Echomail node must be a member of Echomail group ID equal
                to <number>
    f<flag>   : Echomail node must have flag <flag> which is a letter
                between A to Z.
    u<number> : Echomail node must have a unique ID of <number>.  This
                allows security to be applied to specific nodes (ID is
                shown in echomail node editor).

Just like user ACS, Echomail ACS can also use parenthesis and boolean evaulation.

Echomail ACS has been activated for message base subscribing/reading. A new field in each Message base configuration called “List EACS” defines the ACS requires for an echommail node to be able to see, subscribe, or unsubscribe to the area via AreaFix.

Hubs can still manually link a base to a node regardless of security, so for example if you wanted to force nodes to always carry a specific echo area, you would give them the base and then set the “List EACS” to an access they do not have (or even use % which is “never” in ACS terms). With this setup in place, the node cannot add or remove the area, they can only perform rescans.

This is a very powerful system for managing an Echomail network, and EACS strings will be added to various functions in the future as seen fit.

Page 3 of 6 - Groups

 Echo Group 01  │ fsxNet                                    1:General
 Echo Group 02  │ None                                      2:Security
 Echo Group 03  │ None                                      3:GROUPS
 Echo Group 04  │ None                                      4:BinkP
 Echo Group 05  │ None                                      5:FTP
 Echo Group 06  │ None                                      6:Dir Toss
 Echo Group 07  │ None
 Echo Group 08  │ None
 Echo Group 09  │ None
 Echo Group 10  │ None
 Echo Group 11  │ None
 Echo Group 12  │ None
 Echo Group 13  │ None
 Echo Group 14  │ None
 Echo Group 15  │ None                                     Page 3 of 6

Define which EchoMail groups this EchoMail node is a member of.

Page 4 of 6 - BinkP

 BINKP Hostname │                       1:General
 IP Type        │ IPV4                                      2:Security
 Password       │ *****                                     3:Groups
 Time Out       │ 30                                        4:BINKP
 Block Size     │ 16384                                     5:FTP
 CRAM-MD5       │ Yes                                       6:Dir Toss
 Use SSL/TLS    │ No
 Hide AKAs      │ Yes
                │                                          Page 4 of 6

A Binkp section has the following options you should look at and in most cases set up:

BINKP Hostname

Set the DNS hostname (and port if required) for the EchoMail Node you will poll using Fidopoll.

IP Type

Do you wish to use IPV4 or IPV6 when using Fidopoll to connect to this system? Or do you wish to set a preferred connection type and then a fallback type? e.g. IPV6 + IPV4 or IPV4 + IPV6


Set the session password your Mystic BBS will send to this EchoMail Node when you poll it using Fidopoll or it connects to your Mystic BinkP server and attempts to send your system Echomail, Netmail and/or other files.

This password is case sensitive. Be warned some non-Mystic systems have issues with this. Best advice keep everything UPPERCASE and limited to no more than 8 characters to avoid hassles.


Inactivity timeout time in seconds before a BinkP session is halted. Leave as default unless you know what you are doing.


Data blocksize in bytes. Leave as default unless you know what you are doing.


Use MD5 hashing when connecting as a client? This hides session passwords so they are not sent in plain text. It's a good idea to use this.


Mystic BINKP server and FIDOPOLL now support opportunistic SSL (TLS v1.2+) using a proprietary extension of the BINKP protocol. This means that it will only work with other Mystic BBS clients and servers, but the author plans to document the extension and send it to the authors of other mailers in hopes that it can be standardized.

EchoMail Nodes now have three settings which can be used when polling for new mail:

    No     : FIDOPOLL will not use SSL extension at all
    Yes    : FIDOPOLL WILL use SSL if the server supports it
    Forced : FIDOPOLL will refuse to exchange mail with a server
             unless it supports SSL

This setting is experimental at present so your mileage may vary. If you're having issues connecting to other systems it's best to set this to 'No' for now.

Hide AKAs

Hide alternative network addresses during a BinkP handshake. When your system polls this EchoMail Node will it only show the network address you have set up for the same Zone this EchoMail Node has in common with or it will show all your defined EchoMail addresses?

Page 5 of 6 - FTP

 FTP Hostname   │                                           1:General
 Login          │                                           2:Security
 Password       │                                           3:Groups
 Passive        │ Yes                                       4:BinkP
 Out Directory  │                                           5:FTP
 In Directory   │                                           6:Dir Toss
                │                                          Page 5 of 6

A FTP session has the following options you should set:

FTP Hostname

Set the DNS hostname (and port if required) for the EchoMail Node you will poll using Fidopoll.


Set the username to pass to the FTP server when connecting to it.


Set the password to pass to the FTP server when connecting to it


Is this to be an active or passive FTP session?

Out Directory

Set the directory you wish Mystic to send message packets / files from.

In Directory

Set the directory you wish Mystic to look for incoming message packets / files it receives.

Page 6 of 6 - Dir Toss

 Outbound Dir   │                                           1:General
 Inbound Dir    │                                           2:Security
                │                                           3:Groups
                │                                           4:BinkP
                │                                           5:FTP
                │                                           6:DIR TOSS
                │                                          Page 6 of 6

A Directory session has the following options you should set:

Outbound Dir

Set the directory you wish Mystic to place message packets / files in to that will be in turn processed by another system that is receiving them.

Inbound Dir

Set the directory you wish Mystic to look for inbound message packets / files from another system that has sent them to your BBS.

config_echomail_nodes.txt · Last modified: 2019/03/18 03:48 by avon