X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=sgml%2Fadminmanual.sgml;h=f075b7988bb9a35e03316d921e811fe9350b3e60;hb=a8dfe65f270217c237386afb696a52c1a15f5ad1;hp=b956474f8cf5aad33abdbc7427b8c93aa6834802;hpb=e39b738850b9a122b60b179e9723e546ddacfd62;p=spider.git diff --git a/sgml/adminmanual.sgml b/sgml/adminmanual.sgml index b956474f..f075b798 100644 --- a/sgml/adminmanual.sgml +++ b/sgml/adminmanual.sgml @@ -4,9 +4,10 @@ -
-This section describes the installation of DX Spider v1.46 on a
-
-I am assuming a general knowledge of Linux and its commands. You should
-know how to use tar and how to edit files using your favourite editor.
-
-
-The crucial ingredient for all of this is
- In addition to the standard Red Hat distribution you will require the
-following modules from
-
-
-Do get the latest versions of these packages and install them
-but use the above list as the earliest versions usable.
-
-
-I will assume that you have already downloaded the latest tarball of
-the DXSpider software and are ready to install it. I am assuming version
-1.46 for this section but of course you would use the latest version.
-
-
-Login as root and create a user to run the cluster under.
-
-Now set a password for the user ...
-
-
-Now to unpack the DX Spider distribution, set symbolic links and group
-permissions. Copy the tarball to /home/sysop and do the following.
-
-
-The next step is to set the permissions on the Spider directory tree and files ....
-
-
-This last step allows various users of the group spider to have
-write access to all the directories. This is not really needed just yet
-but will be useful when web interfaces start to appear.
-
-
-Finally, you need to fix the permissions on the ax25_call and netrom_call
-programs. Check where they are with the locate command and alter
-the permissions with the chmod command like this ..
-
-
-Now login to your machine as the user you created earlier. In my case that
-user is called sysop. Once logged in, issue the following commands ....
-
-
-Using the distributed DXVars.pm as a a template, set your cluster callsign,
-sysop callsign and other user info to suit your own environment. Note that
-this a perl file which will be parsed and executed as part of the cluster. If
-you get it wrong then perl will complain when you start the cluster process.
-It is important only to alter the text of any section. Some of the lines look
-a little odd. Take this line for example ....
-
-
-$myemail = "ianmaude\@btinternet.com";
-
-
-
-There appears to be an extra slash in there. However this has to be there
-for the file to work so leave it in.
-
-
-DON'T alter any file in /spider/perl, they are overwritten with every
-release. Any files or commands you place in /spider/local or /spider/local_cmd
-will automagically be used in preference to the ones in /spider/perl EVEN
-while the cluster is running!
-
-
-Save the new file and change directory to ../perl ....
-
-
-Now type the following command which creates the basic user file with you as
-the sysop.
-
-
-We can now bring spider up for the first time and see if all is well or not!
-It should look something like this ...
-
-
-If all is well then login on another term or console as sysop and
-cd to /spider/src. Now issue the following command ...
-
-
-This should log you into the cluster as the sysop under the alias callsign we
-set earlier. In this case the callsign is G0VGS. The cluster callsign is set
-in the DXVars.pm file in /spider/local. In this case we will assume that this
-was set as GB7MBC. You should therefore see this when you login ....
-
-
-and both the cluster and the client should return to Linux prompts.
-
-
-In earlier versions of Spider, all the processes were Perl scripts. This
-was fine but with a lot of users your computer memory would soon be used up.
-To combat this a new client was written in "C". This client only works for
-incoming connects at the moment. Before you can use it though it
-has to be "made". CD to /spider/src and type make. You
-should see the output on your screen and hopefully now have a small C program
-called client. Leave it in this directory.
-
-
-
-This section is designed for experienced Spider sysops who want to install
-Spider from scratch. It is simply a check list of things that need to be
-done without any explanations. The name in brackets at the end of each line
-is the user that should be doing that process.
-
-
-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 ...
-
-
-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 ....
-
-
-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 ....
-
- Now login as sysop and cd spider/src. You can test that spider
-is accepting telnet logins by issuing the following command ....
-
-
-Assuming all is well, then try a telnet from your linux console ....
-
-
-You should now get the login prompt and be able to login as before.
-
-
-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.
-
-
-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 ...
-
-
-For now, we will assume that the cluster we are going to connect to is an
-AK1A type node.
-
-
-Start up the cluster as you did before and login as the sysop with client.
-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 ...
-
-
-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.
-
-
-That is now set, it is as simple as that. To prove it, login on yet another
-console as sysop, cd to spider/src and issue the command ...
-
-
-You should get an initialisation string from DXSpider like this ...
-
-
-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.
-
-
-The connect scripts consist of lines which start with the following keywords
-or symbols:-
-
-
-
-
-Both these examples assume that everything is set up properly at the other end.
-You will find other examples in the /spider/examples directory.
-
-
-You start the connection, from within a sysop enabled cluster login, by typing
-in the word connect followed by a script name like this ....
-
-
+In fact DXSpider has had a simple system for some time which is called
+
+The new functionality introduced in version 1.48 allows filtering the node
+and user protocol frames on a "per interface" basis. We call this
+
+What this really means is that you can control more or less completely
+which user and node management PC protocol frames pass to each of your
+partner nodes. You can also limit what comes into your node from your
+partners. It is even possible to control the settings that your partner
+node has for the routing information that it sends to you
+(using the
+Initially when route filters were being tested we generated a
+"default" filter. Unfortunately it quickly became apparent that this
+might suit the UK cluster network but didn't really fit anybody else.
+However using a default filter is an appropriate thing to do. How, is
+explained further on.
+
+
+The first thing that you must do is determine whether you need to use
+route filtering
+To put it simply, you should not mix Isolation and Route Filtering. It
+will work, of sorts, but you will not get the expected results. If you
+are using Isolation sucessfully at the moment, do not get involved in
+Route Filtering unless you have a good supply of aspirin! Once you have
+started down the road of Route Filtering, do not use Isolation either.
+Use one or the other, not both.
+
+
+You will only require this functionality if you are "well-connected". What
+that means is that you are connected to several different parts of (say)
+the EU cluster and, at the same time, also connected to two or three places
+in the US which, in turn are connected back to the EU. This is called a
+"loop" and if you are seriously looped then you need filtering.
+
+
+I should at this stage give a little bit of background on filters. All
+the filters in Spider work in basically the same way. You can either
+accept or reject various options in order to create the filter rules
+you wish to achieve. Some filters are user settable, others can only
+be altered by the sysop. Route filtering can only be done by the sysop.
+
+
+Anyway, without further discouragement, let me start the process
+of explanation.
+
+
+All normal systems should have a default routing filter and it should
+usually be set to send only the normal, unlooped, view of your
+"national" network. Here in the UK that means nodes from the UK and
+Eire, in EU it is more complex as the networks there grew up in a more
+intertwined way.
+
+
+The generic commands are:-
+
+
-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
-
-In a script, this might look like ...
+where filter_option is one of the following ...
-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.
-
-
-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.
-
-
-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 ...
+
+For the default routing filter then you have two real choices: either
+a "national" view or the "safe" option of only your own
+callsign. Examples of each (for my node: GB7DJK) are:-
+The example filters shown control
-Ok, you should now have DXSpider running nicely and allowing connects by cluster
-nodes or users. However, it has to be shutdown and restarted manually and if
-connection scripts fail they have to be started again manually too, not much use
-if you are not at the console! So, in this section we will automate both.
-Firstly starting the cluster.
-
-
-This is not only a way to start the cluster automatically, it also works as a
-watchdog, checking the sanity of DXSpider and respawning it should it crash for
-any reason. Before doing the following, shutdown the cluster as you did earlier.
-
-
-Login as root and bring up the /etc/inittab file in your favourite editor. Add
-the following lines to the file near the end ...
+
+It is also possible to control the
-This line works fine for RedHat distributions. It is also fine for SuSE up to
-7.0. From Suse 7.1 you need to add runlevels 2 and 5 like this ...
+What this does is accept node and user information for our national
+network from nodes that are in our national network, but rejects such
+information from anyone else. Although it doesn't explicitly say so,
+by implication, any other node information (not from the UK and Eire)
+is accepted.
-
+As I imagine it will take a little while to get one's head around all of
+this you can study the effect of any rules that you try by watching the
+debug output after having done:-
-This will automatically start DXSpider on tty7 (ALT-F7) on bootup and restart
-it should it crash for any reason.
-
-
-As root type the command telinit q. DXSpider should start up
-immediately. You will see the output on tty7 and if you login as sysop
-you should find everything running nicely.
-
-
-So far so good, now to automate script connections...
-
-
-Login as sysop and create a file in /spider/local_cmd called crontab.
-Edit it with your favourite editor and add a line like this (I have included
-a comment)
+After you have got tired of that, to put it back the way it was:-
-The callsign involved will be the callsign of the cluster node you are
-going to connect to. This will now check every 10 minutes to see if
-gb7xxx is connected, if it is then nothing will be done. If it is not,
-then a connect attempt will be started.
-
-
-There are probably lots of other things you could use this crontab file for.
-If you want to know more about it, look at the
-
-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).
-
-
-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 ...
+Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
-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.
-
-
-You can alter this file at any time, including whilst the cluster is running.
-If you alter the file during runtime, the command load/hops will
-bring your changes into effect.
-
-
-It is possible to isolate networks from each other on a "gateway" node using the
- set/isolate <node_call> command.
-
-
-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.
-
-
-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.
-
-
-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 ....
-
-
-There is a lot more on filtering in the next section.
-
-
-Filters can be set for spots, announcements and WWV. You will find the
-directories for these under /spider/filter. You will find some examples in
-the directories with the suffix .issue. There are two types of
-filter, one for incoming information and one for outgoing information.
-Outgoing filters are in the form CALLSIGN.pl and incoming filters
-are in the form in_CALLSIGN.pl. Filters can be set for both nodes
-and users.
-
-
-All filters work in basically the same way. There are several elements
-delimited by commas. There can be many lines in the filter and they are
-read from the top by the program. When writing a filter you need to think
-carefully about just what you want to achieve. You are either going to write
-a filter to accept or to reject. Think of a filter as
-having 2 main elements. For a reject filter, you would have a line or multiple
-lines rejecting the things you do not wish to receive and then a default line
-accepting everything else that is not included in the filter. Likewise, for an
-accept filter, you would have a line or multiple lines accepting the things you
-wish to receive and a default line rejecting everthing else.
-
-
-In the example below, a user requires a filter that would only return SSB spots
-posted in Europe on the HF bands. This is achieved by first rejecting the CW
-section of each HF band and rejecting all of VHF, UHF etc based on frequency.
-Secondly, a filter rule is set based on CQ zones to only accept spots posted in
-Europe. Lastly, a default filter rule is set to reject anything outside the filter.
-
-
-The actual elements of each filter are described more fully in the following
-sections.
-
-
-The elements of the Spot filter are ....
-
-
-There are 3 elements here to look at. Firstly, the action element. This is
-very simple and only 2 possible states exist, accept (1) or drop (0).
-
-
-The second element is the field_no. There are 13 possiblities to choose from
-here ....
-
-
-The third element tells us what to expect in the fourth element. There are
-4 possibilities ....
-
-
-The fifth element is simply the hops to set in this filter. This would only
-be used if the filter was for a node of course and overrides the hop count in
-hop_table.pl.
-
-
-So, let's look at an example spot filter. It does not matter in the example
-who the filter is to be used for. So, what do we need in the filter? We need
-to filter the spots the user/node requires and also set a default rule for
-anything else outside the filter. Below is a simple filter that stops spots
-arriving from outside Europe.
-
-
-So the filter is wrapped in between a pair of square brackets. This tells
-Spider to look in between these limits. Then each line is contained within
-its own square brackets and ends with a comma. Lets look carefully at the first
-line. The first element is 0 (drop). Therefore anything we put on this line
-will not be accepted. The next element is 4. This means we are filtering by
-the spotter. The third element is the letter "a" which tells the program to
-expect an alphanumeric expression in the fourth element. The fourth element
-is a list of letters separated by the pipe symbol.
-
-
-What this line does is tell the program to drop any spots posted by anyone in
-the USA, Canada or Japan.
-
-
-The second line is the default rule for anything else. The "d" tells us this
-and the line simply reads... accept anything else.
-
-
-You can add as many lines as you need to complete the filter but if there are
-several lines of the same type it is neater to enclose them all as one line.
-An example of this is where specific bands are set. We could write this like
-this ....
+or
-
-But the line below achieves the same thing and is more efficient ....
+Here are some examples of route filters ...
-
+In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+
-It should be noted that the filter will start to be used only once a user/node
-has logged out and back in again.
-
-I am not going to spend any more time on these filters now as they will become
-more "comprehensive" in the near future.
+This last example takes everything except UK and Eire from PI4EHV-8
+but only sends him my local configuration (just a PC19 for GB7DJK and
+PC16s for my local users).
+
+
+It is possible to write
-In general terms you can create a 'reject' or an 'accept' filter which can have
+In general terms you can create a "reject" or an "accept" filter which can have
up to 10 lines in it. You do this using, for example ...
+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 ...
+
+
+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.
+
+
+You can alter this file at any time, including whilst the cluster is running.
+If you alter the file during runtime, the command load/hops will
+bring your changes into effect.
+
+ You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+
+The set/hops command overrides any hops that you have set otherwise.
+
+
+You can set what hops have been set using the show/hops command.
+
+
+It is possible to isolate networks from each other on a "gateway" node using the
+ set/isolate <node_call> command.
+
+
+The effect of this is to partition an isolated network completely from another
+node 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.
+
+
+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 use
+an acc/spot >call< all filter to override the isolate.
-
-In the same way as mail, there are some types of spot we do not wish to pass on
-to users or linked cluster nodes. In the /spider/data directory you will find
-a file called baddx.pl.issue. Rename this to baddx.pl and edit the file. The
-original looks like this ....
+
+From version 1.48 onwards the interface to this has changed. You can now
+use the commands set/badword to add words that you are not prepared
+to see on the cluster, unset/badword to allow that word again and
+show/badword to list the words that you have set.
-
+If you have a previous /spider/data/badwords, the first time you start
+the node, it will read and convert this file to the new commands. The old style
+file will then be removed.
-# the list of dx spot addresses that we don't store and don't pass on
+
+There are a number of commands that control whether a spot progresses
+any further by regarding it as "bad" in some way.
-package DXProt;
+
+A DX Spot has a number of fields which can be checked to see whether they
+contain "bad" values, they are: the DX callsign itself, the Spotter and
+the Originating Node.
-@baddx = qw
-
- FROG
- SALE
- FORSALE
- WANTED
- P1RATE
- PIRATE
- TEST
- DXTEST
- NIL
- NOCALL
-);
-
+There are a set of commands which allow the sysop to control whether a
+spot continues:-
-
-Again, this is simply a list of names we do not want to see in the spotted
-field of a DX callout.
+
-Create a file in /spider/data called badwords. The format is quite
-simple. Lines beginning with # are ignored so comments can be added. An
-example file is below ...
+a bad spotter:
-You can reload the file from the cluster prompt as sysop with load/badwords.
+
+From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
+
+
+In the first instance, in 1.48, the sysop can create, with their favorite
+text editor, files in the directory /spider/scripts which contain
+any legal command for a callsign or class of connection which will be executed
+at logon.
+
+
+The filename is the callsign of the connection that you want the script to
+operate on, eg: /spider/scripts/g1tlh. The filenames are always in
+lower case on those architectures where this makes a difference.
+
+
+In addition to the callsign specific scripts there are three others:-
+
+
+The user_default script is executed for every user that does
+
+The node_default script is executed for every node that doesn't
+have a specific script.
+
+
+There are a couple of examples in the /spider/scripts directory.
+
@@ -2020,14 +1358,9 @@ that it is possible to update your DXSpider installation to the latest
sources by using a few simple commands.
-THIS IS NOT FOR THE FAINT HEARTED!!! ONLY DO THIS IF YOU HAVE A TEST
-INSTALLATION OR ARE WILLING TO HAVE YOUR CLUSTER CRASH ON YOU!!!
-THIS MUST BE CONSIDERED AT LEAST BETA TESTING AND MAYBE EVEN ALPHA!!
-YOU HAVE BEEN WARNED!!!
-
-
-DID I MENTION..... ONLY DO THIS IF YOU ARE WILLING TO ACCEPT THE
-CONSEQUENCES!!!
+Please be aware that if you update your system using CVS, it is possible that
+you could be running code that is very beta and not fully tested. There is
+a possibility that it could be unstable.
I am of course assuming that you have a machine with both DXSpider and
@@ -2203,6 +1536,50 @@ default for nodes and users eg:-
accept/ann user_default by G,M,2
+
+
+Create an 'accept this routing PC Protocol' line for a filter.
+
+
+An accept filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is passed thru that interface. See HELP FILTERING for more info. Please read this
+to understand how filters work - it will save a lot of grief later on.
+
+
+You can use any of the following things in this line:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to accept everything eg:
+
+
@@ -2389,7 +1766,9 @@ default for nodes and users eg:-
Send an announcement to LOCAL users only, where <text> is the text
-of the announcement you wish to broadcast
+of the announcement you wish to broadcast. If you do not wish to receive
+announces, use the set/noannounce command. Any announces made by
+a sysop will override set/noannounce.
-
-
-Reload the /spider/data/baddx.pl file if you have changed it manually whilst
-the cluster is running. This table contains the DX Calls that, if spotted,
-will not be passed on. FR0G and TEST are classic examples.
-
@@ -2964,21 +2330,6 @@ the cluster is running. This table contains a number of perl regular
expressions which are searched for in the fields targetted of each message.
If any of them match then that message is immediately deleted on receipt.
-
-
-
-Reload the /spider/data/badwords file if you have changed it manually whilst
-the cluster is running. This file contains a list of words which, if found
-on certain text portions of PC protocol, will cause those protocol frames
-to be rejected. It will all put out a message if any of these words are
-used on the announce, dx and talk commands. The words can be one or
-more on a line, lines starting with '#' are ignored.
-
@@ -3228,6 +2579,47 @@ default for nodes and users eg:-
reject/ann user_default by G,M,2
+
+
+Create an 'reject this routing PC Protocol' line for a filter.
+
+
+An reject filter line means that if a PC16/17/19/21/24/41/50 matches this filter
+it is NOT passed thru that interface. See HELP FILTERING for more info. Please
+read this to understand how filters work - it will save a lot of grief later on.
+You can use any of the following things in this line:-
+
+
+some examples:-
+
+
+You can use the tag 'all' to reject everything eg:
+
+
@@ -3578,6 +2970,13 @@ Use with extreme care. This command may well be superceded by FILTERing.
Add a beep to DX and other terminal messages.
+
+
+
@@ -4063,6 +3462,43 @@ for more information.
Display all the bad spotter's callsigns in the system, see SET/BADSPOTTER
for more information.
+
+
+
+This command allows you to see all the users that can be seen
+and the nodes to which they are connected. With the optional node,
+you can specify a particular node to look at.
+
+This command is normally abbreviated to: sh/c
+
+BE WARNED: the list that is returned can be VERY long
+
+
+
+
+Show all the nodes connected locally and the nodes they have connected.
+
+
+
+
+This command shows information on all the active connections known to
+the node. This command gives slightly more information than WHO.
+
@@ -4632,6 +4068,24 @@ Only the fields that are defined (in perl term) will be displayed.
This command shows the internal status of a message and includes information
such as to whom it has been forwarded, its size, origin etc etc.
+
+If no message number is given then the status of the message system is
+displayed.
+
+
+
+
+
+