This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
deb-mbse/html/programs/mbfido.html
2002-05-01 19:02:07 +00:00

280 lines
13 KiB
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 01-May-2002</h5>
<P>&nbsp;<P>
<H1>mbfido, the fidonet mail and files processor.</H1>
<P>
<h3>Synopsis.</H3>
<P>
<code>mbfido [command(s)] &lt;options&gt;</code>
<P>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<P>
<H3>Commands.</H3>
<P>
<code><strong>mbfido</strong> areas</code>
This command will check all file and mail groups if areas files are defined and
if the setting <b>Auto change</b> is set to Yes. Then the areafile is read and
the areas in that file are compared with the defined areas. Missing areas are
created and areas not in the areafile are removed or blocked depending if there
are files or messages present in these areas. This is also a good command to
create large bulks of new areas on your system.
<P>
<code><strong>mbfido</strong> mail &lt;recipient&gt;</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> &lt;recipient&gt;</code>
This is the same as above.
<P>
<code><strong>mbfido</strong> notify &lt;nodes&gt;</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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Main" Border="0">Back to Main index</A>
</BLOCKQUOTE>
</BODY>
</HTML>