<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Configuration</TITLE>
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
+ <TITLE>The DXSpider Administration Manual v1.50: Mail</TITLE>
<LINK HREF="adminmanual-4.html" REL=next>
<LINK HREF="adminmanual-2.html" REL=previous>
<LINK HREF="adminmanual.html#toc3" REL=contents>
<A HREF="adminmanual-2.html">Previous</A>
<A HREF="adminmanual.html#toc3">Contents</A>
<HR>
-<H2><A NAME="s3">3. Configuration</A></H2>
+<H2><A NAME="s3">3.</A> <A HREF="adminmanual.html#toc3">Mail</A></H2>
-<H2><A NAME="ss3.1">3.1 Allowing ax25 connects from users</A>
+<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>
+<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="ss3.1">3.1</A> <A HREF="adminmanual.html#toc3.1">Personal mail</A>
</H2>
-<P>As stated previously, the aim of this document is not to tell you how to
-configure Linux or the ax25 utilities. However, you do need to add a line
-in your ax25d.conf to allow connections to DXSpider for your users. For
-each interface that you wish to allow connections on, use the following format ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-default * * * * * * - sysop /spider/src/client client %u ax25
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>or, if you wish your users to be able to use SSID's on their callsigns ..
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-default * * * * * * - sysop /spider/src/client client %s ax25
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<H2><A NAME="ss3.2">3.2 Allowing telnet connects from users</A>
+<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="ss3.2">3.2</A> <A HREF="adminmanual.html#toc3.2">Bulletin mail</A>
</H2>
-<P>Allowing telnet connections is quite simple. Firstly you need to add a line
-in /etc/services to allow connections to a port number, like this ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-spdlogin 8000/tcp # spider anonymous login port
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>Then add a line in /etc/inetd.conf like this ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-spdlogin stream tcp nowait root /usr/sbin/tcpd /spider/src/client login telnet
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>This needs to be added above the standard services such as ftp, telnet etc.
-Once this is done, you need to restart inetd like this ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-killall -HUP inetd
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>
-<P>Now login as <EM>sysop</EM> and cd spider/perl. You can test that spider
-is accepting telnet logins by issuing the following command ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-./client.pl login telnet
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>You should get a login prompt and on issuing a callsign, you will be given
-access to the cluster. Note, you will not get a password login. There seems
-no good reason for a password prompt to be given so it is not asked for.
-<P>
-<P>Assuming all is well, then try a telnet from your linux console ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-telnet localhost 8000
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>You should now get the login prompt and be able to login as before.
-<P>
-<H2><A NAME="ss3.3">3.3 Setting up node connects</A>
+<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="ss3.3">3.3</A> <A HREF="adminmanual.html#toc3.3">Forward.pl</A>
</H2>
-<P>In order to allow cluster node connections, spider needs to know that the
-connecting callsign is a cluster node. This is the case whether the connect
-is incoming or outgoing. In spider this is a simple task and can be done in
-runtime.
-<P>
-<P>Later versions of Spider can distinguish different software and treat them
-differently. For example, the WCY beacon cannot be handles by AK1A type
-nodes as AK1A does not know what to do with PC73. There are 4 different
-types of node at present and although they may not have any major
-differences at the moment, it allows for compatibility. The 4 types are ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-set/node (AK1A type)
-set/spider
-set/dxnet
-set/clx
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>For now, we will assume that the cluster we are going to connect to is an
-AK1A type node.
-<P>
-<P>Start up the cluster as you did before and login as the sysop with client.pl.
-The cluster node I am wanting to make a connection to is GB7BAA but you would
-obviously use whatever callsign you required. At the prompt type ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-set/node gb7baa
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>The case does not matter as long as you have a version of DXSpider later than
-1.33. Earlier versions required the callsign to be in upper case.
-<P>
-<P>That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop, cd to spider/perl and issue the command ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-./client.pl gb7baa (using the callsign you set as a node)
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>You should get an initialisation string from DXSpider like this ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-./client.pl gb7baa
-PC38^GB7MBC^~
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>If the callsign you just set up as a cluster node is for an incoming connect,
-this is all that needs to be done. If the connection is to be outgoing then
-a connection script needs to be written.
-<P>
-<H2><A NAME="ss3.4">3.4 Connection scripts</A>
+<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>
+<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.
+#
+# 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)
+#
+
+package DXMsg;
+
+@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>
+<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>NB: If a user tries to send mail to a bulletin address that does not exist
+in this file, they will get an error.</P>
+
+<H2><A NAME="ss3.4">3.4</A> <A HREF="adminmanual.html#toc3.4">The msg command</A>
</H2>
-<P>Because DXSpider operates under Linux, connections can be made using just about
-any protocol; AX25, NETRom, tcp/ip, ROSE etc are all possible examples.
-Connect scripts live in the /spider/connect directory and are simple ascii files.
-Writing a script for connections is therefore relatively simple.
-<P>
-<P>The connect scripts consist of lines which start with the following keywords
-or symbols:-
-<P>
-<PRE>
-
-# All lines starting with a # are ignored, as are completely
- blank lines.
+<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>
+<P>Here is a full list of the various options ...</P>
+<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>
+<P>These commands are simply typed from within the cluster as the sysop user.</P>
-timeout timeout followed by a number is the number of seconds to wait for a
- command to complete. If there is no timeout specified in the script
- then the default is 60 seconds.
+<H2><A NAME="ss3.5">3.5</A> <A HREF="adminmanual.html#toc3.5">Message status</A>
+</H2>
-abort abort is a regular expression containing one or more strings to look
- for to abort a connection. This is a perl regular expression and is
- executed ignoring case.
+<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>
+<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>
-connect connect followed by ax25 or telnet and some type dependent
- information. In the case of a telnet connection, there can be up to
- two parameters.
- The first is the ip address or hostname of the computer you wish to
- connect to and the second is the port number you want to use (this
- can be left out if it is a normal telnet session).
- In the case of an ax25 session then this would normally be a call to
- ax25_call or netrom_call as in the example above. It is your
- responsibility to get your node and other ax25 parameters to work
- before going down this route!
+<H2><A NAME="ss3.6">3.6</A> <A HREF="adminmanual.html#toc3.6">Filtering mail</A>
+</H2>
-' ' is the delimiting character for a word or phrase of an expect/send
- line in a chat type script. The words/phrases normally come in pairs,
- either can be empty. Each line reads input from the connection until
- it sees the string (or perl regular expression) contained in the
- left hand string. If the left hand string is empty then it doesn't
- read or wait for anything. The comparison is done ignoring case.
- When the left hand string has found what it is looking for (if it is)
- then the right hand string is sent to the connection.
- This process is repeated for every line of chat script.
+<P>This is described in the section on <EM>Other filters</EM> so I will not
+duplicate it here.</P>
-client client starts the connection, put the arguments you would want here
- if you were starting the client program manually. You only need this
- if the script has a different name to the callsign you are trying to
- connect to (i.e. you have a script called other which actually
- connects to GB7DJK-1 [instead of a script called gb7djk-1]).
-</PRE>
-<P>
-<P>There are many possible ways to configure the script but here are two examples,
-one for a NETRom/AX25 connect and one for tcp/ip.
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-timeout 60
-abort (Busy|Sorry|Fail)
-# don't forget to chmod 4775 netrom_call!
-connect ax25 /usr/sbin/netrom_call bbs gb7djk g1tlh
-'Connect' ''
-'Connect' 'c np7'
-'Connect' 'c gb7dxm'
-# you can leave this out if you call the script 'gb7dxm'
-client gb7dxm ax25
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-timeout 15
-connect telnet dirkl.tobit.co.uk
-'login' 'gb7djk'
-'word' 'gb7djk'
-# tell GB7DJK-1 that it is connected to GB7DJK
-# you can leave this out if you call this script 'gb7djk'
-client gb7djk telnet
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>Both these examples assume that everything is set up properly at the other end.
-You will find other examples in the /spider/examples directory.
-<P>
-<H2><A NAME="ss3.5">3.5 Starting the connection</A>
+<H2><A NAME="ss3.7">3.7</A> <A HREF="adminmanual.html#toc3.7">Distribution lists</A>
</H2>
-<P>You start the connection, from within a sysop enabled cluster login, by typing
-in the word <EM>connect</EM> followed by a script name like this ....
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-G0VGS de GB7MBC 13-Dec-1998 2041Z >connect gb7djk-1
-connection to GB7DJK-1 started
-G0VGS de GB7MBC 13-Dec-1998 2043Z >
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>This will start a connection using the script called <EM>gb7djk-1</EM>. You can
-follow the connection by watching the term or console from where you started
-<EM>cluster.pl</EM>. You should see something like this ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-<- D G1TLH connect gb7djk-1
--> D G1TLH connection to GB7DJK-1 started
--> D G1TLH G1TLH de GB7DJK 13-Dec-1998 2046Z >
-timeout set to 15
-CONNECT sort: telnet command: dirkl.tobit.co.uk
-CHAT "login" -> "gb7djk"
-received "
-Red Hat Linux release 5.1 (Manhattan)
-Kernel 2.0.35 on an i586
-"
-received "login: "
-sent "gb7djk"
-CHAT "word" -> "gb7djk"
-received "gb7djk"
-received "Password: "
-sent "gb7djk"
-Connected to GB7DJK-1, starting normal protocol
-<- O GB7DJK-1 telnet
--> B GB7DJK-1 0
-GB7DJK-1 channel func state 0 -> init
-<- D GB7DJK-1
-<- D GB7DJK-1 Last login: Sun Dec 13 17:59:56 from dirk1
-<- D GB7DJK-1 PC38^GB7DJK-1^~
-<- D GB7DJK-1 PC18^ 1 nodes, 0 local / 1 total users Max users 0 Uptime
-0 00:00^5447^~
- etc
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>With later versions of Spider there is a set/login command for users. This
-tells them when a user or node logs in or out. If you do not add a line to
-your scripts after the final line (or before the client line which should always
-be last if needed) then the login/logout information will be sent to users
-<I>before</I> the login actually completes. This means if a node is
-unreachable, it will continue sending logins and logouts to users even though it
-is not actually connecting. To avoid this use the following line ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-'connect' ''
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>In a script, this might look like ...
+<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>
<P>
<BLOCKQUOTE><CODE>
<PRE>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary 3000
-'ogin:' 'gb7mbc'
-'>' 'telnet 44.131.93.96 7305'
-'connect' ''
+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>
-<H2><A NAME="ss3.6">3.6 Telnet echo</A>
+</P>
+<P>Any mail sent to "sysop" would only be sent to the callsigns in this list.</P>
+
+<H2><A NAME="ss3.8">3.8</A> <A HREF="adminmanual.html#toc3.8">BBS interface</A>
</H2>
-<P>Cluster links in particular suffer greatly from the presence of telnet echo.
-This is caused by the telnet negotiation itself and can create at worst severe
-loops. At best it creates unnecessary bandwidth and large logfiles! There are
-things that can be done to limit this problem but will not always work dependent
-on the route taken to connect.
-<P>
-<P>Telnet echo itself should only be a problem if the connection is being made to
-the telnet port (23). This port uses special rules that include echo negotiation.
-If the connection is to a different port, such as 8000, this negotiation does
-not happen and therefore no echo should be present.
-<P>
-<P>Sometimes it is not possible to make a direct connection to another node and this
-can cause problems. There is a way of trying to suppress the telnet echo but
-this will not always work, unfortunately it is difficult to be more specific.
-Here is an example of what I mean ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-timeout 35
-abort (Busy|Sorry|Fail)
-connect telnet mary.lancs.ac.uk
-'ogin:' 'gb7mbc'
-'word:' 'mypasswd'
-'\$' 'stty -echo raw'
-'\$' 'telnet 44.131.93.96'
-'connect' ''
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>So, the first connection is made by Spider. This is fine as Spider uses the
-Net_Telnet script from within perl. This actually uses TCP rather than TELNET
-so no negotiation will be done on the first connection. Once connected to
-mary.lancs.ac.uk, the command is sent to suppress echo. Now a telnet is made
-to a cluster node that is accepting connections on port 23. The problem with
-this link is that the negotiation is made by the remote machine, therefore you
-have no control over it. The chances are that this link will create echo and
-there will be no way you can stop it.
-<P>
-<P>
+<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>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-4.html">Next</A>
<A HREF="adminmanual-2.html">Previous</A>
projects / spider.git / blobdiff