<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual: Hop control</TITLE>
+ <TITLE>The DXSpider Administration Manual v1.47: Mail</TITLE>
<LINK HREF="adminmanual-6.html" REL=next>
<LINK HREF="adminmanual-4.html" REL=previous>
<LINK HREF="adminmanual.html#toc5" REL=contents>
<A HREF="adminmanual-4.html">Previous</A>
<A HREF="adminmanual.html#toc5">Contents</A>
<HR>
-<H2><A NAME="s5">5. Hop control</A></H2>
+<H2><A NAME="s5">5. Mail</A></H2>
-<P>Starting with version 1.13 there is simple hop control available on a per
-node basis. Also it is possible to isolate a network completely so that you
-get all the benefits of being on that network, but can't pass on information
-from it to any other networks you may be connected to (or vice versa).
+<P>DXSpider deals seamlessly with standard AK1A type mail. It supports both
+personal and bulletin mail and the sysop has additional commands to ensure
+that mail gets to where it is meant. DXSpider will send mail almost
+immediately, assuming that the target is on line. However, only one
+mail message is dealt with at any one time. If a mail message is already
+being sent or recieved, then the new message will be queued until it has
+finished.
+<P>The cluster mail is automatically deleted after 30 days unless the sysop
+sets the "keep" flag using the <EM>msg</EM> command.
<P>
-<H2><A NAME="ss5.1">5.1 Basic hop control</A>
+<H2><A NAME="ss5.1">5.1 Personal mail</A>
</H2>
-<P>In /spider/data you will find a file called hop_table.pl. This is the file
-that controls your hop count settings. It has a set of default hops on the
-various PC frames and also a set for each node you want to alter the hops for.
-You may be happy with the default settings of course, but this powerful tool
-can help to protect and improve the network. The file will look something
-like this ...
+<P>Personal mail is sent using the <EM>sp</EM> command. This is actually the
+default method of sending mail and so a simple <EM>s</EM> for send will do.
+A full list of the send commands and options is in the <EM>command set</EM>
+section, so I will not duplicate them here.
+<P>
+<H2><A NAME="ss5.2">5.2 Bulletin mail</A>
+</H2>
+
+<P>Bulletin mail is sent by using the <EM>sb</EM> command. This is one of the
+most common mistakes users make when sending mail. They send a bulletin
+mail with <EM>s</EM> or <EM>sp</EM> instead of <EM>sb</EM> and of course
+the message never leaves the cluster. This can be rectified by the sysop
+by using the <EM>msg</EM> command.
+<P>
+<P>Bulletin addresses can be set using the Forward.pl file.
+<P>
+<H2><A NAME="ss5.3">5.3 Forward.pl</A>
+</H2>
+
+<P>DXSpider receives all and any mail sent to it without any alterations needed
+in files. Because personal and bulletin mail are treated differently, there
+is no need for a list of accepted bulletin addresses. It is necessary, however,
+to tell the program which links accept which bulletins. For example, it is
+pointless sending bulletins addresses to "UK" to any links other than UK
+ones. The file that does this is called forward.pl and lives in /spider/msg.
+At default, like other spider files it is named forward.pl.issue. Rename it
+to forward.pl and edit the file to match your requirements.
+The format is below ...
<P>
<BLOCKQUOTE><CODE>
<PRE>
+#
+# this is an example message forwarding file for the system
+#
+# The format of each line is as follows
+#
+# type to/from/at pattern action destinations
+# P/B/F T/F/A regex I/F [ call [, call ...] ]
+#
+# type: P - private, B - bulletin (msg), F - file (ak1a bull)
+# to/from/at: T - to field, F - from field, A - home bbs, O - origin
+# pattern: a perl regex on the field requested
+# action: I - ignore, F - forward
+# destinations: a reference to an array containing node callsigns
+#
+# if it is non-private and isn't in here then it won't get forwarded
+#
+# Currently only type B msgs are affected by this code.
#
-# hop table construction
-#
-
-package DXProt;
+# The list is read from the top down, the first pattern that matches
+# causes the action to be taken.
+#
+# The pattern can be undef or 0 in which case it will always be selected
+# for the action specified
+#
+# If the BBS list is undef or 0 and the action is 'F' (and it matches the
+# pattern) then it will always be forwarded to every node that doesn't have
+# it (I strongly recommend you don't use this unless you REALLY mean it, if
+# you allow a new link with this on EVERY bull will be forwarded immediately
+# on first connection)
+#
-# default hopcount to use
-$def_hopcount = 5;
+package DXMsg;
-# some variable hop counts based on message type
-%hopcount =
-(
- 11 => 10,
- 16 => 10,
- 17 => 10,
- 19 => 10,
- 21 => 10,
+@forward = (
+'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ],
+'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ],
+'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
+'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ],
+'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],
);
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Simply insert a bulletin address and state in the brackets where you wish
+that mail to go. For example, you can see here that mail sent to "UK" will
+only be sent to the UK links and not to PA4AB-14.
+<P>
+<P>To force the cluster to reread the file use load/forward
+<P>
+<P>
+<H2><A NAME="ss5.4">5.4 The msg command</A>
+</H2>
-
-# the per node hop control thingy
-
-
-%nodehops =
-
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-};
+<P>The <EM>msg</EM> command is a very powerful and flexible tool for the
+sysop. It allows the sysop to alter to and from fields and make other
+changes to manage the cluster mail.
+<P>Here is a full list of the various options ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ MSG TO <msgno> <call> - change TO callsign to <call>
+ MSG FRom <msgno> <call> - change FROM callsign to <call>
+ MSG PRrivate <msgno> - set private flag
+ MSG NOPRrivate <msgno> - unset private flag
+ MSG RR <msgno> - set RR flag
+ MSG NORR <msgno> - unset RR flag
+ MSG KEep <msgno> - set the keep flag (message won't be deleted ever)
+ MSG NOKEep <msgno> - unset the keep flag
+ MSG SUbject <msgno> <new> - change the subject to <new>
+ MSG WAittime <msgno> - remove any waiting time for this message
+ MSG NOREad <msgno> - mark message as unread
+ MSG REad <msgno> - mark message as read
+ MSG QUeue - queue any outstanding bulletins
+ MSG QUeue 1 - queue any outstanding private messages
</PRE>
</CODE></BLOCKQUOTE>
+<P>These commands are simply typed from within the cluster as the sysop user.
<P>
-<P>Each set of hops is contained within a pair of curly braces and contains a
-series of PC frame types. PC11 for example is a DX spot. The figures here
-are not exhaustive but should give you a good idea of how the file works.
+<H2><A NAME="ss5.5">5.5 Message status</A>
+</H2>
+
+<P>You can check on a message from within the cluster by using the command
+<EM>stat/msg</EM>. This will give you additional information on the
+message number including which nodes have received it, which node it
+was received from and when etc. Here is an example of the output of
+the command ...
<P>
-<P>You can alter this file at any time, including whilst the cluster is running.
-If you alter the file during runtime, the command <EM>load/hops</EM> will
-bring your changes into effect.
+<BLOCKQUOTE><CODE>
+<PRE>
+G0VGS de GB7MBC 28-Jan-2001 1308Z >
+stat/msg 6869
+ From: GB7DJK
+ Msg Time: 26-Jan-2001 1302Z
+ Msgno: 6869
+ Origin: GB7DJK
+ Size: 8012
+ Subject: AMSAT 2line KEPS 01025.AMSAT
+ To: UK
+Got it Nodes: GB7BAA, GB7ADX
+ Private: 0
+Read Confirm: 0
+ Times read: 0
+G0VGS de GB7MBC 28-Jan-2001 1308Z >
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<H2><A NAME="ss5.6">5.6 Filtering mail</A>
+</H2>
+
+<P>This is described in the section on <EM>Other filters</EM> so I will not
+duplicate it here.
<P>
-<H2><A NAME="ss5.2">5.2 Isolating networks</A>
+<H2><A NAME="ss5.7">5.7 Distribution lists</A>
</H2>
-<P>It is possible to isolate networks from each other on a "gateway" node using the
-<EM>set/isolate <node_call></EM> command.
-<P>
-<P>The effect of this is to partition an isolated network completely from another
-nodes connected to your node. Your node will appear on and otherwise behave
-normally on every network to which you are connected, but data from an isolated
-network will not cross onto any other network or vice versa. However all the
-spot, announce and WWV traffic and personal messages will still be handled
-locally (because you are a real node on all connected networks), that is locally
-connected users will appear on all networks and will be able to access and
-receive information from all networks transparently. All routed messages will
-be sent as normal, so if a user on one network knows that you are a gateway for
-another network, he can still still send a talk/announce etc message via your
-node and it will be routed across.
-<P>
-<P>The only limitation currently is that non-private messages cannot be passed down
-isolated links regardless of whether they are generated locally. This will change
-when the bulletin routing facility is added.
-<P>
-<P>If you use isolate on a node connection you will continue to receive all
-information from the isolated partner, however you will not pass any information
-back to the isolated node. There are times when you would like to forward only
-spots across a link (maybe during a contest for example). To do this, isolate
-the node in the normal way and put in a filter in the /spider/filter/spots
-directory to override the isolate. This filter can be very simple and consists
-of just one line ....
+<P>Distribution lists are simply a list of users to send certain types of
+mail to. An example of this is mail you only wish to send to other
+sysops. In /spider/msg there is a directory called <EM>distro</EM>. You
+put any distibution lists in here. For example, here is a file called
+SYSOP.pl that caters for the UK sysops.
<P>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX
+ GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH
+ GB7DXK GB7DXI GB7DXS)
</PRE>
</CODE></BLOCKQUOTE>
+<P>Any mail sent to "sysop" would only be sent to the callsigns in this list.
+<P>
+<H2><A NAME="ss5.8">5.8 BBS interface</A>
+</H2>
+
+<P>Spider provides a simple BBS interface. No input is required from the sysop
+of the cluster at all. The BBS simply sets the cluster as a BBS and pushes
+any required mail to the cluster. No mail can flow from Spider to the BBS,
+the interface is one-way.
<P>
-<P>There is a lot more on filtering in the next section.
+<P>Please be careful not to flood the cluster network with unnecessary mail.
+Make sure you only send mail to the clusters that want it by using the
+Forward.pl file very carefully.
<P>
<HR>
<A HREF="adminmanual-6.html">Next</A>
projects / spider.git / blobdiff