<!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 : Mail</TITLE>
+ <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.16">
+ <TITLE>The DXSpider Administration Manual v1.50: Security</TITLE>
<LINK HREF="adminmanual-10.html" REL=next>
<LINK HREF="adminmanual-8.html" REL=previous>
<LINK HREF="adminmanual.html#toc9" REL=contents>
<A HREF="adminmanual-8.html">Previous</A>
<A HREF="adminmanual.html#toc9">Contents</A>
<HR>
-<H2><A NAME="s9">9. Mail</A></H2>
+<H2><A NAME="s9">9.</A> <A HREF="adminmanual.html#toc9">Security</A></H2>
-<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="ss9.1">9.1 Personal mail</A>
-</H2>
+<P>From version 1.49 DXSpider has some additional security features. These
+are not by any means meant to be exhaustive, however they do afford some
+security against piracy. These two new features can be used independently
+of each other or in concert to tighten the security.</P>
-<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="ss9.2">9.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="ss9.3">9.3 Forward.pl</A>
+<H2><A NAME="ss9.1">9.1</A> <A HREF="adminmanual.html#toc9.1">Registration</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>The basic principle of registration is simple. If a user is not registered
+by the sysop, then they have read-only access to the cluster. The only
+thing they can actually send is a talk or a message to the sysop. In
+order for them to be able to spot, send announces or talks etc the sysop
+must register them with the <EM>set/register</EM> command, like this ...</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) ],
-);
+set/register g0vgs
</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="ss9.4">9.4 The msg command</A>
-</H2>
-
-<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>
+<P>The user g0vgs can now fully use the cluster. In order to enable
+registration, you can issue the command ...</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
+set/var $main::reqreg = 1
</PRE>
</CODE></BLOCKQUOTE>
-<P>These commands are simply typed from within the cluster as the sysop user.
-<P>
-<H2><A NAME="ss9.5">9.5 Message status</A>
+</P>
+<P>Any users that are not registered will now see the motd_nor file rather
+than the motd file as discussed in the Information, files and useful
+programs section.</P>
+
+<P>Entering this line at the prompt will only last for the time the cluster
+is running of course and would not be present on a restart. To make the
+change permanent, add the above line to /spider/scripts/startup. To
+read more on the startup file, see the section on Information, files
+and useful programs.</P>
+
+<P>To unregister a user use <EM>unset/register</EM> and to show the list
+of registered users, use the command <EM>show/register</EM>.</P>
+
+<H2><A NAME="ss9.2">9.2</A> <A HREF="adminmanual.html#toc9.2">Passwords</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>At the moment, passwords only affect users who login to a DXSpider
+cluster node via telnet. If a user requires a password, they can
+either set it themselves or have the sysop enter it for them by using
+the <EM>set/password</EM> command. Any users who already have passwords,
+such as remote sysops, will be asked for their passwords automatically
+by the cluster. Using passwords in this way means that the user has a
+choice on whether to have a password or not. To force the use of
+passwords at login, issue 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 >
+set/var $main::passwdreq = 1
</PRE>
</CODE></BLOCKQUOTE>
-<P>
-<H2><A NAME="ss9.6">9.6 Filtering mail</A>
-</H2>
+</P>
+<P>at the cluster prompt. This can also be added to the /spider/scripts/startup
+file as above to make the change permanent.</P>
-<P>This is described in the section on <EM>Other filters</EM> so I will not
-duplicate it here.
-<P>
-<H2><A NAME="ss9.7">9.7 Distribution lists</A>
-</H2>
+<P>Of course, if you do this you will have to assign a password for each of
+your users. If you were asking them to register, it is anticipated that
+you would ask them to send you a message both to ask to be registered and
+to give you the password they wish to use.</P>
-<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>Should a user forget their password, it can be reset by the sysop by
+first removing the existing password and then setting a new one like so ...</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
-qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX
- GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH
- GB7DXK GB7DXI GB7DXS)
+unset/password g0vgs
+set/password g0vgs new_password
</PRE>
</CODE></BLOCKQUOTE>
-<P>Any mail sent to "sysop" would only be sent to the callsigns in this list.
-<P>
-<H2><A NAME="ss9.8">9.8 BBS interface</A>
-</H2>
+</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-10.html">Next</A>
<A HREF="adminmanual-8.html">Previous</A>
projects / spider.git / blobdiff