2001-08-17 05:46:24 +00:00
|
|
|
<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>
|
2001-08-25 19:53:11 +00:00
|
|
|
If the file /opt/mbse/etc/aliases exists, mbfido will try to fetch ftn-style
|
2001-08-17 05:46:24 +00:00
|
|
|
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
|
2001-08-25 19:53:11 +00:00
|
|
|
already exist. Normally you only need to use this switch once.
|
2001-08-17 05:46:24 +00:00
|
|
|
<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>
|
|
|
|
|
|
