Updated documentation
This commit is contained in:
Michiel Broek
@@ -1,4 +1,5 @@
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
@@ -11,7 +12,7 @@
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 07-Jan-2002</h5>
|
||||
<h5>Last update 21-Jan-2002</h5>
|
||||
<P> <P>
|
||||
|
||||
<h1>MBSE BBS Programs.</h1>
|
||||
@@ -24,7 +25,6 @@
|
||||
<li><A HREF="mbchat.html">mbchat, Sysop to user chat utility</A>
|
||||
<li><A HREF="mbcico.html">mbcico, The Fidonet mailer ala ifcico</A>
|
||||
<li><A HREF="mbdiff.html">mbdiff, Nodelist difference processor</A>
|
||||
<li><A HREF="mbfbgen.html">mbfbgen, FileBase Generator utility</A>
|
||||
<li><A HREF="mbfido.html">mbfido, Fidonet mail and files procesor</A>
|
||||
<li><A HREF="mbfile.html">mbfile, Files database maintenance program</A>
|
||||
<li><A HREF="mbindex.html">mbindex, Nodelist index compiler</A>
|
||||
|
||||
@@ -1,222 +1,263 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" "content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbcico - The Fidonet mailer.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 30-Jan-2001</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbcico - The Fidonet mailer.</H1>
|
||||
|
||||
<P>
|
||||
This is work in progress....
|
||||
<P>
|
||||
|
||||
<h3>Synopsis.</H3>
|
||||
<P>
|
||||
<code>-r<role> -a<inetaddr> <node> ...</code><br>
|
||||
<code>-r 0|1 </code>1 - master, o - slave [0]<br>
|
||||
<code>-n<phone> </code>forced phone number<br>
|
||||
<code>-l<ttydevice> </code>forced tty device<br>
|
||||
<code>-t<tcpmode> </code>telnet TCP/IP mode, must be one of ifc|itn|ibn, forces TCP/IP<br>
|
||||
<code>-a<inetaddr> </code>supply internet hostname if not in nodelist<br>
|
||||
<code> <node> </code>should be in domain form, e.g. f11.n22.z3
|
||||
(this implies master mode)<br>
|
||||
<code>-h </code>show this help message<br>
|
||||
<br>
|
||||
or: <code>mbcico tsync|yoohoo|**EMSI_INQC816|-t ibn|-t ifc|-t itn</code> (this implies slave mode)
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbcico</strong> stands for MBse "Internet - Fidonet Copy In /Copy Out",
|
||||
this is a FidoNet(r) compatible transport agent. It is based on <strong>
|
||||
ifcico</strong> written by Eugene G. Crosser, <crosser@average.org>,
|
||||
2:5020/230@FidoNet. I changed the name of the program to make the difference
|
||||
between <strong>ifcico</strong> and <strong>mbcico</strong>. Nowadays it is
|
||||
quite different then ifcico.
|
||||
<P>
|
||||
Currently it supports FTS-0001, YooHoo/2U2 and EMSI handshake protocols,
|
||||
Xmodem, Telink, Modem7, Hydra, SEAlink with and without overdrive and
|
||||
crash recovery, Bark file and update requests, WaZoo protocols: DietIFNA,
|
||||
plain Zmodem (aka ZedZip, EMSI flag "ZMO") and ZedZap, WaZoo file and
|
||||
update requests (nodelist flag should be XA). WaZoo file and update requests
|
||||
do also work with FTS-0001 sessions, this is supported by several well known DOS
|
||||
mailers also.
|
||||
Password protected requests and update requests are implemented (but not
|
||||
yet full tested).
|
||||
<P>
|
||||
There is also a special protocol optimized to use over TCP/IP connections,
|
||||
contributed by Stanislav Voronyi <stas@uanet.kharkov.ua>, it is
|
||||
identiefied by EMSI proto code TCP (not registered) and nodelist flag IFC.
|
||||
The default port is 60179. There is a telnet variant on this, the default
|
||||
port is 23, and nodelist flag is ITN. The telnet variant is written by
|
||||
T. Tanaka.
|
||||
<P>
|
||||
There is also a <strong>Binkp</strong> implementation, this is a
|
||||
bi-directional TCP/IP protocol.
|
||||
This protocol is prefferred over the IFC protocol because it is
|
||||
more efficient. Nodelist flag is IBN, the default port is 24554, and the
|
||||
nodelist request flag is XX. This Binkp implementation supports multiple
|
||||
batches, however this is only tested against another <strong>mbcico.</strong>
|
||||
I don't know if any other mailer supports this option, but it is documented
|
||||
in the spec's.
|
||||
<P>
|
||||
Outbound directory structure is BinkleyTerm compatible, with domains and
|
||||
point subdirectories (full 5d). There are separate "protected" and
|
||||
"unprotected" inbound directories for the incoming sessions with the nodes
|
||||
that are in your setup. Files received during outbound sessions are always
|
||||
stored in the "protected" inbound.
|
||||
<P>
|
||||
"Magic" file request processors are executable files placed in the "magic"
|
||||
directory. If a request is made for a file with matching name, the
|
||||
executable from the "magic" directory is run, and its stdout output is mailed
|
||||
to the requestor. Full requestor's address, in the form of "John Smith of
|
||||
1:234/56/7" is passed to the executable in the command line. Non-executable
|
||||
files in the magic directory contain the full names to magic filenames. The
|
||||
magic NODELIST can thus point to the full path and filename of your latest
|
||||
nodelist. These magic names are automatic maintained by the <strong>mbfido</strong>
|
||||
program when the magic name is set in the .tic file that you receive.
|
||||
<P>
|
||||
To run <strong>mbcico</strong> in master mode, you need to make dialout
|
||||
devices read/writeable for <strong>mbcico</strong>, and do the same for
|
||||
the directory where your uucp locks are created (usually /var/locks).
|
||||
<P> <P>
|
||||
|
||||
<h3>Answer Mode.</h3>
|
||||
<P>
|
||||
To make <strong>mbcico</strong> work in answer mode, you need <strong>
|
||||
mgetty</strong> written by Gert Doering. <strong>mbcico</strong> must be
|
||||
started with one of the following parameters:
|
||||
<P><PRE>
|
||||
FTS-0001 call: "/opt/mbse/bin/mbcico tsync"
|
||||
FTS-0006 call: "/opt/mbse/bin/mbcico yoohoo"
|
||||
EMSI call: "/opt/mbse/bin/mbcico **EMSI_....."
|
||||
</PRE><P>
|
||||
In the latter case the received EMSI packet should be passed whitout trailing
|
||||
CR). To make this work <strong>mgetty</strong> must be compiled with the
|
||||
-DFIDO option. Other getty programs might work.
|
||||
<P>
|
||||
To answer TCP/IP calls the following lines should be added to /etc/inetd.conf:
|
||||
<P><PRE>
|
||||
binkd stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t ibn
|
||||
tfido stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t itn
|
||||
fido stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t ifc
|
||||
</PRE><P>
|
||||
In the file /etc/services the following lines must be present:
|
||||
<P><PRE>
|
||||
binkd 24554/tcp # mbcico IBN mode
|
||||
tfido 60177/tcp # mbcico ITN mode
|
||||
fido 60179/tcp # mbcico IFC mode
|
||||
mbse 60180/tcp # MBSE BBS deamon
|
||||
</PRE><P>
|
||||
In this case I installed the ITN mode at port 60177 instead of 23 like most
|
||||
sysops do.
|
||||
<P> <P>
|
||||
|
||||
|
||||
<h3>Master Mode.</h3>
|
||||
<P>
|
||||
To make <strong>mbcico</strong> scan for pending outbound mail and do
|
||||
appropriate calls, start it with <strong>-r1</strong> flag. It will check
|
||||
for Zone Mail Hour, outside ZMH only crash mail is delivered. Mail to
|
||||
non-CM systems is only send when mail has the Immedidate status.
|
||||
Poll request are always honnored, even to non-CM systems if there is a
|
||||
<strong>poll</strong> request in the outbound. Be carefull.
|
||||
The taskmanager <strong>mbtask</strong> will start calling <strong>mbcico -r1</strong>
|
||||
if it has seen the <b>scanout</b> semafore. After all calls are completed <b>mbcico</b>
|
||||
will remove the <b>scanout</b> semafore.
|
||||
During ZMH all non-compressed mail is send. File requests in the outbound do not
|
||||
force calling a system. If you make a filerequest, you must also make a
|
||||
poll for that node to really start the request. You can also force a call
|
||||
by entering <strong>mbcico f2802.n280.z2</strong> on the commandline.
|
||||
Only one call is made then and there is no dial delay. If <b>mbcico -r1</b> is
|
||||
called a random dialdelay is used with each call except for internet calls.
|
||||
<P> <P>
|
||||
|
||||
<h3>Environment.</H3>
|
||||
<P>
|
||||
In order to run the mbcico you need to set one global environment variable
|
||||
<strong>$MBSE_ROOT</strong>
|
||||
This variable must point to the root of the bbs directoy structure.
|
||||
<P> <P>
|
||||
|
||||
<H3>Return Codes.</H3>
|
||||
<P>
|
||||
<pre>
|
||||
0 - No errors
|
||||
1..32 - Linux errors, SIGHUP, SIGKILL, etc.
|
||||
101 - No dialout ports available.
|
||||
102 - Dial failed (no CONNECT or TCP connection failed).
|
||||
103 - Could not reset the modem (no OK).
|
||||
104 - System is locked.
|
||||
105 - not used?
|
||||
106 - Nodelist lookup failed.
|
||||
107 - Call prohibited by config options.
|
||||
108 - Phone number unavailable.
|
||||
109 - No matching ports defined.
|
||||
110 - Tried to call a CM system outside ZMH.
|
||||
111..129 - Session failures (not defined).
|
||||
130 - Could not establish session, system is marked undialable.
|
||||
</pre>
|
||||
These codes are also stored in status files for nodes, with the extension
|
||||
of ".sts". These are small datafiles containing three decimal numbers.
|
||||
<ol>
|
||||
<li>Time retry code, this is the last call attempt time. This is an unsigned
|
||||
long representing the number of seconds since the epoch.
|
||||
<li>Retries, this is the number of consequtive call attempts made that returned
|
||||
"call failed" or other errors. This field is zeroed when the call succeeds and
|
||||
when a new "poll" is created. If the value is 30, the node won't be called
|
||||
anymore.
|
||||
<li>Code, this is the return code of the last attempt.
|
||||
</ol>
|
||||
<p> <p>
|
||||
|
||||
<h3>Configuration.</H3>
|
||||
<P>
|
||||
The behaviour of mbcico can be configured with <strong>mbsetup</strong>,
|
||||
section 1.16 If something doesn't do what you want, set the debug on for
|
||||
that problem. This will produce huge logfiles, but also a lot of information.
|
||||
Important flags are Device IO, EMSI debug, File forward, Locking, Outboundscan
|
||||
and Session.
|
||||
<P> <P>
|
||||
|
||||
<h3>Bugs.</H3>
|
||||
<P>
|
||||
Incoming calls from McMail mailers, McMail is quite hasty
|
||||
to establish an EMSI session, and times out in less than a second. So
|
||||
if your system is heavy loaded, or not too fast, McMail cannot connect
|
||||
with your system. This is a known problem with McMail 1.0 and older,
|
||||
later versions are ok.
|
||||
<P> <P>
|
||||
|
||||
<H3>Authors.</H3>
|
||||
<P>
|
||||
<pre>
|
||||
Eugene G. Crosser <crosser@average.org> Orginal ifcico.
|
||||
Stanislav Voronyi <stas@uanet.kharkov.ua> TCP/IP code.
|
||||
T. Tanaka Telnet mode.
|
||||
Martin Junius Rewrite of opentcp().
|
||||
Omen Technology Inc Zmodem protocol.
|
||||
Arjen G. Lentz, Joaquim H. Homrighausen Hydra transfer protocol.
|
||||
Cristof Meerwald Implementation of Hydra in ifcico.
|
||||
P. Saratxaga Tty driver code, yoohoo extensions.
|
||||
Dima Maloff Binkp protocol.
|
||||
Michiel Broek Rewrite for MBSE BBS.
|
||||
</pre>
|
||||
<P>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0" width="40" height="30"> Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0" width="33" height="35"> Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbcico - The Fidonet mailer.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 21-Jan-2002</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbcico - The Fidonet mailer.</H1>
|
||||
|
||||
<P>
|
||||
This is work in progress....
|
||||
<P>
|
||||
|
||||
<h3>Synopsis.</H3>
|
||||
<P>
|
||||
<code>-r<role> -a<inetaddr> <node> ...</code><br>
|
||||
<code>-r 0|1 </code>1 - master, o - slave [0]<br>
|
||||
<code>-n<phone> </code>forced phone number<br>
|
||||
<code>-l<ttydevice> </code>forced tty device<br>
|
||||
<code>-t<tcpmode> </code>telnet TCP/IP mode, must be one of ifc|itn|ibn, forces TCP/IP<br>
|
||||
<code>-a<inetaddr> </code>supply internet hostname if not in nodelist<br>
|
||||
<code> <node> </code>should be in domain form, e.g. f11.n22.z3
|
||||
(this implies master mode)<br>
|
||||
<code>-h </code>show this help message<br>
|
||||
<br>
|
||||
or: <code>mbcico tsync|yoohoo|**EMSI_INQC816|-t ibn|-t ifc|-t itn</code> (this implies slave mode)
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbcico</strong> stands for MBse "Internet - Fidonet Copy In /Copy Out",
|
||||
this is a FidoNet(r) compatible transport agent. It is based on <strong>
|
||||
ifcico</strong> written by Eugene G. Crosser, <crosser@average.org>,
|
||||
2:5020/230@FidoNet. I changed the name of the program to make the difference
|
||||
between <strong>ifcico</strong> and <strong>mbcico</strong>. Nowadays it is
|
||||
quite different then ifcico.
|
||||
<P>
|
||||
Currently it supports FTS-0001, YooHoo/2U2 and EMSI handshake protocols,
|
||||
Xmodem, Telink, Modem7, Hydra, SEAlink with and without overdrive and
|
||||
crash recovery, Bark file and update requests, WaZoo protocols: DietIFNA,
|
||||
plain Zmodem (aka ZedZip, EMSI flag "ZMO") and ZedZap, WaZoo file and
|
||||
update requests (nodelist flag should be XA). WaZoo file and update requests
|
||||
do also work with FTS-0001 sessions, this is supported by several well known DOS
|
||||
mailers also.
|
||||
Password protected requests and update requests are implemented (but not
|
||||
yet full tested).
|
||||
<P>
|
||||
There is also a special protocol optimized to use over TCP/IP connections,
|
||||
contributed by Stanislav Voronyi <stas@uanet.kharkov.ua>, it is
|
||||
identiefied by EMSI proto code TCP (not registered) and nodelist flag IFC.
|
||||
The default port is 60179. There is a telnet variant on this, the default
|
||||
port is 23, and nodelist flag is ITN. The telnet variant is written by
|
||||
T. Tanaka.
|
||||
<P>
|
||||
There is also a <strong>Binkp</strong> implementation, this is a
|
||||
bi-directional TCP/IP protocol.
|
||||
This protocol is prefferred over the IFC protocol because it is
|
||||
more efficient. Nodelist flag is IBN, the default port is 24554, and the
|
||||
nodelist request flag is XX. This Binkp implementation supports multiple
|
||||
batches, however this is only tested against another <strong>mbcico.</strong>
|
||||
I don't know if any other mailer supports this option, but it is documented
|
||||
in the spec's.
|
||||
<P>
|
||||
Outbound directory structure is BinkleyTerm compatible, with domains and
|
||||
point subdirectories (full 5d). There are separate "protected" and
|
||||
"unprotected" inbound directories for the incoming sessions with the nodes
|
||||
that are in your setup. Files received during outbound sessions are always
|
||||
stored in the "protected" inbound.
|
||||
<P>
|
||||
"Magic" file request processors are executable files placed in the "magic"
|
||||
directory. If a request is made for a file with matching name, the
|
||||
executable from the "magic" directory is run, and its stdout output is mailed
|
||||
to the requestor. Full requestor's address, in the form of "John Smith of
|
||||
1:234/56/7" is passed to the executable in the command line. Non-executable
|
||||
files in the magic directory contain the full names to magic filenames. The
|
||||
magic NODELIST can thus point to the full path and filename of your latest
|
||||
nodelist. These magic names are automatic maintained by the <strong>mbfido</strong>
|
||||
program when the magic name is set in the .tic file that you receive.
|
||||
<P>
|
||||
To run <strong>mbcico</strong> in master mode, you need to make dialout
|
||||
devices read/writeable for <strong>mbcico</strong>, and do the same for
|
||||
the directory where your uucp locks are created (usually /var/locks).
|
||||
<P> <P>
|
||||
|
||||
<h3>Answer Mode.</h3>
|
||||
<P>
|
||||
To make <strong>mbcico</strong> work in answer mode, you need <strong>
|
||||
mgetty</strong> written by Gert Doering. <strong>mbcico</strong> must be
|
||||
started with one of the following parameters:
|
||||
<P><PRE>
|
||||
FTS-0001 call: "/opt/mbse/bin/mbcico tsync"
|
||||
FTS-0006 call: "/opt/mbse/bin/mbcico yoohoo"
|
||||
EMSI call: "/opt/mbse/bin/mbcico **EMSI_....."
|
||||
</PRE><P>
|
||||
In the latter case the received EMSI packet should be passed whitout trailing
|
||||
CR). To make this work <strong>mgetty</strong> must be compiled with the
|
||||
-DFIDO option. Other getty programs might work.
|
||||
<P>
|
||||
To answer TCP/IP calls the following lines should be added to /etc/inetd.conf:
|
||||
<P><PRE>
|
||||
binkd stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t ibn
|
||||
tfido stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t itn
|
||||
fido stream tcp nowait mbse /opt/mbse/bin/mbcico mbcico -t ifc
|
||||
</PRE><P>
|
||||
If your system uses xinetd the file /etc/xinetd.d/mbsebbs could be:
|
||||
<P><PRE>
|
||||
#:MBSE BBS services are defined here.
|
||||
|
||||
service binkp
|
||||
{
|
||||
socket_type = stream
|
||||
protocol = tcp
|
||||
wait = no
|
||||
user = mbse
|
||||
instances = 10
|
||||
server = /opt/mbse/bin/mbcico
|
||||
server_args = -t ibn
|
||||
}
|
||||
|
||||
service tfido
|
||||
{
|
||||
socket_type = stream
|
||||
protocol = tcp
|
||||
wait = no
|
||||
user = mbse
|
||||
instances = 10
|
||||
server = /opt/mbse/bin/mbcico
|
||||
server_args = -t itn
|
||||
}
|
||||
|
||||
service fido
|
||||
{
|
||||
socket_type = stream
|
||||
protocol = tcp
|
||||
wait = no
|
||||
user = mbse
|
||||
instances = 10
|
||||
server = /opt/mbse/bin/mbcico
|
||||
server_args = -t ifc
|
||||
}
|
||||
</PRE><P>
|
||||
In the file /etc/services the following lines must be present:
|
||||
<P><PRE>
|
||||
binkd 24554/tcp # mbcico IBN mode
|
||||
tfido 60177/tcp # mbcico ITN mode
|
||||
fido 60179/tcp # mbcico IFC mode
|
||||
mbse 60180/tcp # MBSE BBS deamon
|
||||
</PRE><P>
|
||||
In this case I installed the ITN mode at port 60177 instead of 23 like most
|
||||
sysops do.
|
||||
<P> <P>
|
||||
|
||||
|
||||
<h3>Master Mode.</h3>
|
||||
<P>
|
||||
To make <strong>mbcico</strong> scan for pending outbound mail and do
|
||||
appropriate calls, start it with <strong>-r1</strong> flag. It will check
|
||||
for Zone Mail Hour, outside ZMH only crash mail is delivered. Mail to
|
||||
non-CM systems is only send when mail has the Immedidate status.
|
||||
Poll request are always honnored, even to non-CM systems if there is a
|
||||
<strong>poll</strong> request in the outbound. Be carefull.
|
||||
The taskmanager <strong>mbtask</strong> will start calling <strong>mbcico -r1</strong>
|
||||
if it has seen the <b>scanout</b> semafore. After all calls are completed <b>mbcico</b>
|
||||
will remove the <b>scanout</b> semafore.
|
||||
During ZMH all non-compressed mail is send. File requests in the outbound do not
|
||||
force calling a system. If you make a filerequest, you must also make a
|
||||
poll for that node to really start the request. You can also force a call
|
||||
by entering <strong>mbcico f2802.n280.z2</strong> on the commandline.
|
||||
Only one call is made then and there is no dial delay. If <b>mbcico -r1</b> is
|
||||
called a random dialdelay is used with each call except for internet calls.
|
||||
<P><B>Note:</B> you should not call nodes with mbcico directly, let
|
||||
<b>mbtask</b> do the calling.
|
||||
If you want to call a node make a <a href="mbout.html">poll</a> command.
|
||||
<P> <P>
|
||||
|
||||
<h3>Environment.</H3>
|
||||
<P>
|
||||
In order to run the mbcico you need to set one global environment variable
|
||||
<strong>$MBSE_ROOT</strong>
|
||||
This variable must point to the root of the bbs directoy structure.
|
||||
<P> <P>
|
||||
|
||||
<H3>Return Codes.</H3>
|
||||
<P>
|
||||
<pre>
|
||||
0 - No errors
|
||||
1..32 - Linux errors, SIGHUP, SIGKILL, etc.
|
||||
101 - No dialout ports available.
|
||||
102 - Dial failed (no CONNECT or TCP connection failed).
|
||||
103 - Could not reset the modem (no OK).
|
||||
104 - System is locked.
|
||||
105 - not used?
|
||||
106 - Nodelist lookup failed.
|
||||
107 - Call prohibited by config options.
|
||||
108 - Phone number unavailable.
|
||||
109 - No matching ports defined.
|
||||
110 - Tried to call a CM system outside ZMH.
|
||||
111..129 - Session failures (not defined).
|
||||
130 - Could not establish session, system is marked undialable.
|
||||
</pre>
|
||||
These codes are also stored in status files for nodes, with the extension
|
||||
of ".sts". These are small datafiles containing three decimal numbers.
|
||||
<ol>
|
||||
<li>Time retry code, this is the last call attempt time. This is an unsigned
|
||||
long representing the number of seconds since the epoch.
|
||||
<li>Retries, this is the number of consequtive call attempts made that returned
|
||||
"call failed" or other errors. This field is zeroed when the call succeeds and
|
||||
when a new "poll" is created. If the value is 30, the node won't be called
|
||||
anymore.
|
||||
<li>Code, this is the return code of the last attempt.
|
||||
</ol>
|
||||
<p> <p>
|
||||
|
||||
<h3>Configuration.</H3>
|
||||
<P>
|
||||
The behaviour of mbcico can be configured with <strong>mbsetup</strong>,
|
||||
section 1.17 If something doesn't do what you want, set the debug on for
|
||||
that problem. This will produce huge logfiles, but also a lot of information.
|
||||
Important flags are Device IO, EMSI debug, File forward, Locking, Outboundscan
|
||||
and Session.
|
||||
<P> <P>
|
||||
|
||||
<h3>Bugs.</H3>
|
||||
<P>
|
||||
Incoming calls from McMail mailers, McMail is quite hasty
|
||||
to establish an EMSI session, and times out in less than a second. So
|
||||
if your system is heavy loaded, or not too fast, McMail cannot connect
|
||||
with your system. This is a known problem with McMail 1.0 and older,
|
||||
later versions are ok.
|
||||
<P> <P>
|
||||
|
||||
<H3>Authors.</H3>
|
||||
<P>
|
||||
<pre>
|
||||
Eugene G. Crosser <crosser@average.org> Orginal ifcico.
|
||||
Stanislav Voronyi <stas@uanet.kharkov.ua> TCP/IP code.
|
||||
T. Tanaka Telnet mode.
|
||||
Martin Junius Rewrite of opentcp().
|
||||
Omen Technology Inc Zmodem protocol.
|
||||
Arjen G. Lentz, Joaquim H. Homrighausen Hydra transfer protocol.
|
||||
Cristof Meerwald Implementation of Hydra in ifcico.
|
||||
P. Saratxaga Tty driver code, yoohoo extensions.
|
||||
Dima Maloff Binkp protocol.
|
||||
Michiel Broek Rewrite for MBSE BBS.
|
||||
</pre>
|
||||
<P>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0">Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0">Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
@@ -1,61 +0,0 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" "content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbfbgen - FileBase Generato.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 30-Jan-2001</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbfbgen - FileBase Generator</H1>
|
||||
<P>
|
||||
|
||||
<H3>Synopsis.</H3>
|
||||
<P>
|
||||
<code><strong>mbfbgen</strong></code>
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbfbgen</strong> is used to import filebase areas from CD-ROM. This
|
||||
util works like <strong>fbgen</strong> which is known to RA users. It reads
|
||||
the file <strong>files.bbs</strong> to get the filenames and descriptions
|
||||
to build the filedatabase.
|
||||
<P>
|
||||
To import a filebase you must setup the area with <strong>mbsetup</strong>.
|
||||
If you are really importing from a CD that will stay mounted on your system
|
||||
you must set <strong>CDrom</strong> to yes. If the files.bbs file is not in the
|
||||
directory were the files are, but somewere else on the CD, you must fill in
|
||||
the field <strong>Files.bbs</strong> in the edit file area screen.
|
||||
If the files.bbs file is in the same directory together with the files, you may
|
||||
leave that field blank.
|
||||
It is handy to use a closed range of file areas.
|
||||
Once you are ready with the setup start <strong>mbfbgen</strong>, enter the
|
||||
start and end area numbers, the uploader name, and the import will start.
|
||||
This can last quite long as from each file the 32 bits CRC is calculated
|
||||
that will be stored in the filedatabase. When <strong>mbfbgen</strong> is
|
||||
finished, run <strong>mbfile index</strong> to recreate the filerequest index
|
||||
file.
|
||||
<P> <P>
|
||||
|
||||
<H3>Environmet.</H3>
|
||||
<P>
|
||||
In order to run <strong>fbgen</strong> you must set the global variable
|
||||
<strong>$MBSE_ROOT</strong>. This variable must point to the root directory
|
||||
of the bbs structure. The main configuration file <strong>config.data</strong>
|
||||
must be present in the ~/etc directory.
|
||||
<P>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0" width="40" height="30"> Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0" width="33" height="35"> Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
@@ -1,260 +1,270 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" "content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbfido - The Fidonet mail and files processor.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 10-Jul-2001</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbfido, the fidonet mail and files processor.</H1>
|
||||
<P>
|
||||
|
||||
<h3>Synopsis.</H3>
|
||||
<P>
|
||||
<code>mbfido [command(s)] <options></code>
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbfido</strong>
|
||||
is the program to process fidonet mail and files. In order to run mbfido
|
||||
you must first start <strong>mbtask</strong>,
|
||||
this is the deamon which controls all bbs activities. To prevent that
|
||||
<strong>mbfido</strong> will run more than once at the same time a lock
|
||||
is placed in the protected inbound with the pid of the running
|
||||
<strong>mbfido</strong> program. The gateway to and from internet is also
|
||||
handled by <strong>mbfido</strong>.
|
||||
<P> <P>
|
||||
|
||||
<H3>Specifications.</H3>
|
||||
<p>
|
||||
The recognized mail packets are type 2+ following the FSC-0039 standard with
|
||||
a fallback to the old stone age packets.
|
||||
Can handle messages of maximum 429467295 bytes, or less if you have less
|
||||
memory available, the practical limit is about 1 Meg. Note that most mailprocessors
|
||||
are only guaranteed to work to maximum 16 KBytes.
|
||||
Recent experiments in the LINUX echo show that this is still true,
|
||||
although most tossers seem to process mail up to 32 KBytes.
|
||||
<P> <P>
|
||||
|
||||
<H3>Tossing Mail.</H3>
|
||||
<P>
|
||||
First make sure you have the necessary message areas in your setup. At least
|
||||
you need the badmail and dupemail areas and a netmail area for each network
|
||||
you participate in. If you don't create badmail and dupemail areas then
|
||||
bad (unknown area etc) and dupes are lost and you cannot check the reason why.
|
||||
If you don't create the netmail areas for each network, then netmail to your
|
||||
system will dissapear. It is not possible to "retoss" the badmail yet after
|
||||
you have created any missing echomail areas.
|
||||
<P>
|
||||
To prevent .pkt name collision the toss of incoming mail is done in parts.
|
||||
The first run is to process all uncompressed mailpackets and add mail to the
|
||||
outbound. Then each compressed ARCmail archive will be uncompressed and
|
||||
processed and mail will be imported and forwarded as necessary. During all
|
||||
these passes all filenames are sorted by date and time, the oldest files are
|
||||
processed first.
|
||||
<P>
|
||||
The recognized mail packets are type 2+ following the FSC-0039 standard with
|
||||
a fallback to the old stone age packets. The packets are checked for being
|
||||
addressed to one of your own aka's and for a correct password. The
|
||||
password check may be switched off in the nodes setup. After all the packet
|
||||
header checks the messages will be extracted from the packet file.
|
||||
<P>
|
||||
When messages are extracted from the packets, the date format is checked for
|
||||
Year2000 bugs from other tossers. Several checks are done by ideas of Tobias
|
||||
Ernst of 2:2476/418. It is also possible to run the <strong>pktdate</strong>
|
||||
utility before each packet will be processed. Whatever date format us used in
|
||||
the original message, <strong>mbfido</strong> will always rewrite the date
|
||||
field in the right FTS-0001 format.
|
||||
<P>
|
||||
If the message is a netmail the message is checked for DOMAIN, INTL, FMPT and
|
||||
TOPT kludges so that full 4d or 5d addressing will be possible. Then a check
|
||||
is done if this netmail is addressed to one of our aka's. If it's addressed to
|
||||
"sysop" or "postmaster" the name is replaced with the sysop's name. If the
|
||||
message is addressed to one of the names defined in the service setup, that
|
||||
mail will be handled by the service manager, ie. given to areamgr, filemgr or
|
||||
send further as email to your local system.
|
||||
<BR>
|
||||
Then the message is checked if it is addressed to an existing bbs user, and if
|
||||
so it will be imported into the netmail area of the main zone of the bbs.
|
||||
If it's not addressed to a bbs user, the message will be readdressed to the
|
||||
sysop. If the message is not for one of our aka's the message will be put in the
|
||||
mailqueue for further routing.
|
||||
<P>
|
||||
If the message is a echomail message it will be checked for being a duplicate by
|
||||
storing the CRC32 value of the AREA: line, message subject, origin line,
|
||||
message date and msgid kludge and testing if that CRC32 value exists in the
|
||||
echomail duplicate database. If there is no msgid in the message, the whole
|
||||
message body will be include to complete the CRC32 dupe check.
|
||||
Also the existance of the echomail area is checked and the node must be linked to that area.
|
||||
If the message is not in a passthru area and is not a duplicate it
|
||||
is finally imported in the message base.
|
||||
After that is the message will be forwarded to downlinks
|
||||
by adding the message to the mailqueue.
|
||||
<P> <P>
|
||||
|
||||
<h3>Adding mail to the outbound.</h3>
|
||||
<P>
|
||||
Adding mail to the outbound is done in two passes. The first pass is to put all
|
||||
outgoing mail into the ~/tmp directory, these files are named z.n.n.p.ext
|
||||
The extension can be qqq for packed mail, nnn for normal unpacked mail, hhh for
|
||||
hold unpacked mail and ccc for crash unpacked mail. Adding mail to this tmp
|
||||
directory can allways be done, even if one of the nodes you are adding mail
|
||||
for is having a mail session with your system. This is a safe operation.<br>
|
||||
In the second pass, these temp files are really added to the outbound, but
|
||||
only if the destination node is not locked, ie. there is no current mailsession
|
||||
with that node. If there is a mail session going, these temp files will stay in
|
||||
the temp directory and are added to the outbound in a later run of
|
||||
<strong>mbfido</strong>. If adding the mail to the outbound succeeds
|
||||
the temporary file is removed.
|
||||
<P> <P>
|
||||
|
||||
<H3>Alias file.</H3>
|
||||
<P>
|
||||
If the file /opt/mbse/etc/aliases exists, mbfido will try to fetch ftn-style
|
||||
aliases from there.
|
||||
If "from" address of a message from FidoNet matches <b>right</b> side
|
||||
of some entry in alias file, then the Reply-To: header is created
|
||||
in the RFC message with the name part taken from the left side of the
|
||||
sysalis entry and domain part taken from myfqdn (below). E.g., if a
|
||||
fidonet message comes from "John Smith of 1:234/567.89@fidonet" and
|
||||
there is an entry in the sysalias file:
|
||||
<pre>
|
||||
"jsmith: John.Smith@p89.f567.n234.z1.fidonet.org"
|
||||
</pre>
|
||||
and Domain name value is "mbse.nl", then the resulting message will
|
||||
contain a line: "Reply-To: jsmith@mbse.nl".
|
||||
<P> <P>
|
||||
|
||||
<H3>Commands.</H3>
|
||||
<P>
|
||||
<code><strong>mbfido</strong> notify <nodes></code>
|
||||
This command will send notify messages to all nodes in your setup which
|
||||
have the notify option set to on. If you enter nodes as option you may use
|
||||
wilcards, ie 2:*/* to send messages to all nodes in zone 2. If you specify
|
||||
exactly one node, messages will be generated even if that node has the
|
||||
notify function off. From cron you should not specify any nodes, this will
|
||||
just send to all your links the information about their setup. Each node
|
||||
will receive a status report for files and mail, and area list for all
|
||||
file areas and mail areas to each aka a node has, and a flow report for
|
||||
mail for each aka.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> roll</code>
|
||||
This command will only do something if a new week or month has begun.
|
||||
If this is true the statistic records in several databases are updated.
|
||||
You should run this command each midnight from cron to be sure that this when it is
|
||||
time to do so. This command is always executed before one of the scan, toss or tic commands so
|
||||
if you don't do this in cron, it will still happen.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> scan</code>
|
||||
Scan for new messages entered at the bbs or by other utilities. If the file
|
||||
~/tmp/echomail.jam or ~/tmp/netmail.jam exists,
|
||||
mbfido will only scan the messages in areas which are
|
||||
pointed at in this file. This is a lot faster then a full mailscan.
|
||||
If it is not present, all messagebases are scanned
|
||||
to see if there is a new message. If you specify
|
||||
<strong>-full</strong> on the commandline a full messagebase scan is forced.
|
||||
It is wise to do this sometimes, on my bbs I run this once a day.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> tag</code>
|
||||
The command will create tag- and areas files in the doc directory for each group of
|
||||
mail and files.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> test</code>
|
||||
This is for testing of the mail routing. In the source "tracker.c" I have
|
||||
included a list of nodes that will be tested. This is for development only,
|
||||
but it might be handy for you to test your netmail routing.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> tic</code>
|
||||
Process incoming files accompanied with .tic control files. Several actions can
|
||||
take place on the incoming file before they are imported in the BBS areas.
|
||||
Options are rearchiving, replacing banners (with your add), check for DOS
|
||||
viruses, running scripts for certain filename patterns, send these files to
|
||||
other nodes etc. All options can be defined for each area. If as a result from
|
||||
one of the actions there are new files hatched, for example after processing
|
||||
a nodelist difference file which created a new nodelist, the .tic processing
|
||||
will start again, until there is really nothing more to do.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> toss</code>
|
||||
Toss incoming fidonet netmail and or echomail. By default mail in the protected
|
||||
inbound directory will be processed, uncompressed .pkt files and compressed
|
||||
arcmail bundles are recognized, filename case doesn't matter.
|
||||
<P>
|
||||
<code><b>mbfido</b> news</code> Scan all defined newsgroups for new newsarticles.
|
||||
New articles are fetched from the newsserver and stored in your messagebase and
|
||||
send to your up- and downlinks. This is for use with an NNTP gateway.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> uucp</code>
|
||||
This will read a standard a newsbatch from stdin and gate the articles
|
||||
to Fidonet and the local message base. This is for use with an UUCP gateway, this
|
||||
mode should be called by uuxqt. The newsbatch may be compressed or uncompressed or
|
||||
a single news article.
|
||||
<P>
|
||||
<code><strong>mbnews</strong></code>
|
||||
This is an alternative to <strong>mbfido uucp -quiet</strong>.
|
||||
<P> <P>
|
||||
|
||||
<h3>Options.</h3>
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -nocrc</code>
|
||||
Disable CRC checking of incoming TIC files. Only use this if you know what
|
||||
you are doing.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> scan -full</code>
|
||||
Force scanning of all message bases for new entered mail. You need this if
|
||||
mail in entered with other editors then from mbse. Also, running it once a
|
||||
day is adviced to catch any missed messages.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> news -learn</code>
|
||||
Scan the newsserver for news articles, and update the news dupes database only.
|
||||
Use this switch if you start using mbfido to gate news articles for the first time.
|
||||
Articles will not be gated with this switch, mbfido will just learn which articles
|
||||
already exist. Normally you only need to use this switch once.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -nodupe</code>
|
||||
Disable checking for duplicate's. Normally you should not use this switch.
|
||||
This switch doesn't work with the news command, only for echomail and tic files.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -quiet</code>
|
||||
Quiet mode, all output to the current tty is supressed. Use this flag if
|
||||
you toss mail from a script (started by cron) after mail is received.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> toss -a</code> Toss mail and allow to autocreate
|
||||
new message areas. See the <A HREF="../setup/emareas.html"> message area setup</A>
|
||||
how to set this up.
|
||||
<code><strong>mbfido</strong> toss -unsecure</code>
|
||||
Toss mail without checking if the echomail is for your own system en without
|
||||
checking if the sending node is connected to your system. Nodes who are
|
||||
excluded from a certain echo, can stil not enter messages in that echo.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -unprotect</code>
|
||||
Toss from the unprotected inbound directory. The default is to toss from the
|
||||
protected inbound directory.
|
||||
<P> <P>
|
||||
|
||||
<h3>Environment.</H3>
|
||||
<P>
|
||||
In order to run the bbs you need to set one global environment variable
|
||||
<strong>$MBSE_ROOT</strong>
|
||||
This variable must point to the root of the bbs directoy structure.
|
||||
<P> <P>
|
||||
|
||||
<h3>Bugs.</H3>
|
||||
<P>
|
||||
There are still bugs, this program is under development.
|
||||
<P>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0" width="40" height="30"> Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0" width="33" height="35"> Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbfido - The Fidonet mail and files processor.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 21-Jan-2002</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbfido, the fidonet mail and files processor.</H1>
|
||||
<P>
|
||||
|
||||
<h3>Synopsis.</H3>
|
||||
<P>
|
||||
<code>mbfido [command(s)] <options></code>
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbfido</strong>
|
||||
is the program to process fidonet mail and files. In order to run mbfido
|
||||
you must first start <strong>mbtask</strong>,
|
||||
this is the deamon which controls all bbs activities. To prevent that
|
||||
<strong>mbfido</strong> will run more than once at the same time a lock
|
||||
is placed in the protected inbound with the pid of the running
|
||||
<strong>mbfido</strong> program. The gateway to and from internet is also
|
||||
handled by <strong>mbfido</strong>.
|
||||
<P> <P>
|
||||
|
||||
<H3>Specifications.</H3>
|
||||
<p>
|
||||
The recognized mail packets are type 2+ following the FSC-0039 standard with
|
||||
a fallback to the old stone age packets.
|
||||
Can handle messages of maximum 429467295 bytes, or less if you have less
|
||||
memory available, the practical limit is about 1 Meg. Note that most mailprocessors
|
||||
are only guaranteed to work to maximum 16 KBytes.
|
||||
Recent experiments in the LINUX echo show that this is still true,
|
||||
although most tossers seem to process mail up to 32 KBytes.
|
||||
<P> <P>
|
||||
|
||||
<H3>Tossing Mail.</H3>
|
||||
<P>
|
||||
First make sure you have the necessary message areas in your setup. At least
|
||||
you need the badmail and dupemail areas and a netmail area for each network
|
||||
you participate in. If you don't create badmail and dupemail areas then
|
||||
bad (unknown area etc) and dupes are lost and you cannot check the reason why.
|
||||
If you don't create the netmail areas for each network, then netmail to your
|
||||
system will dissapear. It is not possible to "retoss" the badmail yet after
|
||||
you have created any missing echomail areas.
|
||||
<P>
|
||||
To prevent .pkt name collision the toss of incoming mail is done in parts.
|
||||
The first run is to process all uncompressed mailpackets and add mail to the
|
||||
outbound. Then each compressed ARCmail archive will be uncompressed and
|
||||
processed and mail will be imported and forwarded as necessary. During all
|
||||
these passes all filenames are sorted by date and time, the oldest files are
|
||||
processed first.
|
||||
<P>
|
||||
The recognized mail packets are type 2+ following the FSC-0039 standard with
|
||||
a fallback to the old stone age packets. The packets are checked for being
|
||||
addressed to one of your own aka's and for a correct password. The
|
||||
password check may be switched off in the nodes setup. After all the packet
|
||||
header checks the messages will be extracted from the packet file.
|
||||
<P>
|
||||
When messages are extracted from the packets, the date format is checked for
|
||||
Year2000 bugs from other tossers. Several checks are done by ideas of Tobias
|
||||
Ernst of 2:2476/418. It is also possible to run the <strong>pktdate</strong>
|
||||
utility before each packet will be processed. Whatever date format us used in
|
||||
the original message, <strong>mbfido</strong> will always rewrite the date
|
||||
field in the right FTS-0001 format.
|
||||
<P>
|
||||
If the message is a netmail the message is checked for DOMAIN, INTL, FMPT and
|
||||
TOPT kludges so that full 4d or 5d addressing will be possible. Then a check
|
||||
is done if this netmail is addressed to one of our aka's. If it's addressed to
|
||||
"sysop" or "postmaster" the name is replaced with the sysop's name. If the
|
||||
message is addressed to one of the names defined in the service setup, that
|
||||
mail will be handled by the service manager, ie. given to areamgr, filemgr or
|
||||
send further as email to your local system.
|
||||
<BR>
|
||||
Then the message is checked if it is addressed to an existing bbs user, and if
|
||||
so it will be imported into the netmail area of the main zone of the bbs.
|
||||
If it's not addressed to a bbs user, the message will be readdressed to the
|
||||
sysop. If the message is not for one of our aka's the message will be put in the
|
||||
mailqueue for further routing.
|
||||
<P>
|
||||
If the message is a echomail message it will be checked for being a duplicate by
|
||||
storing the CRC32 value of the AREA: line, message subject, origin line,
|
||||
message date and msgid kludge and testing if that CRC32 value exists in the
|
||||
echomail duplicate database. If there is no msgid in the message, the whole
|
||||
message body will be include to complete the CRC32 dupe check.
|
||||
Also the existance of the echomail area is checked and the node must be linked to that area.
|
||||
If the message is not in a passthru area and is not a duplicate it
|
||||
is finally imported in the message base.
|
||||
After that is the message will be forwarded to downlinks
|
||||
by adding the message to the mailqueue.
|
||||
<P> <P>
|
||||
|
||||
<h3>Adding mail to the outbound.</h3>
|
||||
<P>
|
||||
Adding mail to the outbound is done in two passes. The first pass is to put all
|
||||
outgoing mail into the ~/tmp directory, these files are named z.n.n.p.ext
|
||||
The extension can be qqq for packed mail, nnn for normal unpacked mail, hhh for
|
||||
hold unpacked mail and ccc for crash unpacked mail. Adding mail to this tmp
|
||||
directory can allways be done, even if one of the nodes you are adding mail
|
||||
for is having a mail session with your system. This is a safe operation.<br>
|
||||
In the second pass, these temp files are really added to the outbound, but
|
||||
only if the destination node is not locked, ie. there is no current mailsession
|
||||
with that node. If there is a mail session going, these temp files will stay in
|
||||
the temp directory and are added to the outbound in a later run of
|
||||
<strong>mbfido</strong>. If adding the mail to the outbound succeeds
|
||||
the temporary file is removed.
|
||||
<P> <P>
|
||||
|
||||
<H3>Alias file.</H3>
|
||||
<P>
|
||||
If the file /opt/mbse/etc/aliases exists, mbfido will try to fetch ftn-style
|
||||
aliases from there.
|
||||
If "from" address of a message from FidoNet matches <b>right</b> side
|
||||
of some entry in alias file, then the Reply-To: header is created
|
||||
in the RFC message with the name part taken from the left side of the
|
||||
sysalis entry and domain part taken from myfqdn (below). E.g., if a
|
||||
fidonet message comes from "John Smith of 1:234/567.89@fidonet" and
|
||||
there is an entry in the sysalias file:
|
||||
<pre>
|
||||
"jsmith: John.Smith@p89.f567.n234.z1.fidonet.org"
|
||||
</pre>
|
||||
and Domain name value is "mbse.nl", then the resulting message will
|
||||
contain a line: "Reply-To: jsmith@mbse.nl".
|
||||
<P> <P>
|
||||
|
||||
<H3>Commands.</H3>
|
||||
<P>
|
||||
<code><strong>mbfido</strong> mail <recipient></code>
|
||||
This command is used by your MTA to deliver email addressed to for example
|
||||
Michiel_Broek@f2802.n280.z2.fidonet.org
|
||||
|
||||
<P>
|
||||
<code><strong>mbmail</strong> <recipient></code>
|
||||
This is the same as above.
|
||||
|
||||
<P>
|
||||
<code><strong>mbfido</strong> notify <nodes></code>
|
||||
This command will send notify messages to all nodes in your setup which
|
||||
have the notify option set to on. If you enter nodes as option you may use
|
||||
wilcards, ie 2:*/* to send messages to all nodes in zone 2. If you specify
|
||||
exactly one node, messages will be generated even if that node has the
|
||||
notify function off. From cron you should not specify any nodes, this will
|
||||
just send to all your links the information about their setup. Each node
|
||||
will receive a status report for files and mail, and area list for all
|
||||
file areas and mail areas to each aka a node has, and a flow report for
|
||||
mail for each aka.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> roll</code>
|
||||
This command will only do something if a new week or month has begun.
|
||||
If this is true the statistic records in several databases are updated.
|
||||
You should run this command each midnight from cron to be sure that this when it is
|
||||
time to do so. This command is always executed before one of the scan, toss or tic commands so
|
||||
if you don't do this in cron, it will still happen.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> scan</code>
|
||||
Scan for new messages entered at the bbs or by other utilities. If the file
|
||||
~/tmp/echomail.jam or ~/tmp/netmail.jam exists,
|
||||
mbfido will only scan the messages in areas which are
|
||||
pointed at in this file. This is a lot faster then a full mailscan.
|
||||
If it is not present, all messagebases are scanned
|
||||
to see if there is a new message. If you specify
|
||||
<strong>-full</strong> on the commandline a full messagebase scan is forced.
|
||||
It is wise to do this sometimes, on my bbs I run this once a day.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> tag</code>
|
||||
The command will create tag- and areas files in the doc directory for each group of
|
||||
mail and files.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> test</code>
|
||||
This is for testing of the mail routing. In the source "tracker.c" I have
|
||||
included a list of nodes that will be tested. This is for development only,
|
||||
but it might be handy for you to test your netmail routing.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> tic</code>
|
||||
Process incoming files accompanied with .tic control files. Several actions can
|
||||
take place on the incoming file before they are imported in the BBS areas.
|
||||
Options are rearchiving, replacing banners (with your add), check for DOS
|
||||
viruses, running scripts for certain filename patterns, send these files to
|
||||
other nodes etc. All options can be defined for each area. If as a result from
|
||||
one of the actions there are new files hatched, for example after processing
|
||||
a nodelist difference file which created a new nodelist, the .tic processing
|
||||
will start again, until there is really nothing more to do.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> toss</code>
|
||||
Toss incoming fidonet netmail and or echomail. By default mail in the protected
|
||||
inbound directory will be processed, uncompressed .pkt files and compressed
|
||||
arcmail bundles are recognized, filename case doesn't matter.
|
||||
<P>
|
||||
<code><b>mbfido</b> news</code> Scan all defined newsgroups for new newsarticles.
|
||||
New articles are fetched from the newsserver and stored in your messagebase and
|
||||
send to your up- and downlinks. This is for use with an NNTP gateway.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> uucp</code>
|
||||
This will read a standard a newsbatch from stdin and gate the articles
|
||||
to Fidonet and the local message base. This is for use with an UUCP gateway, this
|
||||
mode should be called by uuxqt. The newsbatch may be compressed or uncompressed or
|
||||
a single news article.
|
||||
<P>
|
||||
<code><strong>mbnews</strong></code>
|
||||
This is an alternative to <strong>mbfido uucp -quiet</strong>.
|
||||
<P> <P>
|
||||
|
||||
<h3>Options.</h3>
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -nocrc</code>
|
||||
Disable CRC checking of incoming TIC files. Only use this if you know what
|
||||
you are doing.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> scan -full</code>
|
||||
Force scanning of all message bases for new entered mail. You need this if
|
||||
mail in entered with other editors then from mbse. Also, running it once a
|
||||
day is adviced to catch any missed messages.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> news -learn</code>
|
||||
Scan the newsserver for news articles, and update the news dupes database only.
|
||||
Use this switch if you start using mbfido to gate news articles for the first time.
|
||||
Articles will not be gated with this switch, mbfido will just learn which articles
|
||||
already exist. Normally you only need to use this switch once.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -nodupe</code>
|
||||
Disable checking for duplicate's. Normally you should not use this switch.
|
||||
This switch doesn't work with the news command, only for echomail and tic files.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -quiet</code>
|
||||
Quiet mode, all output to the current tty is supressed. Use this flag if
|
||||
you toss mail from a script (started by cron) after mail is received.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> toss -a</code> Toss mail and allow to autocreate
|
||||
new message areas. See the <A HREF="../setup/emareas.html"> message area setup</A>
|
||||
how to set this up.
|
||||
<code><strong>mbfido</strong> toss -unsecure</code>
|
||||
Toss mail without checking if the echomail is for your own system en without
|
||||
checking if the sending node is connected to your system. Nodes who are
|
||||
excluded from a certain echo, can stil not enter messages in that echo.
|
||||
<P>
|
||||
<code><strong>mbfido</strong> [command] -unprotect</code>
|
||||
Toss from the unprotected inbound directory. The default is to toss from the
|
||||
protected inbound directory.
|
||||
<P> <P>
|
||||
|
||||
<h3>Environment.</H3>
|
||||
<P>
|
||||
In order to run the bbs you need to set one global environment variable
|
||||
<strong>$MBSE_ROOT</strong>
|
||||
This variable must point to the root of the bbs directoy structure.
|
||||
<P> <P>
|
||||
|
||||
<h3>Bugs.</H3>
|
||||
<P>
|
||||
There are still bugs, this program is under development.
|
||||
<P>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0">Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0">Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" "content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
<TITLE>MBSE BBS Programs - mbmail - Mail User Agent for the email gate.</TITLE>
|
||||
<LINK rel=stylesheet HREF="../manual.css">
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 10-Apr-2001</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbmail - Mail User Agent for the email gate.</H1>
|
||||
<P>
|
||||
|
||||
<H3>Synopsys.</H3>
|
||||
<code><strong>mbmail</strong> -r<addr> -g<grade> -c<charset> -b <recip></code>
|
||||
<P> <P>
|
||||
|
||||
<H3>Description.</H3>
|
||||
<P>
|
||||
<strong>mbmail</strong>
|
||||
is the Mail User Agent that should be called by your Internet mailer to deliver
|
||||
mail to Fidonet systems. This program must always run as user <strong>mbse</strong> so
|
||||
your mailer must be capable of doing so. The Postfix mailer I use can do that.
|
||||
<P>
|
||||
|
||||
<H3>Commandline options.</H3>
|
||||
<P>
|
||||
<code><strong>mbfile</strong> -r<addr> -g<grade> -c<charset> -b <recip></code>
|
||||
The -r<addr> is the address to route the packet to. This should normal be set by
|
||||
the Internet mailer to one of your aka's. The -g<grade> is the packet flavor. This
|
||||
can be one of the characters n, c or h which means normal, crash or hold. The -c<charset> will
|
||||
force a certain characterset. Normally this will be automatic set. The -b switch disables splitting
|
||||
of long messages. The <recip> are one or more recipients for the message. The message itself is
|
||||
read from stdin.
|
||||
<P>
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0" width="40" height="30"> Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0" width="33" height="35"> Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
@@ -11,7 +12,7 @@
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 07-Jan-2002</h5>
|
||||
<h5>Last update 21-Jan-2002</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbpasswd - The password wrapper.</H1>
|
||||
@@ -34,7 +35,7 @@ bbs when an existing user changes his password. If you as sysop use
|
||||
His password under Unix is then always the same as his password in the bbs program.
|
||||
This is necessary for the user to be able to get his email using the pop3 protocol.<P>
|
||||
You never need to run <strong>mbpasswd</strong> by hand, in fact it is protected so that only
|
||||
members of group <b>bbs</b> are allowed to use it. User <b>mbse</b> can use thsi
|
||||
members of group <b>bbs</b> are allowed to use it. User <b>mbse</b> can use this
|
||||
program and if you do, the password for a user are not in sync anymore.
|
||||
<P> <P>
|
||||
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||
<META http-equiv="Content-Style-Type" content="text/css">
|
||||
<META name="author" lang="en" "content=Michiel Broek">
|
||||
<META name="author" lang="en" content="Michiel Broek">
|
||||
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||||
<META name="description" lang="en" content="MBSE BBS Manual">
|
||||
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||||
@@ -11,7 +12,7 @@
|
||||
</HEAD>
|
||||
<BODY>
|
||||
<BLOCKQUOTE>
|
||||
<h5>Last update 09-Nov-2001</h5>
|
||||
<h5>Last update 21-Jan-2002</h5>
|
||||
<P> <P>
|
||||
|
||||
<H1>mbsebbs - The main BBS program</H1>
|
||||
@@ -43,18 +44,8 @@ If this tty is not available or is not in your setup, the user is kicked
|
||||
out. If he is allowed to login, a message is shown at which port he is on,
|
||||
unless you have turned this feature off in the setup.
|
||||
<P>
|
||||
If a user logs in the first check is if he/she has a Unix account or not.
|
||||
Unix users bypass the login prompt. Other users will get the normal prompt
|
||||
the same way DOS based bbs programs do. At that time it is checked if the
|
||||
user has IEMSI capabilities, if that is true, IEMSI login will be tried.
|
||||
If the user is not known, the newuser procedure begins.
|
||||
<P>
|
||||
If the user login is successfull, his favourite language will be loaded.
|
||||
Then it is checked if the user is the Sysop, if so, the Sysop flag is set.
|
||||
If the user has a blank password, he is asked to create a new password.
|
||||
Next it is checked if the user has an Unix account, if not he is forced to
|
||||
create a Unix account. This situation can exist after switching to MBSE BBS
|
||||
and you have converted your old userbase to the userbase for MBSE BBS.
|
||||
If the users Date of Birth is invalid, he is forced to enter the right
|
||||
Date of Birth.
|
||||
The next check is to see if the user has passed the expiry date, this is a
|
||||
@@ -139,19 +130,13 @@ will be made with the connect speed.
|
||||
If the environment variable <strong>CALLER_ID</strong> is present, a log entry
|
||||
will be made with the caller id.
|
||||
<P>
|
||||
If the environment variable <strong>LOGNAME</strong> is present and it is not
|
||||
<strong>bbs</strong> then it is assumed that it is a Unixmode login of the
|
||||
user who's Unixname is in the <strong>LOGNAME</strong> environment variable.
|
||||
This variable is set by the /bin/login program, so users that telnet to your
|
||||
bbs or login via <strong>mgetty</strong> and login with their Unixname will
|
||||
set this. If the <strong>LOGNAME</strong> is <strong>bbs</strong> then the
|
||||
user is prompted to enter his Fidonet style name. By the way, you can change
|
||||
that default <b>bbs</b> username with <b>mbsetup</b>.
|
||||
The environment variable <strong>LOGNAME</strong> must contain the unix
|
||||
username. This is set by the <b>mblogin</b> program.
|
||||
<P> <P>
|
||||
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0" width="40" height="30"> Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0" width="33" height="35"> Back to Main index</A>
|
||||
<A HREF="index.htm"><IMG SRC="../images/larrow.gif" ALT="Index" Border="0">Back to index</A>
|
||||
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0">Back to Main index</A>
|
||||
</BLOCKQUOTE>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
Reference in New Issue
Block a user