Differences

This shows you the differences between two versions of the page.

--- config_echomail_nodes [2019/03/16 17:55] – added ssl/tls for echomail nodes avon
+++ config_echomail_nodes [2022/09/26 01:31] – adding 'uplink' content avon
@@ Line 70: / Line 70: @@
    Export Type    │ Crash
    Route Info     │ 21:*
+   Uplink         │ No
    Max PKT Size   │ 512
    Max ARC Size   │ 2048
@@ Line 156: / Line 157: @@
 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.
+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.
+=== Uplink ===
+This flag can either be set to Yes or No for each Echomail Node.  It works in tandem with MIS POLL UPLINK and is similar to the MIS POLL FORCED command, but instead will only force a poll of Echomail Nodes with the Uplink flag set to Yes.
 === Max PKT Size ===
@@ Line 265: / Line 270: @@
 === Echomail Node Security ====
-The beginnings of 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).
+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 [[config_echomail_groups|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 [[access_control|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:
@@ Line 272: / Line 277: @@
 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.