bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial revision

Browse Source
This commit is contained in:
Ken Bowley 2001-08-17 05:46:24 +00:00
commit 40420d900a
750 changed files with 177485 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
AUTHORS Normal file
View File

@ -0,0 +1,31 @@
MBSE BBS AUTHORS.
All following people have contributed to the MBSE BBS project. I'm sure that
people are missing from this list. The list is not in any special order.
Michiel Broek mbse@users.sourceforge.net 2:280/2802
Joaquim Homrighausen joho@abs.lu
Andrew Milner andrew@fido.lu
Mats Wallin mw@fido.lu
Eugene G. Crosser crosser@average.org
Stanislav Voronyi stas@uanet.kharkov.ua
T. Tanaka
Martin Junius
Omen Technology Inc
Arjen G. Lentz
Cristof Meerwald
P. Saratxaga
Dima Maloff
Jan van de Werken
Sean Rima
Juergen Heisel
Jim Hansen
Ken Bowley
Redy Rodriguez 2:283/613.6
Johannes Lundberg 2:206/149@fidonet, <jojo@chaosdev.org>
Vincent Danen
Francois Thunus francois@telematique.org
Johan Lindh
William McBrine
Harald Wuensch
NERvOus nervous@nervous.it

339
COPYING Normal file
View File

@ -0,0 +1,339 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

100
CRON.sh Normal file
View File

@ -0,0 +1,100 @@
#!/bin/sh
#
# Crontab setup script for MBSE BBS
#
# (C) Michiel Broek, v0.06 06-Mar-2001
echo "MBSE BBS for Linux crontab setup. Checking your system..."
# Basic checks.
if [ `whoami` != "mbse" ]; then
cat << EOF
*** Run $0 as "mbse" user only! ***
Because the crontab for mbse must be changed, you must be mbse.
*** SETUP aborted ***
EOF
exit 2
fi
if [ "$MBSE_ROOT" = "" ]; then
echo "*** The MBSE_ROOT variable doesn't exist ***"
echo "*** SETUP aborted ***"
exit 2
fi
if [ "`grep mbse: /etc/passwd`" = "" ]; then
echo "*** User 'mbse' does not exist on this system ***"
echo "*** SETUP aborted ***"
exit 2
fi
if [ "`crontab -l`" != "" ]; then
echo "*** User 'mbse' already has a crontab ***"
echo "*** SETUP aborted ***"
exit 2
fi
MHOME=$MBSE_ROOT
clear
cat << EOF
Everything looks allright to install the default crontab now.
If you didn't install all bbs programs yet, you better hit
Control-C now and run this script when everything is installed.
If you insist on installing the crontab without the bbs is complete
you might get a lot of mail from cron complaining about errors.
The default crontab will have entries for regular maintenance.
You need to add entries to start and stop polling fidonet uplinks.
There is a example at the bottom of the crontab which is commented
out of course.
IMPORTANT: the first crontab entry is to set the Zone Mail Hour.
This entry is set for Holland, Amsterdam. ZMH is 02:30 - 03:30 UTC
for zone 2. CET is one hour plus in wintertime and two hours plus
in summertime. If you run "mbstat check" at each possible begin
and end of ZMH you must run it at 03:30, 04:30 and 05:30 local CET.
You must calculate and set the times for your own timezone and own
Fidonet Zone Mail Hour.
On most systems you can edit the crontab by typing "crontab -e".
Hit Return to continue or Control-C to abort.
EOF
read junk
echo "Installing MBSE BBS crontab..."
crontab - << EOF
#-------------------------------------------------------------------------
#
# Crontab for mbse bbs.
#
#-------------------------------------------------------------------------
# User maintenance etc. Just do it sometime when it's quiet.
00 09 * * * $MHOME/etc/maint
# Midnight event at 00:00.
00 00 * * * $MHOME/etc/midnight
# Weekly event at Sunday 00:05.
05 00 * * 0 $MHOME/etc/weekly
# Monthly event at the 1st day of the month at 00:10.
10 00 1 * * $MHOME/etc/monthly
#-----------------------------------------------------------------------------
#
# From here you should enter your outgoing mailslots, when to send mail etc.
# Mail slot example.
#00 02 * * * export MBSE_ROOT=$MHOME; \$MBSE_ROOT/bin/mbout poll f16.n2801.z2 -quiet
#00 03 * * * export MBSE_ROOT=$MHOME; \$MBSE_ROOT/bin/mbout stop f16.n2801.z2 -quiet
EOF
echo "Done."

4062
ChangeLog Normal file
View File

File diff suppressed because it is too large Load Diff

31
DEBUG Normal file
View File

@ -0,0 +1,31 @@
Debugging with MBSE BBS.
From version 0.33.15 I changed the way debug logging goes. There are no more
#ifdef .. #endif directives in the code that change the loging behaviour.
Lines that could be logged in the code for debug are now written in two
possible ways:
Syslog('b', "This is always logged for debug");
Syslog('B', "This is logged if most_debug flag is true");
The difference is the uppercase or lowercase logclass. Uppercase is only logged
if the global flag most_debug is set to true. If you want to use it in one of
the sources declare that flag like this:
extern int most_debug;
Then, from the moment you need the extra debugging, insert
most_debug = TRUE;
in the code, and set it to FALSE when you are done.
I did this because the extra debug is good for developers but not for regualar
users that need some extra logging. The log output with the most_debug flag
set to TRUE can be huge and does affect system performance.
For those who are developing code for MBSE BBS, use two kinds on debug logging.
Michiel Broek.

23
FILE_ID.DIZ.in Normal file
View File

@ -0,0 +1,23 @@
-= MBSE BBS System v@VERSION@ for Linux =-
MBSE BBS is a full Fidonet capable ANSI bbs
package including a mailer (ifcico clone),
tosser, ticfile processor, filefind and other
utilities.
The bbs supports full configurable ANSI
menus, multiple languages, IEMSI, standard
file transfer protocols, native Linux doors
and BlueWave and QWK offline readers.
The mailer supports FTS-0001, YooHoo/2U2,
EMSI protocols over modem, TCP/IP IFC and
Binkd protocol. Zedzap, Zmodem, Telink and
Hydra file transfer protocols. Full FTN mail
support, including automatic routing for hub
and host systems.
Internal mail format is JAM (c) messagebase.
Full tic file support, including extended
tic files. Costsharing will be added later.
Originating sites 2:280/2802@fidonet and
http://mbse.sourceforge.net/
Copyright by Michiel Broek.
Released under the terms of the GNU Public
License.

251
INSTALL Normal file
View File

@ -0,0 +1,251 @@
New installation procedure.
---------------------------
The old initial system setup was a little tricky and didn't work on some
systems. This procedure is tested on Slackware, RedHat, Mandrake, SuSE and Debian.
I have not tested on other distributions. Installation is now done by a
script which will do the dirty work. This script can be executed once only,
unless you undo all changes the script has done. Basicly, if you already
have installed MBSE BBS, or there are parts left of an old installation, the
script will abort and inform you why. I hope this will give a better and more
universal setup on most distributions.
Installing MBSE BBS for the first time.
---------------------------------------
Login as root and type the following commands to do the basic install:
cd /tmp
tar xfvz /pathtopackage/mbsebbs-0.33.17.tar.gz
cd mbsebbs-0.33.17
sh ./SETUP.sh
This will setup a new directory structure /opt/mbse and create's some
necessary users. If this in successfull, logout and login as user "mbse".
To build and install mbse bbs type the following commands:
cd
tar xfvz /pathtopackage/mbsebbs-0.33.17.tar.gz
cd mbsebbs-0.33.17
./configure
make
su
[type rootpassword]
make install
exit
/opt/mbse/bin/mbtask
The next step is to read the documentation in /opt/mbse/html with a browser.
After your system is configured and tested type "sh ./CRON.sh" to install
a default crontab for the bbs.
Upgrading MBSE BBS on a running system.
---------------------------------------
Login as user "mbse", backup your bbs configuration, and then type the
following commands:
cd
tar xfvz /pathtopackage/mbsebbs-0.33.17.tar.gz
cd mbsebbs-0.33.17
./configure
make
su
[type rootpassword]
make install
exit
Read the ChangeLog file for update instructions from the version
you were running and the version you have just installed over the old
version. Perform the upgrades step by step, version by version.
Next the instructions for the standard GNU installation programs:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that
the `configure' script does not know about. You can give `configure'
initial values for variables by setting them in the environment. Using
a Bourne-compatible shell, you can do that on the command line like
this:
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Or on systems that have the `env' program, you can do it like this:
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory. After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
architecture.
Installation Names
==================
By default, `make install' will install the package's files in
`/opt/mbse/bin', `/opt/mbse/etc', etc. You can specify an
installation prefix other than `/opt/mbse' by giving `configure' the
option `--prefix=PATH'. This is NOT ADVISED for MBSE BBS!!!
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like `--bindir=PATH' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
=================
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
==========================
There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on. Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
CPU-COMPANY-SYSTEM
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.
If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.
Sharing Defaults
================
If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Operation Controls
==================
`configure' recognizes the following options to control how it
operates.
`--cache-file=FILE'
Use and save the results of the tests in FILE instead of
`./config.cache'. Set FILE to `/dev/null' to disable caching, for
debugging `configure'.
`--help'
Print a summary of the options to `configure', and exit.
`--quiet'
`--silent'
`-q'
Do not print messages saying which checks are being made. To
suppress all normal output, redirect it to `/dev/null' (any error
messages will still be shown).
`--srcdir=DIR'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`--version'
Print the version of Autoconf used to generate the `configure'
script, and exit.
`configure' also accepts some other, not widely useful, options.

251
INSTALL.in Normal file
View File

@ -0,0 +1,251 @@
New installation procedure.
---------------------------
The old initial system setup was a little tricky and didn't work on some
systems. This procedure is tested on Slackware, RedHat, Mandrake, SuSE and Debian.
I have not tested on other distributions. Installation is now done by a
script which will do the dirty work. This script can be executed once only,
unless you undo all changes the script has done. Basicly, if you already
have installed MBSE BBS, or there are parts left of an old installation, the
script will abort and inform you why. I hope this will give a better and more
universal setup on most distributions.
Installing MBSE BBS for the first time.
---------------------------------------
Login as root and type the following commands to do the basic install:
cd /tmp
tar xfvz /pathtopackage/@PACKAGE@-@VERSION@.tar.gz
cd @PACKAGE@-@VERSION@
sh ./SETUP.sh
This will setup a new directory structure /opt/mbse and create's some
necessary users. If this in successfull, logout and login as user "mbse".
To build and install mbse bbs type the following commands:
cd
tar xfvz /pathtopackage/@PACKAGE@-@VERSION@.tar.gz
cd @PACKAGE@-@VERSION@
./configure
make
su
[type rootpassword]
make install
exit
/opt/mbse/bin/mbtask
The next step is to read the documentation in /opt/mbse/html with a browser.
After your system is configured and tested type "sh ./CRON.sh" to install
a default crontab for the bbs.
Upgrading MBSE BBS on a running system.
---------------------------------------
Login as user "mbse", backup your bbs configuration, and then type the
following commands:
cd
tar xfvz /pathtopackage/@PACKAGE@-@VERSION@.tar.gz
cd @PACKAGE@-@VERSION@
./configure
make
su
[type rootpassword]
make install
exit
Read the ChangeLog file for update instructions from the version
you were running and the version you have just installed over the old
version. Perform the upgrades step by step, version by version.
Next the instructions for the standard GNU installation programs:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
Compilers and Options
=====================
Some systems require unusual options for compilation or linking that
the `configure' script does not know about. You can give `configure'
initial values for variables by setting them in the environment. Using
a Bourne-compatible shell, you can do that on the command line like
this:
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Or on systems that have the `env' program, you can do it like this:
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
Compiling For Multiple Architectures
====================================
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'. `cd' to the
directory where you want the object files and executables to go and run
the `configure' script. `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory. After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
architecture.
Installation Names
==================
By default, `make install' will install the package's files in
`/opt/mbse/bin', `/opt/mbse/etc', etc. You can specify an
installation prefix other than `/opt/mbse' by giving `configure' the
option `--prefix=PATH'. This is NOT ADVISED for MBSE BBS!!!
You can specify separate installation prefixes for
architecture-specific files and architecture-independent files. If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.
In addition, if you use an unusual directory layout you can give
options like `--bindir=PATH' to specify different values for particular
kinds of files. Run `configure --help' for a list of the directories
you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
Optional Features
=================
Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System). The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.
For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.
Specifying the System Type
==========================
There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on. Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option. TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
CPU-COMPANY-SYSTEM
See the file `config.sub' for the possible values of each field. If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.
If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.
Sharing Defaults
================
If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists. Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.
Operation Controls
==================
`configure' recognizes the following options to control how it
operates.
`--cache-file=FILE'
Use and save the results of the tests in FILE instead of
`./config.cache'. Set FILE to `/dev/null' to disable caching, for
debugging `configure'.
`--help'
Print a summary of the options to `configure', and exit.
`--quiet'
`--silent'
`-q'
Do not print messages saying which checks are being made. To
suppress all normal output, redirect it to `/dev/null' (any error
messages will still be shown).
`--srcdir=DIR'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`--version'
Print the version of Autoconf used to generate the `configure'
script, and exit.
`configure' also accepts some other, not widely useful, options.

30
Makefile.am Normal file
View File

@ -0,0 +1,30 @@
## Process this file with automake to produce Makefile.in
AUTOMAKE_OPTIONS = foreign dist-zip no-installinfo no-installman
EXTRA_DIST = COPYING DEBUG CRON.sh FILE_ID.DIZ.in README \
README.GoldED SETUP.sh TODO UPGRADE files.css checkbasic
SUBDIRS = @SUBDIRS@
install-exec-local:
@./checkbasic
@if [ "$(shell whoami)" != "root" ] ; then \
echo; echo " Must be root to install!"; echo; exit 3; \
fi
$(mkinstalldirs) $(prefix)/{bin,etc,etc/maptabs,doc,fdb,home,log,magic,sema,var,tmp}
$(mkinstalldirs) $(prefix)/{dutch,dutch/txtfiles,dutch/menus,dutch/macro}
$(mkinstalldirs) $(prefix)/{english,english/txtfiles,english/menus,english/macro}
$(mkinstalldirs) $(prefix)/{italian,italian/txtfiles,italian/menus,italian/macro}
$(mkinstalldirs) $(prefix)/{spanish,spanish/txtfiles,spanish/menus,spanish/macro}
chown @OWNER@.@GROUP@ $(prefix)/{bin,etc,etc/maptabs,doc,fdb,home,log,magic,sema,var,tmp}
chown @OWNER@.@GROUP@ $(prefix)/{dutch,dutch/txtfiles,dutch/menus,dutch/macro}
chown @OWNER@.@GROUP@ $(prefix)/{english,english/txtfiles,english/menus,english/macro}
chown @OWNER@.@GROUP@ $(prefix)/{italian,italian/txtfiles,italian/menus,italian/macro}
chown @OWNER@.@GROUP@ $(prefix)/{spanish,spanish/txtfiles,spanish/menus,spanish/macro}
chmod 777 $(prefix)/{sema,tmp}
$(mkinstalldirs) /var/spool/mbse
$(mkinstalldirs) /var/spool/mbse/{nodelist,unknown,inbound,outbound,badtic,ticqueue,ftp,mail}
chown -R @OWNER@.@GROUP@ /var/spool/mbse
chmod -R 755 /var/spool/mbse

395
Makefile.in Normal file
View File

@ -0,0 +1,395 @@
# Makefile.in generated automatically by automake 1.4 from Makefile.am
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = .
ACLOCAL = @ACLOCAL@
AUTOCONF = @AUTOCONF@
AUTOMAKE = @AUTOMAKE@
AUTOHEADER = @AUTOHEADER@
INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
transform = @program_transform_name@
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
AWK = @AWK@
CC = @CC@
COMPRESS = @COMPRESS@
GROUP = @GROUP@
GZIP = @GZIP@
LEX = @LEX@
LOG_COMPRESS = @LOG_COMPRESS@
LOG_COMPRESSEXT = @LOG_COMPRESSEXT@
MAKEINFO = @MAKEINFO@
OWNER = @OWNER@
PACKAGE = @PACKAGE@
RANLIB = @RANLIB@
VERSION = @VERSION@
YACC = @YACC@
AUTOMAKE_OPTIONS = foreign dist-zip no-installinfo no-installman
EXTRA_DIST = COPYING DEBUG CRON.sh FILE_ID.DIZ.in README README.GoldED SETUP.sh TODO UPGRADE files.css checkbasic
SUBDIRS = @SUBDIRS@
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES = INSTALL FILE_ID.DIZ
DIST_COMMON = README ./stamp-h.in AUTHORS COPYING ChangeLog \
FILE_ID.DIZ.in INSTALL INSTALL.in Makefile.am Makefile.in NEWS TODO \
acconfig.h acinclude.m4 aclocal.m4 config.guess config.h.in configure \
configure.in install-sh missing mkinstalldirs
DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --foreign --include-deps Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) \
&& CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status
$(ACLOCAL_M4): configure.in acinclude.m4
cd $(srcdir) && $(ACLOCAL)
config.status: $(srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
$(SHELL) ./config.status --recheck
$(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
cd $(srcdir) && $(AUTOCONF)
config.h: stamp-h
@if test ! -f $@; then \
rm -f stamp-h; \
$(MAKE) stamp-h; \
else :; fi
stamp-h: $(srcdir)/config.h.in $(top_builddir)/config.status
cd $(top_builddir) \
&& CONFIG_FILES= CONFIG_HEADERS=config.h \
$(SHELL) ./config.status
@echo timestamp > stamp-h 2> /dev/null
$(srcdir)/config.h.in: $(srcdir)/stamp-h.in
@if test ! -f $@; then \
rm -f $(srcdir)/stamp-h.in; \
$(MAKE) $(srcdir)/stamp-h.in; \
else :; fi
$(srcdir)/stamp-h.in: $(top_srcdir)/configure.in $(ACLOCAL_M4) acconfig.h
cd $(top_srcdir) && $(AUTOHEADER)
@echo timestamp > $(srcdir)/stamp-h.in 2> /dev/null
mostlyclean-hdr:
clean-hdr:
distclean-hdr:
-rm -f config.h
maintainer-clean-hdr:
INSTALL: $(top_builddir)/config.status INSTALL.in
cd $(top_builddir) && CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status
FILE_ID.DIZ: $(top_builddir)/config.status FILE_ID.DIZ.in
cd $(top_builddir) && CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
@SET_MAKE@
all-recursive install-data-recursive install-exec-recursive \
installdirs-recursive install-recursive uninstall-recursive install-info-recursive \
check-recursive installcheck-recursive info-recursive dvi-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
mostlyclean-recursive clean-recursive distclean-recursive \
maintainer-clean-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
rev=''; list='$(SUBDIRS)'; for subdir in $$list; do \
rev="$$subdir $$rev"; \
test "$$subdir" = "." && dot_seen=yes; \
done; \
test "$$dot_seen" = "no" && rev=". $$rev"; \
target=`echo $@ | sed s/-recursive//`; \
for subdir in $$rev; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done && test -z "$$fail"
tags-recursive:
list='$(SUBDIRS)'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
done
tags: TAGS
ID: $(HEADERS) $(SOURCES) $(LISP)
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
here=`pwd` && cd $(srcdir) \
&& mkid -f$$here/ID $$unique $(LISP)
TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test -f $$subdir/TAGS && tags="$$tags -i $$here/$$subdir/TAGS"; \
fi; \
done; \
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(ETAGS_ARGS)config.h.in$$unique$(LISP)$$tags" \
|| (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags config.h.in $$unique $(LISP) -o $$here/TAGS)
mostlyclean-tags:
clean-tags:
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
# This target untars the dist file and tries a VPATH configuration. Then
# it guarantees that the distribution is self-contained by making another
# tarfile.
distcheck: dist
-rm -rf $(distdir)
GZIP=$(GZIP_ENV) $(TAR) zxf $(distdir).tar.gz
mkdir $(distdir)/=build
mkdir $(distdir)/=inst
dc_install_base=`cd $(distdir)/=inst && pwd`; \
cd $(distdir)/=build \
&& ../configure --srcdir=.. --prefix=$$dc_install_base \
&& $(MAKE) $(AM_MAKEFLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) dvi \
&& $(MAKE) $(AM_MAKEFLAGS) check \
&& $(MAKE) $(AM_MAKEFLAGS) install \
&& $(MAKE) $(AM_MAKEFLAGS) installcheck \
&& $(MAKE) $(AM_MAKEFLAGS) dist
-rm -rf $(distdir)
@banner="$(distdir).tar.gz is ready for distribution"; \
dashes=`echo "$$banner" | sed s/./=/g`; \
echo "$$dashes"; \
echo "$$banner"; \
echo "$$dashes"
dist: distdir
-chmod -R a+r $(distdir)
GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
-rm -rf $(distdir)
dist-zip: distdir
-chmod -R a+r $(distdir)
zip -rq $(distdir).zip $(distdir)
-rm -rf $(distdir)
dist-all: distdir
-chmod -R a+r $(distdir)
GZIP=$(GZIP_ENV) $(TAR) chozf $(distdir).tar.gz $(distdir)
zip -rq $(distdir).zip $(distdir)
-rm -rf $(distdir)
distdir: $(DISTFILES)
-rm -rf $(distdir)
mkdir $(distdir)
-chmod 777 $(distdir)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pr $$/$$file $(distdir)/$$file; \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
for subdir in $(SUBDIRS); do \
if test "$$subdir" = .; then :; else \
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
chmod 777 $(distdir)/$$subdir; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$(distdir) distdir=../$(distdir)/$$subdir distdir) \
|| exit 1; \
fi; \
done
info-am:
info: info-recursive
dvi-am:
dvi: dvi-recursive
check-am: all-am
check: check-recursive
installcheck-am:
installcheck: installcheck-recursive
install-info-am:
install-info: install-info-recursive
all-recursive-am: config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
install-exec-am: install-exec-local
install-exec: install-exec-recursive
install-data-am:
install-data: install-data-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-recursive
uninstall-am:
uninstall: uninstall-recursive
all-am: Makefile config.h
all-redirect: all-recursive-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs: installdirs-recursive
installdirs-am:
mostlyclean-generic:
clean-generic:
distclean-generic:
-rm -f Makefile $(CONFIG_CLEAN_FILES)
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
mostlyclean-am: mostlyclean-hdr mostlyclean-tags mostlyclean-generic
mostlyclean: mostlyclean-recursive
clean-am: clean-hdr clean-tags clean-generic mostlyclean-am
clean: clean-recursive
distclean-am: distclean-hdr distclean-tags distclean-generic clean-am
distclean: distclean-recursive
-rm -f config.status
maintainer-clean-am: maintainer-clean-hdr maintainer-clean-tags \
maintainer-clean-generic distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
maintainer-clean: maintainer-clean-recursive
-rm -f config.status
.PHONY: mostlyclean-hdr distclean-hdr clean-hdr maintainer-clean-hdr \
install-data-recursive uninstall-data-recursive install-exec-recursive \
uninstall-exec-recursive installdirs-recursive uninstalldirs-recursive \
all-recursive check-recursive installcheck-recursive info-recursive \
dvi-recursive mostlyclean-recursive distclean-recursive clean-recursive \
maintainer-clean-recursive tags tags-recursive mostlyclean-tags \
distclean-tags clean-tags maintainer-clean-tags distdir info-am info \
dvi-am dvi check check-am installcheck-am installcheck install-info-am \
install-info all-recursive-am install-exec-local install-exec-am \
install-exec install-data-am install-data install-am install \
uninstall-am uninstall all-redirect all-am all installdirs-am \
installdirs mostlyclean-generic distclean-generic clean-generic \
maintainer-clean-generic clean mostlyclean distclean maintainer-clean
install-exec-local:
@./checkbasic
@if [ "$(shell whoami)" != "root" ] ; then \
echo; echo " Must be root to install!"; echo; exit 3; \
fi
$(mkinstalldirs) $(prefix)/{bin,etc,etc/maptabs,doc,fdb,home,log,magic,sema,var,tmp}
$(mkinstalldirs) $(prefix)/{dutch,dutch/txtfiles,dutch/menus,dutch/macro}
$(mkinstalldirs) $(prefix)/{english,english/txtfiles,english/menus,english/macro}
$(mkinstalldirs) $(prefix)/{italian,italian/txtfiles,italian/menus,italian/macro}
$(mkinstalldirs) $(prefix)/{spanish,spanish/txtfiles,spanish/menus,spanish/macro}
chown @OWNER@.@GROUP@ $(prefix)/{bin,etc,etc/maptabs,doc,fdb,home,log,magic,sema,var,tmp}
chown @OWNER@.@GROUP@ $(prefix)/{dutch,dutch/txtfiles,dutch/menus,dutch/macro}
chown @OWNER@.@GROUP@ $(prefix)/{english,english/txtfiles,english/menus,english/macro}
chown @OWNER@.@GROUP@ $(prefix)/{italian,italian/txtfiles,italian/menus,italian/macro}
chown @OWNER@.@GROUP@ $(prefix)/{spanish,spanish/txtfiles,spanish/menus,spanish/macro}
chmod 777 $(prefix)/{sema,tmp}
$(mkinstalldirs) /var/spool/mbse
$(mkinstalldirs) /var/spool/mbse/{nodelist,unknown,inbound,outbound,badtic,ticqueue,ftp,mail}
chown -R @OWNER@.@GROUP@ /var/spool/mbse
chmod -R 755 /var/spool/mbse
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

0
NEWS Normal file
View File

24
README Normal file
View File

@ -0,0 +1,24 @@
MBSE BBS Packages.
Distribution naming scheme:
mbd0_30a.tgz
^^^^ ^^^
||| ||
||| |+---- Alpha, Beta, Gamma or none for stable version.
||| +----- Minor version number (2 digits).
||+-------- Major version number.
|+--------- Package type, see next section.
+---------- Always mb (2 alpha characters).
Package types:
b - The complete MBSE BBS package, including mailer and utilities.
i - Internet <> Fidonet gateway software.
p - Pointlist processing software.
Note that for distribution via Fidonet Technology networks the naming scheme
is restricted to dos 8.3 conventions, while longer names would be nicer.

90
README.GoldED Normal file
View File

@ -0,0 +1,90 @@
README for GoldED users.
Since MBSE BBS version 0.33.12 GoldED and MBSE BBS can be used together
without problems as long as you use it to read the sysop mail. The
mbsetup program can export a file called /opt/mbse/etc/golded.inc which
will contain your main Aka's, Aka matching, sysop name and all your mail
areas. This file is only (re)created if you change the global settings or
one of the mail areas. The first time you must force this by making a change
somewhere.
Now create /opt/mbse/etc/golded.cfg, here is what I wrote:
; GoldED.cfg
;
; Internet Addressing
;
INTERNETADDRESS Michiel_Broek@f2802.n280.z2.fidonet.org
INTERNETGATE UUCP 2:292/875
;
;
OUTBOUNDPATH /SYS/usr/mail/out
REPLYLINK chain
STYLECODES yes
;
;
; MESSAGE READER
;
DISPMSGSIZE KBYTES
DISPATTACHSIZE KBYTES
DISPLOCALHIGH YES
DISPPAGEBAR YES
VIEWHIDDEN YES
VIEWKLUDGE NO
VIEWQUOTE YES
;
INCLUDE /opt/mbse/etc/golded.inc
;
; The end.
Put in /opt/mbse/.profile the following line:
export GOLDED=$HOME/etc
When you now start GoldED you use it as the sysop. Make sure that the sysop's
userrecord is the first user in the MBSE BBS userbase. If not, the lastread
pointers are not right.
Compile instructions for GoldED 3.0.1 written by Johannes Beekhuizen, 2:280/1018
* Unpack the sources in some directory (/tmp):
cd /tmp
tar -zxvf ???/ged_301.tgz
This will create a directory golded-3.0.1, so if you did this in /tmp then
there is now a directory called /tmp/golded-3.0.1 which will be called
<basedir> from now on.
* Set the environment variables GSRC, GOBJ and GLIB to basedir. In a bash
shell this is:
export GSRC=/tmp/golded-3.0.1
export GOBJ=/tmp/golded-3.0.1
export GLIB=/tmp/golded-3.0.1
* Build the program 'gbuild':
cd <basedir>/gbuild
make lnx
cp gbldnx /opt/mbse/bin
The location of gbldlnx is not important, as long as it is in your PATH.
* Create the directories needed for compilation and installation:
cd <basedir>/goldlib
make install
* Next build GoldED:
cd <basedir>/goldlib/gall
make lnx
cd <basedir>/goldlib/gcfg
make lnx
cd <basedir>/goldlib/gmb3
make lnx
cd <basedir>/golded3
cp mygolded.__h mygolded.h
Edit the file mygolded.h to suit your own taste.
make lnx
strip gedlnx
cp gedlnx /opt/mbse/bin
* Now build goldnode:
cd <basedir>/goldnode
make lnx
strip gnlnx
cp gnlnx /opt/mbse/bin
* Example configurations and documentation are in <basedir>/golded3/cfgs
and <basedir>/golded3/docs.

365
SETUP.sh Normal file
View File

@ -0,0 +1,365 @@
#!/bin/sh
#
# Basic setup script for MBSE BBS
#
# (C) Michiel Broek, v0.17 26-May-2001
#
# Customisation section, change the next variables to your need.
# However, all docs refer to the setup below.
#
# Basic bbs root directory.
clear
MHOME=/opt/mbse
PATH=/bin:/sbin:/usr/bin:/usr/sbin:
DISTNAME=
DISTVERS=
#------------------------------------------------------------------------
#
# Logging procedure, needs two parameters.
#
log() {
/bin/echo `date +%d-%b-%y\ %X ` $1 $2 >> SETUP.log
}
#------------------------------------------------------------------------
#
cat << EOF
MBSE BBS for Linux first time setup. Checking your system..."
If anything goes wrong with this script, look at the output of
the file SETUP.log that is created by this script in this
directory. If you can't get this script to run on your system,
mail this logfile to Michiel Broek at 2:280/2802 or email it
to mbroek@users.sourceforge.net
EOF
echo -n "Press ENTER to start the basic checks "
read junk
log "+" "MBSE BBS $0 started by `whoami`"
log "+" "Current directory is `pwd`"
#
# First do various tests to see which Linux distribution this is.
#
if [ -f /etc/slackware-version ]; then
# Slackware 7.0 and later
DISTNAME="Slackware"
DISTVERS=`cat /etc/slackware-version`
else
if [ -f /etc/debian_version ]; then
# Debian, at least since version 2.2
DISTNAME="Debian"
DISTVERS=`cat /etc/debian_version`
else
if [ -f /etc/SuSE-release ]; then
DISTNAME="SuSE"
DISTVERS=`cat /etc/SuSE-release | grep VERSION | awk '{ print $3 }'`
else
if [ -f /etc/redhat-release ]; then
DISTNAME="RedHat"
DISTVERS=`cat /etc/redhat-release | awk '{ print $5 }'`
else
if [ -f /etc/mandrake-release ]; then
DISTNAME="Mandrake"
# Format: Linux Mandrake release 8.0 (Cooker) for i586
DISTVERS=`cat /etc/mandrake-release | awk '{ print $4 }'`
else
if [ -f /etc/rc.d/rc.0 ] && [ -f /etc/rc.d/rc.local ]; then
# If Slackware wasn't detected yet it is version 4.0 or older.
DISTNAME="Slackware"
DISTVERS="Old"
else
DISTNAME="Unknown"
fi
fi
fi
fi
fi
fi
log "+" "Detected \"${DISTNAME}\" version \"${DISTVERS}\""
# Basic checks.
if [ `whoami` != "root" ]; then
cat << EOF
*** Run $0 as root only! ***
Because some of the system files must be changed, you must be root
to use this script.
*** SETUP aborted ***
EOF
log "!" "Aborted, not root"
exit 2
fi
if [ "$MBSE_ROOT" != "" ]; then
echo "*** The MBSE_ROOT variable exists: $MBSE_ROOT ***"
echo "*** SETUP aborted ***"
log "!" "Aborted, MBSE_ROOT variable exists: ${MBSE_ROOT}"
exit 2
fi
if [ "`grep mbse: /etc/passwd`" != "" ]; then
echo "*** User 'mbse' already exists on this system ***"
echo "*** SETUP aborted ***"
log "!" "Aborted, user 'mbse' already exists on this system"
exit 2
fi
if [ "`grep bbs: /etc/group`" != "" ]; then
echo "*** Group 'bbs' already exists on this system ***"
echo "*** SETUP aborted ***"
log "!" "Aborted, group 'bbs' already exists on this system"
exit 2
fi
if [ -f /etc/passwd.lock ]; then
echo "*** The password file is locked, make sure that nobody"
echo " is using any password utilities. ***"
echo "*** SETUP aborted ***"
log "!" "Aborted, password file is locked"
exit 2
fi
clear
if [ -d /opt ]; then
log "+" "Directory /opt already present"
else
mkdir /opt
echo "Directory /opt created."
log "+" "Directory /opt created"
fi
cat << EOF
Basic checks done.
The detected Linux distribution is $DISTNAME $DISTVERS
Everything looks allright to start the installation now.
Next the script will install a new group 'bbs' and two new
users, 'mbse' which is the bbs system account, and 'bbs' which
is the login account for bbs users. This account will have no
password! The shell for this account is the main bbs program.
One final important note: This script will make changes to some
of your system files. Because I don't have access to all kinds of
distributions and configurations there is no garantee that this
script is perfect. Please make sure you have a recent system backup.
Also make sure you have resque boot disks and know how to repair
your system. It might also be wise to login as root on another
virtual console incase something goes wrong with system login.
If you are not sure, or forgot something, hit Control-C now or
EOF
echo -n " press Enter to start the installation "
read junk
clear
#------------------------------------------------------------------------
#
# The real work starts here
#
log "+" "Starting installation"
echo "Installing MBSE BBS for the first time..."
echo ""
echo -n "Adding group 'bbs'"
groupadd bbs
log "+" "[$?] Added group bbs"
echo -n ", user 'mbse'"
useradd -c "MBSE BBS Admin" -d $MHOME -g bbs -G uucp -m -s /bin/bash mbse
log "+" "[$?] Added user mbse"
chmod 770 $MHOME
log "+" "[$?] chmod 770 $MHOME"
echo -n " writing '$MHOME/.profile'"
cat << EOF >$MHOME/.profile
# profile for mbse
#
export PATH=\$HOME/bin:\$PATH
export MBSE_ROOT=\$HOME
export GOLDED=\$HOME/etc
# For xterm on the Gnome desktop:
cd \$HOME
EOF
echo ""
log "+" "Created $MHOME/.profile"
# On some systems there is a .bashrc file in the users homedir.
# It must be removed.
if [ -f $MHOME/.bashrc ] || [ -f $MHOME/.bash_profile ]; then
echo "Removing '$MHOME/.bash*'"
rm -f $MHOME/.bash*
log "+" "Removed $MHOME/.bash* files"
fi
echo ""
echo "Now set the login password for user 'mbse'"
passwd mbse
log "+" "[$?] Password is set for user mbse"
echo -n "Adding user 'bbs'"
mkdir $MHOME/home
log "+" "[$?] Created directory $MHOME/home"
chown mbse.bbs $MHOME/home
log "+" "[$?] chown mbse.bbs $MHOME/home
chmod 775 $MHOME/home
log "+" "[$?] chmod 775 $MHOME/home
useradd -c "MBSE BBS Login" -d $MHOME/home/bbs -g bbs -s $MHOME/bin/mbsebbs bbs
log "+" "[$?] Added user bbs"
# Some systems (RedHat and Mandrake) insist on creating a users homedir.
# These are full of garbage we don't need. Kill it first.
if [ -d $MHOME/home/bbs ]; then
rm -Rf $MHOME/home/bbs
log "+" "[$?] Removed $MHOME/home/bbs"
fi
mkdir $MHOME/home/bbs
log "+" "[$?] mkdir $MHOME/home/bbs"
chmod 770 $MHOME/home/bbs
log "+" "[$?] chmod 770 $MHOME/home/bbs"
chown mbse.bbs $MHOME/home/bbs
log "+" "[$?] chown mbse.bbs $MHOME/home/bbs"
touch $MHOME/home/bbs/.hushlogin
log "+" "[$?] touch $MHOME/home/bbs/.hushlogin"
echo ", removing password:"
echo -n "$$" >/etc/passwd.lock
if [ -f /etc/shadow ]; then
log "+" "Shadow password system"
# Not all systems are the same...
if [ "`grep bbs:\!\!: /etc/shadow`" != "" ]; then
sed /bbs:\!\!:/s/bbs:\!\!:/bbs::/ /etc/shadow >/etc/shadow.bbs
else
sed /bbs:\!:/s/bbs:\!:/bbs::/ /etc/shadow >/etc/shadow.bbs
fi
log "+" "[$?] removed password from user bbs"
mv /etc/shadow /etc/shadow.mbse
log "+" "[$?] made backup of /etc/shadow"
mv /etc/shadow.bbs /etc/shadow
log "+" "[$?] moved new /etc/shadow in place"
if [ "$DISTNAME" = "Debian" ] || [ "$DISTNAME" = "SuSE" ]; then
# Debian and SuSE use other ownership of /etc/shadow
chmod 640 /etc/shadow
chgrp shadow /etc/shadow
log "+" "[$?] Debian/SuSE style owner of /etc/shadow (0640 root.shadow)"
else
chmod 600 /etc/shadow
log "+" "[$?] Default style owner of /etc/shadow (0600 root.root)"
fi
echo " File /etc/shadow.mbse is your backup of /etc/shadow"
else
log "+" "Not a shadow password system"
if [ "`grep bbs:\!\!: /etc/passwd`" != "" ]; then
sed /bbs:\!\!:/s/bbs:\!\!:/bbs::/ /etc/passwd >/etc/passwd.bbs
else
sed /bbs:\!:/s/bbs:\!:/bbs::/ /etc/passwd >/etc/passwd.bbs
fi
log "+" "[$?] Removed password of user bbs"
mv /etc/passwd /etc/passwd.mbse
log "+" "[$?] Made backup of /etc/passwd"
mv /etc/passwd.bbs /etc/passwd
log "+" "[$?] Moved new /etc/passwd in place"
chmod 644 /etc/passwd
log "+" "[$?] Changed owner of /etc/passwd"
echo " File /etc/passwd.mbse is your backup of /etc/passwd"
fi
rm /etc/passwd.lock
echo ""
if [ "`grep binkp /etc/services`" = "" ]; then
BINKD=TRUE
else
BINKD=FALSE
fi
if [ "`grep fido /etc/services`" = "" ]; then
FIDO=TRUE
else
FIDO=FALSE
fi
log "+" "Services: binkp=$BINKD fido=$FIDO"
if [ "$FIDO" = "TRUE" ] || [ "$BINKD" = "TRUE" ]; then
echo -n "Modifying /etc/services"
log "+" "Modifying /etc/services"
mv /etc/services /etc/services.mbse
cat /etc/services.mbse >/etc/services
echo "#" >>/etc/services
echo "# Unofficial for MBSE BBS" >>/etc/services
echo "#" >>/etc/services
if [ "$BINKD" = "TRUE" ]; then
echo -n ", binkp at port 24554"
echo "binkp 24554/tcp # mbcico IBN mode">>/etc/services
fi
if [ "$FIDO" = "TRUE" ]; then
echo -n ", fido at port 60179"
echo "tfido 60177/tcp # mbcico ITN mode">>/etc/services
echo "fido 60179/tcp # mbcico IFC mode">>/etc/services
fi
chmod 644 /etc/services
echo ", done."
fi
if [ "`grep mbcico /etc/inetd.conf`" = "" ]; then
echo -n "Modifying /etc/inetd.conf"
log "+" "Modifying /etc/inetd.conf"
mv /etc/inetd.conf /etc/inetd.conf.mbse
cat /etc/inetd.conf.mbse >/etc/inetd.conf
cat << EOF >>/etc/inetd.conf
#:MBSE-BBS: bbs service
binkp stream tcp nowait mbse $MHOME/bin/mbcico mbcico -t ibn
tfido stream tcp nowait mbse $MHOME/bin/mbcico mbcico -t itn
fido stream tcp nowait mbse $MHOME/bin/mbcico mbcico -t ifc
EOF
chmod 644 /etc/inetd.conf
if [ -f /var/run/inetd.pid ]; then
echo -n ", restarting inetd"
kill -HUP `cat /var/run/inetd.pid`
log "+" "[$?] restarted inetd"
else
log "!" "Warning: no inetd.pid file found"
fi
echo ", done."
fi
echo ""
echo -n "Press Enter to continue"
read junk
clear
cat << EOF
The script made it to the end, that looks good. Before you logout do some
sanity checks;
1. Can you still login as a normal user.
2. Login on another virtual console, network or whatever as user 'mbse'.
Then type 'echo \$MBSE_ROOT'. Does this show the path to
'$MHOME' or nothing.
3. Login on another virtual console as user 'bbs'. It should not ask for
a password, but should direct try to start the bbs. This is not
installed yet but you should see error messages and then be logged out.
If these three tests weren't successfull, restore /etc/passwd and
or /etc/shadow, the backup copies have the extension '.mbse'.
Then issue (as root of course) the following commands:
userdel bbs
userdel -r mbse
groupdel bbs
EOF

123
TODO Normal file
View File

@ -0,0 +1,123 @@
MBSE BBS V0.33.17 TODO list.
----------------------------
These are a list of things that must be implemented one way or
another. Some things are urgent and necessary to operate the bbs
without human intervention, others are just for comfort, or nice.
I think this list will always contain items, I only hope the urgent
matters will be removed.
Note that most goodies are still in my mind instead of in this file.
Classes: U = Urgent.
N = Normal, second priority.
L = Cosmetic or nice to have.
mbsebbs:
L: Reading of function keys over modem lines, or worse PPP connections,
must be fixed. Timing problems together with modem buffering?
It works with direct serial connections. Note, this also happens
on busy LAN's between Linux boxes with normal xterm's.
Note: this problem almost dissapeared after kernel upgrade to
2.2.16.
L: Must include SEEN-BY and other hidden lines into BlueWave and QWK
mail, must be user selectable. see remarks of William McBrine.
The default is oke now.
N: Rewrite chat to use "mbtask". Write chat functions into "mbmon"
N: Implement session and time/day limits.
N: Display textfiles and archives.
N: Check for tagged files before logoff
N: If a message doesn't end with a newline in the FS-editor, the last
line will dissapear when reading the message.
N: Can't post messages to users handle.
L: Implement telnet door.
N: Deleting a line in the FS editor with the BS key gives a SEGFAULT.
mbfido:
U: Code cleanup and make a structure in this program. Remove duplicate
or similar functions.
N: Remove memory leak during toss. (It's ok for less 5000 messages for
each run).
N: Make a workaround for the fileecho name in the filesdatabase.
N: Implement long filename support from .tic files.
N: When a news article is received from a mailinglist there is a valid
To: address in the message, the gate doesn't see that and uses the
name to "All".
mbcico:
L: Implement modem connect response translation for ISDN lines, i.e.
make the CAUSE responses human readable. see McMail for this
option.
N: Implement MD5 crypt in binkp protocol driver.
N: Remove code to make automatic calls after mbtask does this.
mbfile:
N: Add a check to see if the magic filenames are valid.
N: Adopt files with check for FILE_ID.DIZ
N: Export to files.bbs
N: Add <area> <file> <uploader> <description>
N: Update <filespec> <area> <-touch>
N: Rearc <area>
mbaff:
L: Add setup parameters for minimum length of keywords.
mbindex:
N: Add usernames index.
mbmon:
L: Logfile tail functions.
L: Chat with bbs users.
mbtask:
L: Add chat protocol.
N: Let mbtask control the mailer and mailer calls.
N: Implement nodelist Txx flags.
N: Add events.
mbsetup:
U: PickAka function lets mbsetup crash if domain is 12 characters
L: Generate crossreference document:
File Areas <=> BBS groups
File Areas <=> Newfiles groups
Filefind flags <=> TIC Areas
Echomail <=> Mail groups
Echomail <=> Nodes
Fileechos <=> Groups
Fileechos <=> Nodes
Fileechos <=> BBS Areas
Fileechos <=> Magic processing
Fileechos <=> Hatch
Newfiles <=> BBS Areas
Newfiles <=> File groups
Echomail groups <=> Nodes
Echomail groups <=> Areas
Fileecho groups <=> Nodes
Fileecho groups <=> File echos
Fileecho groups <=> Newfile reports
Fileecho groups <=> BBS Areas

18
UPGRADE Normal file
View File

@ -0,0 +1,18 @@
UPGRADE INSTRUCTIONS.
Read the file ChangeLog from the version you are currently running
until you reach the current version. With every version that needs
upgrade you will find the instructions there. Read them carefully
and perform all necessary steps.
Read the file ChangeLog from the version you are currently running
until you reach the current version. With every version that needs
upgrade you will find the instructions there. Read them carefully
and perform all necessary steps.
Yes, I wrote this twice, please do the same with the update
instructions.
Michiel.

72
acconfig.h Normal file
View File

@ -0,0 +1,72 @@
/* acconfig.h for the MBSE BBS package */
#define AUTHOR @COPYRIGHT@
/* Memory debugging */
#undef MEMWATCH
/* Has strcasestr function */
#undef HAVE_STRCASESTR
/* Has mkstemp function */
#undef HAVE_MKSTEMP
/* If you have gettimeofday function */
#undef HAVE_GETTIMEOFDAY
#undef HAVE_DECLARED_TIMEZONE
#undef HAVE_TM_GMTOFF
#undef HAVE_TM_ZONE
/* If you don't have pid_t */
#undef DONT_HAVE_PID_T
/* Believe ZFIN */
#undef BELEIVE_ZFIN
/* Add pid to mbmail */
#undef ADD_PID
/* FSC-0070 */
#undef FSC_0070
/* NOPROTO in lhash.h ??? */
#undef NOPROTO
/* No Hash Comp function */
#undef NO_HASH_COMP
/* News postings */
#undef RESTAMP_FUTURE_POSTINGS
#undef RESTAMP_OLD_POSTINGS
/* From mbftpd: */
#undef FNM_PATHNAME
#undef IP_TOS
#undef M_UNIX
#undef NBBY
#undef REGEX
#undef REGEXEC
#undef SHADOW_PASSWORD
#undef SO_OOBINLINE
/* mbuseradd */
#undef AGING
#undef ATT_AGE
#undef ATT_COMMENTS
#undef AUTH_METHODS
#undef CKDEFS
#undef DOUBLESIZE
#undef HAVE_A64L
#undef HAVE_FCHMOD
#undef HAVE_FCHOWN
#undef HAVE_FSYNC
#undef HAVE_LCKPWDF
#undef HAVE_LIBCRACK
#undef HAVE_LIBCRACK_HIST
#undef KEEP_NIS_AT_END
#undef MD5_CRYPT
#undef PAM
#undef SW_CRYPT
/* That's it */

136
acinclude.m4 Normal file
View File

@ -0,0 +1,136 @@
dnl aclocal.m4 generated automatically by aclocal 1.4
dnl Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
dnl PARTICULAR PURPOSE.
# Do all the work for Automake. This macro actually does too much --
# some checks are only needed if your package does certain things.
# But this isn't really a big deal.
# serial 1
dnl Usage:
dnl AM_INIT_AUTOMAKE(package,version, [no-define])
AC_DEFUN(AM_INIT_AUTOMAKE,
[AC_REQUIRE([AC_PROG_INSTALL])
PACKAGE=[$1]
AC_SUBST(PACKAGE)
VERSION=[$2]
AC_SUBST(VERSION)
dnl test to see if srcdir already configured
if test "`cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
fi
ifelse([$3],,
AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package]))
AC_REQUIRE([AM_SANITY_CHECK])
AC_REQUIRE([AC_ARG_PROGRAM])
dnl FIXME This is truly gross.
missing_dir=`cd $ac_aux_dir && pwd`
AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir)
AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir)
AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir)
AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
AC_REQUIRE([AC_PROG_MAKE_SET])])
#
# Check to make sure that the build environment is sane.
#
AC_DEFUN(AM_SANITY_CHECK,
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
echo timestamp > conftestfile
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
set X `ls -Lt $srcdir/configure conftestfile 2> /dev/null`
if test "[$]*" = "X"; then
# -L didn't work.
set X `ls -t $srcdir/configure conftestfile`
fi
if test "[$]*" != "X $srcdir/configure conftestfile" \
&& test "[$]*" != "X conftestfile $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
# broken ls alias from the environment. This has actually
# happened. Such a system could not be considered "sane".
AC_MSG_ERROR([ls -t appears to fail. Make sure there is not a broken
alias in your environment])
fi
test "[$]2" = conftestfile
)
then
# Ok.
:
else
AC_MSG_ERROR([newly created file is older than distributed files!
Check your system clock])
fi
rm -f conftest*
AC_MSG_RESULT(yes)])
dnl AM_MISSING_PROG(NAME, PROGRAM, DIRECTORY)
dnl The program must properly implement --version.
AC_DEFUN(AM_MISSING_PROG,
[AC_MSG_CHECKING(for working $2)
# Run test in a subshell; some versions of sh will print an error if
# an executable is not found, even if stderr is redirected.
# Redirect stdin to placate older versions of autoconf. Sigh.
if ($2 --version) < /dev/null > /dev/null 2>&1; then
$1=$2
AC_MSG_RESULT(found)
else
$1="$3/missing $2"
AC_MSG_RESULT(missing)
fi
AC_SUBST($1)])
# Like AC_CONFIG_HEADER, but automatically create stamp file.
AC_DEFUN(AM_CONFIG_HEADER,
[AC_PREREQ([2.12])
AC_CONFIG_HEADER([$1])
dnl When config.status generates a header, we must update the stamp-h file.
dnl This file resides in the same directory as the config header
dnl that is generated. We must strip everything past the first ":",
dnl and everything past the last "/".
AC_OUTPUT_COMMANDS(changequote(<<,>>)dnl
ifelse(patsubst(<<$1>>, <<[^ ]>>, <<>>), <<>>,
<<test -z "<<$>>CONFIG_HEADERS" || echo timestamp > patsubst(<<$1>>, <<^\([^:]*/\)?.*>>, <<\1>>)stamp-h<<>>dnl>>,
<<am_indx=1
for am_file in <<$1>>; do
case " <<$>>CONFIG_HEADERS " in
*" <<$>>am_file "*<<)>>
echo timestamp > `echo <<$>>am_file | sed -e 's%:.*%%' -e 's%[^/]*$%%'`stamp-h$am_indx
;;
esac
am_indx=`expr "<<$>>am_indx" + 1`
done<<>>dnl>>)
changequote([,]))])
dnl AM_PROG_LEX
dnl Look for flex, lex or missing, then run AC_PROG_LEX and AC_DECL_YYTEXT
AC_DEFUN(AM_PROG_LEX,
[missing_dir=ifelse([$1],,`cd $ac_aux_dir && pwd`,$1)
AC_CHECK_PROGS(LEX, flex lex, "$missing_dir/missing flex")
AC_PROG_LEX
AC_DECL_YYTEXT])

149
aclocal.m4 vendored Normal file
View File

@ -0,0 +1,149 @@
dnl aclocal.m4 generated automatically by aclocal 1.4
dnl Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
dnl PARTICULAR PURPOSE.
dnl aclocal.m4 generated automatically by aclocal 1.4
dnl Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
dnl PARTICULAR PURPOSE.
# Do all the work for Automake. This macro actually does too much --
# some checks are only needed if your package does certain things.
# But this isn't really a big deal.
# serial 1
dnl Usage:
dnl AM_INIT_AUTOMAKE(package,version, [no-define])
AC_DEFUN(AM_INIT_AUTOMAKE,
[AC_REQUIRE([AC_PROG_INSTALL])
PACKAGE=[$1]
AC_SUBST(PACKAGE)
VERSION=[$2]
AC_SUBST(VERSION)
dnl test to see if srcdir already configured
if test "`cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
fi
ifelse([$3],,
AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package]))
AC_REQUIRE([AM_SANITY_CHECK])
AC_REQUIRE([AC_ARG_PROGRAM])
dnl FIXME This is truly gross.
missing_dir=`cd $ac_aux_dir && pwd`
AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir)
AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir)
AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir)
AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
AC_REQUIRE([AC_PROG_MAKE_SET])])
#
# Check to make sure that the build environment is sane.
#
AC_DEFUN(AM_SANITY_CHECK,
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
echo timestamp > conftestfile
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
set X `ls -Lt $srcdir/configure conftestfile 2> /dev/null`
if test "[$]*" = "X"; then
# -L didn't work.
set X `ls -t $srcdir/configure conftestfile`
fi
if test "[$]*" != "X $srcdir/configure conftestfile" \
&& test "[$]*" != "X conftestfile $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
# broken ls alias from the environment. This has actually
# happened. Such a system could not be considered "sane".
AC_MSG_ERROR([ls -t appears to fail. Make sure there is not a broken
alias in your environment])
fi
test "[$]2" = conftestfile
)
then
# Ok.
:
else
AC_MSG_ERROR([newly created file is older than distributed files!
Check your system clock])
fi
rm -f conftest*
AC_MSG_RESULT(yes)])
dnl AM_MISSING_PROG(NAME, PROGRAM, DIRECTORY)
dnl The program must properly implement --version.
AC_DEFUN(AM_MISSING_PROG,
[AC_MSG_CHECKING(for working $2)
# Run test in a subshell; some versions of sh will print an error if
# an executable is not found, even if stderr is redirected.
# Redirect stdin to placate older versions of autoconf. Sigh.
if ($2 --version) < /dev/null > /dev/null 2>&1; then
$1=$2
AC_MSG_RESULT(found)
else
$1="$3/missing $2"
AC_MSG_RESULT(missing)
fi
AC_SUBST($1)])
# Like AC_CONFIG_HEADER, but automatically create stamp file.
AC_DEFUN(AM_CONFIG_HEADER,
[AC_PREREQ([2.12])
AC_CONFIG_HEADER([$1])
dnl When config.status generates a header, we must update the stamp-h file.
dnl This file resides in the same directory as the config header
dnl that is generated. We must strip everything past the first ":",
dnl and everything past the last "/".
AC_OUTPUT_COMMANDS(changequote(<<,>>)dnl
ifelse(patsubst(<<$1>>, <<[^ ]>>, <<>>), <<>>,
<<test -z "<<$>>CONFIG_HEADERS" || echo timestamp > patsubst(<<$1>>, <<^\([^:]*/\)?.*>>, <<\1>>)stamp-h<<>>dnl>>,
<<am_indx=1
for am_file in <<$1>>; do
case " <<$>>CONFIG_HEADERS " in
*" <<$>>am_file "*<<)>>
echo timestamp > `echo <<$>>am_file | sed -e 's%:.*%%' -e 's%[^/]*$%%'`stamp-h$am_indx
;;
esac
am_indx=`expr "<<$>>am_indx" + 1`
done<<>>dnl>>)
changequote([,]))])
dnl AM_PROG_LEX
dnl Look for flex, lex or missing, then run AC_PROG_LEX and AC_DECL_YYTEXT
AC_DEFUN(AM_PROG_LEX,
[missing_dir=ifelse([$1],,`cd $ac_aux_dir && pwd`,$1)
AC_CHECK_PROGS(LEX, flex lex, "$missing_dir/missing flex")
AC_PROG_LEX
AC_DECL_YYTEXT])

40
checkbasic Executable file
View File

@ -0,0 +1,40 @@
#!/bin/sh
#
# checkbasic - A script for mbse bbs that checks if your
# installation is correct. If it is then
# normal installation is allowed. If it is
# pristine, basic installation must be done.
# If it bad or incomplete installed it will
# give an errormessage.
#
# v1.00 08-Oct-2000 (c) Michiel Broek.
if [ "`grep mbse: /etc/passwd`" != "" ]; then
if [ "`grep bbs: /etc/group`" != "" ]; then
if [ -n "$MBSE_ROOT" ]; then
if [ "$LOGNAME" = "mbse" ]; then
#
# Looks good, normal mbse user and environment is set.
# Exit with errorcode 0
echo "Hm, looks good..."
exit 0
else
echo "*** You are not logged in as user 'mbse' ***"
exit 1
fi
else
echo "*** MBSE_ROOT environment is not set or you are not 'mbse' ***"
exit 1
fi
else
echo "*** Group 'bbs' is missing on your system ***"
exit 1
fi
else
echo "*** User 'mbse' is missing on your system ***"
echo " It looks like you need to do a basic install."
echo " Make sure you are root and type ./SETUP.sh and"
echo " read the file INSTALL for instructions."
fi

973
config.guess vendored Executable file
View File

@ -0,0 +1,973 @@
#! /bin/sh
# Attempt to guess a canonical system name.
# Copyright (C) 1992, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc.
#
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.
# Written by Per Bothner <bothner@cygnus.com>.
# The master version of this file is at the FSF in /home/gd/gnu/lib.
#
# This script attempts to guess a canonical system name similar to
# config.sub. If it succeeds, it prints the system name on stdout, and
# exits with 0. Otherwise, it exits with 1.
#
# The plan is that this can be called by configure scripts if you
# don't specify an explicit system type (host/target name).
#
# Only a few systems have been added to this list; please add others
# (but try to keep the structure clean).
#
# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
# (ghazi@noc.rutgers.edu 8/24/94.)
if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
PATH=$PATH:/.attbin ; export PATH
fi
UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
dummy=dummy-$$
trap 'rm -f $dummy.c $dummy.o $dummy; exit 1' 1 2 15
# Note: order is significant - the case branches are not exclusive.
case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
alpha:OSF1:*:*)
if test $UNAME_RELEASE = "V4.0"; then
UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
fi
# A Vn.n version is a released version.
# A Tn.n version is a released field test version.
# A Xn.n version is an unreleased experimental baselevel.
# 1.2 uses "1.2" for uname -r.
cat <<EOF >$dummy.s
.globl main
.ent main
main:
.frame \$30,0,\$26,0
.prologue 0
.long 0x47e03d80 # implver $0
lda \$2,259
.long 0x47e20c21 # amask $2,$1
srl \$1,8,\$2
sll \$2,2,\$2
sll \$0,3,\$0
addl \$1,\$0,\$0
addl \$2,\$0,\$0
ret \$31,(\$26),1
.end main
EOF
${CC-cc} $dummy.s -o $dummy 2>/dev/null
if test "$?" = 0 ; then
./$dummy
case "$?" in
7)
UNAME_MACHINE="alpha"
;;
15)
UNAME_MACHINE="alphaev5"
;;
14)
UNAME_MACHINE="alphaev56"
;;
10)
UNAME_MACHINE="alphapca56"
;;
16)
UNAME_MACHINE="alphaev6"
;;
esac
fi
rm -f $dummy.s $dummy
echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VTX]//' | tr [[A-Z]] [[a-z]]`
exit 0 ;;
21064:Windows_NT:50:3)
echo alpha-dec-winnt3.5
exit 0 ;;
Amiga*:UNIX_System_V:4.0:*)
echo m68k-cbm-sysv4
exit 0;;
amiga:NetBSD:*:*)
echo m68k-cbm-netbsd${UNAME_RELEASE}
exit 0 ;;
amiga:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
*:[Aa]miga[Oo][Ss]:*:*)
echo ${UNAME_MACHINE}-unknown-amigaos
exit 0 ;;
arc64:OpenBSD:*:*)
echo mips64el-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
arc:OpenBSD:*:*)
echo mipsel-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
hkmips:OpenBSD:*:*)
echo mips-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
pmax:OpenBSD:*:*)
echo mipsel-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
sgi:OpenBSD:*:*)
echo mips-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
wgrisc:OpenBSD:*:*)
echo mipsel-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
echo arm-acorn-riscix${UNAME_RELEASE}
exit 0;;
arm32:NetBSD:*:*)
echo arm-unknown-netbsd`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
exit 0 ;;
SR2?01:HI-UX/MPP:*:*)
echo hppa1.1-hitachi-hiuxmpp
exit 0;;
Pyramid*:OSx*:*:*|MIS*:OSx*:*:*|MIS*:SMP_DC-OSx*:*:*)
# akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
if test "`(/bin/universe) 2>/dev/null`" = att ; then
echo pyramid-pyramid-sysv3
else
echo pyramid-pyramid-bsd
fi
exit 0 ;;
NILE:*:*:dcosx)
echo pyramid-pyramid-svr4
exit 0 ;;
sun4H:SunOS:5.*:*)
echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit 0 ;;
sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit 0 ;;
i86pc:SunOS:5.*:*)
echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit 0 ;;
sun4*:SunOS:6*:*)
# According to config.sub, this is the proper way to canonicalize
# SunOS6. Hard to guess exactly what SunOS6 will be like, but
# it's likely to be more like Solaris than SunOS4.
echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit 0 ;;
sun4*:SunOS:*:*)
case "`/usr/bin/arch -k`" in
Series*|S4*)
UNAME_RELEASE=`uname -v`
;;
esac
# Japanese Language versions have a version number like `4.1.3-JL'.
echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'`
exit 0 ;;
sun3*:SunOS:*:*)
echo m68k-sun-sunos${UNAME_RELEASE}
exit 0 ;;
sun*:*:4.2BSD:*)
UNAME_RELEASE=`(head -1 /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
test "x${UNAME_RELEASE}" = "x" && UNAME_RELEASE=3
case "`/bin/arch`" in
sun3)
echo m68k-sun-sunos${UNAME_RELEASE}
;;
sun4)
echo sparc-sun-sunos${UNAME_RELEASE}
;;
esac
exit 0 ;;
aushp:SunOS:*:*)
echo sparc-auspex-sunos${UNAME_RELEASE}
exit 0 ;;
atari*:NetBSD:*:*)
echo m68k-atari-netbsd${UNAME_RELEASE}
exit 0 ;;
atari*:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
sun3*:NetBSD:*:*)
echo m68k-sun-netbsd${UNAME_RELEASE}
exit 0 ;;
sun3*:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
mac68k:NetBSD:*:*)
echo m68k-apple-netbsd${UNAME_RELEASE}
exit 0 ;;
mac68k:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
mvme68k:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
mvme88k:OpenBSD:*:*)
echo m88k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
powerpc:machten:*:*)
echo powerpc-apple-machten${UNAME_RELEASE}
exit 0 ;;
macppc:NetBSD:*:*)
echo powerpc-apple-netbsd${UNAME_RELEASE}
exit 0 ;;
RISC*:Mach:*:*)
echo mips-dec-mach_bsd4.3
exit 0 ;;
RISC*:ULTRIX:*:*)
echo mips-dec-ultrix${UNAME_RELEASE}
exit 0 ;;
VAX*:ULTRIX*:*:*)
echo vax-dec-ultrix${UNAME_RELEASE}
exit 0 ;;
2020:CLIX:*:*)
echo clipper-intergraph-clix${UNAME_RELEASE}
exit 0 ;;
mips:*:*:UMIPS | mips:*:*:RISCos)
sed 's/^ //' << EOF >$dummy.c
int main (argc, argv) int argc; char **argv; {
#if defined (host_mips) && defined (MIPSEB)
#if defined (SYSTYPE_SYSV)
printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0);
#endif
#if defined (SYSTYPE_SVR4)
printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0);
#endif
#if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0);
#endif
#endif
exit (-1);
}
EOF
${CC-cc} $dummy.c -o $dummy \
&& ./$dummy `echo "${UNAME_RELEASE}" | sed -n 's/\([0-9]*\).*/\1/p'` \
&& rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
echo mips-mips-riscos${UNAME_RELEASE}
exit 0 ;;
Night_Hawk:Power_UNIX:*:*)
echo powerpc-harris-powerunix
exit 0 ;;
m88k:CX/UX:7*:*)
echo m88k-harris-cxux7
exit 0 ;;
m88k:*:4*:R4*)
echo m88k-motorola-sysv4
exit 0 ;;
m88k:*:3*:R3*)
echo m88k-motorola-sysv3
exit 0 ;;
AViiON:dgux:*:*)
# DG/UX returns AViiON for all architectures
UNAME_PROCESSOR=`/usr/bin/uname -p`
if [ $UNAME_PROCESSOR = mc88100 -o $UNAME_PROCESSOR = mc88110 ] ; then
if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx \
-o ${TARGET_BINARY_INTERFACE}x = x ] ; then
echo m88k-dg-dgux${UNAME_RELEASE}
else
echo m88k-dg-dguxbcs${UNAME_RELEASE}
fi
else echo i586-dg-dgux${UNAME_RELEASE}
fi
exit 0 ;;
M88*:DolphinOS:*:*) # DolphinOS (SVR3)
echo m88k-dolphin-sysv3
exit 0 ;;
M88*:*:R3*:*)
# Delta 88k system running SVR3
echo m88k-motorola-sysv3
exit 0 ;;
XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3)
echo m88k-tektronix-sysv3
exit 0 ;;
Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD)
echo m68k-tektronix-bsd
exit 0 ;;
*:IRIX*:*:*)
echo mips-sgi-irix`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'`
exit 0 ;;
????????:AIX?:[12].1:2) # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
echo romp-ibm-aix # uname -m gives an 8 hex-code CPU id
exit 0 ;; # Note that: echo "'`uname -s`'" gives 'AIX '
i?86:AIX:*:*)
echo i386-ibm-aix
exit 0 ;;
*:AIX:2:3)
if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then
sed 's/^ //' << EOF >$dummy.c
#include <sys/systemcfg.h>
main()
{
if (!__power_pc())
exit(1);
puts("powerpc-ibm-aix3.2.5");
exit(0);
}
EOF
${CC-cc} $dummy.c -o $dummy && ./$dummy && rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
echo rs6000-ibm-aix3.2.5
elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then
echo rs6000-ibm-aix3.2.4
else
echo rs6000-ibm-aix3.2
fi
exit 0 ;;
*:AIX:*:4)
IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | head -1 | awk '{ print $1 }'`
if /usr/sbin/lsattr -EHl ${IBM_CPU_ID} | grep POWER >/dev/null 2>&1; then
IBM_ARCH=rs6000
else
IBM_ARCH=powerpc
fi
if [ -x /usr/bin/oslevel ] ; then
IBM_REV=`/usr/bin/oslevel`
else
IBM_REV=4.${UNAME_RELEASE}
fi
echo ${IBM_ARCH}-ibm-aix${IBM_REV}
exit 0 ;;
*:AIX:*:*)
echo rs6000-ibm-aix
exit 0 ;;
ibmrt:4.4BSD:*|romp-ibm:BSD:*)
echo romp-ibm-bsd4.4
exit 0 ;;
ibmrt:*BSD:*|romp-ibm:BSD:*) # covers RT/PC NetBSD and
echo romp-ibm-bsd${UNAME_RELEASE} # 4.3 with uname added to
exit 0 ;; # report: romp-ibm BSD 4.3
*:BOSX:*:*)
echo rs6000-bull-bosx
exit 0 ;;
DPX/2?00:B.O.S.:*:*)
echo m68k-bull-sysv3
exit 0 ;;
9000/[34]??:4.3bsd:1.*:*)
echo m68k-hp-bsd
exit 0 ;;
hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*)
echo m68k-hp-bsd4.4
exit 0 ;;
9000/[34678]??:HP-UX:*:*)
case "${UNAME_MACHINE}" in
9000/31? ) HP_ARCH=m68000 ;;
9000/[34]?? ) HP_ARCH=m68k ;;
9000/6?? | 9000/7?? | 9000/80[24] | 9000/8?[13679] | 9000/892 )
sed 's/^ //' << EOF >$dummy.c
#include <stdlib.h>
#include <unistd.h>
int main ()
{
#if defined(_SC_KERNEL_BITS)
long bits = sysconf(_SC_KERNEL_BITS);
#endif
long cpu = sysconf (_SC_CPU_VERSION);
switch (cpu)
{
case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
case CPU_PA_RISC2_0:
#if defined(_SC_KERNEL_BITS)
switch (bits)
{
case 64: puts ("hppa2.0w"); break;
case 32: puts ("hppa2.0n"); break;
default: puts ("hppa2.0"); break;
} break;
#else /* !defined(_SC_KERNEL_BITS) */
puts ("hppa2.0"); break;
#endif
default: puts ("hppa1.0"); break;
}
exit (0);
}
EOF
(${CC-cc} $dummy.c -o $dummy 2>/dev/null ) && HP_ARCH=`./$dummy`
rm -f $dummy.c $dummy
esac
HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
echo ${HP_ARCH}-hp-hpux${HPUX_REV}
exit 0 ;;
3050*:HI-UX:*:*)
sed 's/^ //' << EOF >$dummy.c
#include <unistd.h>
int
main ()
{
long cpu = sysconf (_SC_CPU_VERSION);
/* The order matters, because CPU_IS_HP_MC68K erroneously returns
true for CPU_PA_RISC1_0. CPU_IS_PA_RISC returns correct
results, however. */
if (CPU_IS_PA_RISC (cpu))
{
switch (cpu)
{
case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break;
case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break;
case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break;
default: puts ("hppa-hitachi-hiuxwe2"); break;
}
}
else if (CPU_IS_HP_MC68K (cpu))
puts ("m68k-hitachi-hiuxwe2");
else puts ("unknown-hitachi-hiuxwe2");
exit (0);
}
EOF
${CC-cc} $dummy.c -o $dummy && ./$dummy && rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
echo unknown-hitachi-hiuxwe2
exit 0 ;;
9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:* )
echo hppa1.1-hp-bsd
exit 0 ;;
9000/8??:4.3bsd:*:*)
echo hppa1.0-hp-bsd
exit 0 ;;
hp7??:OSF1:*:* | hp8?[79]:OSF1:*:* )
echo hppa1.1-hp-osf
exit 0 ;;
hp8??:OSF1:*:*)
echo hppa1.0-hp-osf
exit 0 ;;
i?86:OSF1:*:*)
if [ -x /usr/sbin/sysversion ] ; then
echo ${UNAME_MACHINE}-unknown-osf1mk
else
echo ${UNAME_MACHINE}-unknown-osf1
fi
exit 0 ;;
parisc*:Lites*:*:*)
echo hppa1.1-hp-lites
exit 0 ;;
C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
echo c1-convex-bsd
exit 0 ;;
C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
if getsysinfo -f scalar_acc
then echo c32-convex-bsd
else echo c2-convex-bsd
fi
exit 0 ;;
C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
echo c34-convex-bsd
exit 0 ;;
C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
echo c38-convex-bsd
exit 0 ;;
C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
echo c4-convex-bsd
exit 0 ;;
CRAY*X-MP:*:*:*)
echo xmp-cray-unicos
exit 0 ;;
CRAY*Y-MP:*:*:*)
echo ymp-cray-unicos${UNAME_RELEASE}
exit 0 ;;
CRAY*[A-Z]90:*:*:*)
echo ${UNAME_MACHINE}-cray-unicos${UNAME_RELEASE} \
| sed -e 's/CRAY.*\([A-Z]90\)/\1/' \
-e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/
exit 0 ;;
CRAY*TS:*:*:*)
echo t90-cray-unicos${UNAME_RELEASE}
exit 0 ;;
CRAY*T3E:*:*:*)
echo t3e-cray-unicosmk${UNAME_RELEASE}
exit 0 ;;
CRAY-2:*:*:*)
echo cray2-cray-unicos
exit 0 ;;
F300:UNIX_System_V:*:*)
FUJITSU_SYS=`uname -p | tr [A-Z] [a-z] | sed -e 's/\///'`
FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
echo "f300-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
exit 0 ;;
F301:UNIX_System_V:*:*)
echo f301-fujitsu-uxpv`echo $UNAME_RELEASE | sed 's/ .*//'`
exit 0 ;;
hp3[0-9][05]:NetBSD:*:*)
echo m68k-hp-netbsd${UNAME_RELEASE}
exit 0 ;;
hp300:OpenBSD:*:*)
echo m68k-unknown-openbsd${UNAME_RELEASE}
exit 0 ;;
sparc*:BSD/OS:*:*)
echo sparc-unknown-bsdi${UNAME_RELEASE}
exit 0 ;;
i?86:BSD/386:*:* | i?86:BSD/OS:*:*)
echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
exit 0 ;;
*:BSD/OS:*:*)
echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
exit 0 ;;
*:FreeBSD:*:*)
echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
exit 0 ;;
*:NetBSD:*:*)
echo ${UNAME_MACHINE}-unknown-netbsd`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
exit 0 ;;
*:OpenBSD:*:*)
echo ${UNAME_MACHINE}-unknown-openbsd`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
exit 0 ;;
i*:CYGWIN*:*)
echo ${UNAME_MACHINE}-pc-cygwin
exit 0 ;;
i*:MINGW*:*)
echo ${UNAME_MACHINE}-pc-mingw32
exit 0 ;;
p*:CYGWIN*:*)
echo powerpcle-unknown-cygwin
exit 0 ;;
prep*:SunOS:5.*:*)
echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit 0 ;;
*:GNU:*:*)
echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
exit 0 ;;
*:Linux:*:*)
# uname on the ARM produces all sorts of strangeness, and we need to
# filter it out.
case "$UNAME_MACHINE" in
arm* | sa110*) UNAME_MACHINE="arm" ;;
esac
# The BFD linker knows what the default object file format is, so
# first see if it will tell us.
ld_help_string=`ld --help 2>&1`
ld_supported_emulations=`echo $ld_help_string \
| sed -ne '/supported emulations:/!d
s/[ ][ ]*/ /g
s/.*supported emulations: *//
s/ .*//
p'`
case "$ld_supported_emulations" in
i?86linux) echo "${UNAME_MACHINE}-pc-linux-gnuaout" ; exit 0 ;;
i?86coff) echo "${UNAME_MACHINE}-pc-linux-gnucoff" ; exit 0 ;;
sparclinux) echo "${UNAME_MACHINE}-unknown-linux-gnuaout" ; exit 0 ;;
armlinux) echo "${UNAME_MACHINE}-unknown-linux-gnuaout" ; exit 0 ;;
m68klinux) echo "${UNAME_MACHINE}-unknown-linux-gnuaout" ; exit 0 ;;
elf32ppc) echo "powerpc-unknown-linux-gnu" ; exit 0 ;;
esac
if test "${UNAME_MACHINE}" = "alpha" ; then
sed 's/^ //' <<EOF >$dummy.s
.globl main
.ent main
main:
.frame \$30,0,\$26,0
.prologue 0
.long 0x47e03d80 # implver $0
lda \$2,259
.long 0x47e20c21 # amask $2,$1
srl \$1,8,\$2
sll \$2,2,\$2
sll \$0,3,\$0
addl \$1,\$0,\$0
addl \$2,\$0,\$0
ret \$31,(\$26),1
.end main
EOF
LIBC=""
${CC-cc} $dummy.s -o $dummy 2>/dev/null
if test "$?" = 0 ; then
./$dummy
case "$?" in
7)
UNAME_MACHINE="alpha"
;;
15)
UNAME_MACHINE="alphaev5"
;;
14)
UNAME_MACHINE="alphaev56"
;;
10)
UNAME_MACHINE="alphapca56"
;;
16)
UNAME_MACHINE="alphaev6"
;;
esac
objdump --private-headers $dummy | \
grep ld.so.1 > /dev/null
if test "$?" = 0 ; then
LIBC="libc1"
fi
fi
rm -f $dummy.s $dummy
echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC} ; exit 0
elif test "${UNAME_MACHINE}" = "mips" ; then
cat >$dummy.c <<EOF
main(argc, argv)
int argc;
char *argv[];
{
#ifdef __MIPSEB__
printf ("%s-unknown-linux-gnu\n", argv[1]);
#endif
#ifdef __MIPSEL__
printf ("%sel-unknown-linux-gnu\n", argv[1]);
#endif
return 0;
}
EOF
${CC-cc} $dummy.c -o $dummy 2>/dev/null && ./$dummy "${UNAME_MACHINE}" && rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
else
# Either a pre-BFD a.out linker (linux-gnuoldld)
# or one that does not give us useful --help.
# GCC wants to distinguish between linux-gnuoldld and linux-gnuaout.
# If ld does not provide *any* "supported emulations:"
# that means it is gnuoldld.
echo "$ld_help_string" | grep >/dev/null 2>&1 "supported emulations:"
test $? != 0 && echo "${UNAME_MACHINE}-pc-linux-gnuoldld" && exit 0
case "${UNAME_MACHINE}" in
i?86)
VENDOR=pc;
;;
*)
VENDOR=unknown;
;;
esac
# Determine whether the default compiler is a.out or elf
cat >$dummy.c <<EOF
#include <features.h>
main(argc, argv)
int argc;
char *argv[];
{
#ifdef __ELF__
# ifdef __GLIBC__
# if __GLIBC__ >= 2
printf ("%s-${VENDOR}-linux-gnu\n", argv[1]);
# else
printf ("%s-${VENDOR}-linux-gnulibc1\n", argv[1]);
# endif
# else
printf ("%s-${VENDOR}-linux-gnulibc1\n", argv[1]);
# endif
#else
printf ("%s-${VENDOR}-linux-gnuaout\n", argv[1]);
#endif
return 0;
}
EOF
${CC-cc} $dummy.c -o $dummy 2>/dev/null && ./$dummy "${UNAME_MACHINE}" && rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
fi ;;
# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there. earlier versions
# are messed up and put the nodename in both sysname and nodename.
i?86:DYNIX/ptx:4*:*)
echo i386-sequent-sysv4
exit 0 ;;
i?86:UNIX_SV:4.2MP:2.*)
# Unixware is an offshoot of SVR4, but it has its own version
# number series starting with 2...
# I am not positive that other SVR4 systems won't match this,
# I just have to hope. -- rms.
# Use sysv4.2uw... so that sysv4* matches it.
echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
exit 0 ;;
i?86:*:4.*:* | i?86:SYSTEM_V:4.*:*)
if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
echo ${UNAME_MACHINE}-univel-sysv${UNAME_RELEASE}
else
echo ${UNAME_MACHINE}-pc-sysv${UNAME_RELEASE}
fi
exit 0 ;;
i?86:*:3.2:*)
if test -f /usr/options/cb.name; then
UNAME_REL=`sed -n 's/.*Version //p' </usr/options/cb.name`
echo ${UNAME_MACHINE}-pc-isc$UNAME_REL
elif /bin/uname -X 2>/dev/null >/dev/null ; then
UNAME_REL=`(/bin/uname -X|egrep Release|sed -e 's/.*= //')`
(/bin/uname -X|egrep i80486 >/dev/null) && UNAME_MACHINE=i486
(/bin/uname -X|egrep '^Machine.*Pentium' >/dev/null) \
&& UNAME_MACHINE=i586
echo ${UNAME_MACHINE}-pc-sco$UNAME_REL
else
echo ${UNAME_MACHINE}-pc-sysv32
fi
exit 0 ;;
i?86:UnixWare:*:*)
if /bin/uname -X 2>/dev/null >/dev/null ; then
(/bin/uname -X|egrep '^Machine.*Pentium' >/dev/null) \
&& UNAME_MACHINE=i586
fi
echo ${UNAME_MACHINE}-unixware-${UNAME_RELEASE}-${UNAME_VERSION}
exit 0 ;;
pc:*:*:*)
# uname -m prints for DJGPP always 'pc', but it prints nothing about
# the processor, so we play safe by assuming i386.
echo i386-pc-msdosdjgpp
exit 0 ;;
Intel:Mach:3*:*)
echo i386-pc-mach3
exit 0 ;;
paragon:*:*:*)
echo i860-intel-osf1
exit 0 ;;
i860:*:4.*:*) # i860-SVR4
if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then
echo i860-stardent-sysv${UNAME_RELEASE} # Stardent Vistra i860-SVR4
else # Add other i860-SVR4 vendors below as they are discovered.
echo i860-unknown-sysv${UNAME_RELEASE} # Unknown i860-SVR4
fi
exit 0 ;;
mini*:CTIX:SYS*5:*)
# "miniframe"
echo m68010-convergent-sysv
exit 0 ;;
M68*:*:R3V[567]*:*)
test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
3[34]??:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 4850:*:4.0:3.0)
OS_REL=''
test -r /etc/.relid \
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
&& echo i486-ncr-sysv4.3${OS_REL} && exit 0
/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
&& echo i586-ncr-sysv4.3${OS_REL} && exit 0 ;;
3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
&& echo i486-ncr-sysv4 && exit 0 ;;
m68*:LynxOS:2.*:*)
echo m68k-unknown-lynxos${UNAME_RELEASE}
exit 0 ;;
mc68030:UNIX_System_V:4.*:*)
echo m68k-atari-sysv4
exit 0 ;;
i?86:LynxOS:2.*:*)
echo i386-unknown-lynxos${UNAME_RELEASE}
exit 0 ;;
TSUNAMI:LynxOS:2.*:*)
echo sparc-unknown-lynxos${UNAME_RELEASE}
exit 0 ;;
rs6000:LynxOS:2.*:* | PowerPC:LynxOS:2.*:*)
echo rs6000-unknown-lynxos${UNAME_RELEASE}
exit 0 ;;
SM[BE]S:UNIX_SV:*:*)
echo mips-dde-sysv${UNAME_RELEASE}
exit 0 ;;
RM*:SINIX-*:*:*)
echo mips-sni-sysv4
exit 0 ;;
*:SINIX-*:*:*)
if uname -p 2>/dev/null >/dev/null ; then
UNAME_MACHINE=`(uname -p) 2>/dev/null`
echo ${UNAME_MACHINE}-sni-sysv4
else
echo ns32k-sni-sysv
fi
exit 0 ;;
PENTIUM:CPunix:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
# says <Richard.M.Bartel@ccMail.Census.GOV>
echo i586-unisys-sysv4
exit 0 ;;
*:UNIX_System_V:4*:FTX*)
# From Gerald Hewes <hewes@openmarket.com>.
# How about differentiating between stratus architectures? -djm
echo hppa1.1-stratus-sysv4
exit 0 ;;
*:*:*:FTX*)
# From seanf@swdc.stratus.com.
echo i860-stratus-sysv4
exit 0 ;;
mc68*:A/UX:*:*)
echo m68k-apple-aux${UNAME_RELEASE}
exit 0 ;;
news*:NEWS-OS:*:6*)
echo mips-sony-newsos6
exit 0 ;;
R3000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R4000:UNIX_SV:*:*)
if [ -d /usr/nec ]; then
echo mips-nec-sysv${UNAME_RELEASE}
else
echo mips-unknown-sysv${UNAME_RELEASE}
fi
exit 0 ;;
BeBox:BeOS:*:*) # BeOS running on hardware made by Be, PPC only.
echo powerpc-be-beos
exit 0 ;;
BeMac:BeOS:*:*) # BeOS running on Mac or Mac clone, PPC only.
echo powerpc-apple-beos
exit 0 ;;
BePC:BeOS:*:*) # BeOS running on Intel PC compatible.
echo i586-pc-beos
exit 0 ;;
SX-4:SUPER-UX:*:*)
echo sx4-nec-superux${UNAME_RELEASE}
exit 0 ;;
SX-5:SUPER-UX:*:*)
echo sx5-nec-superux${UNAME_RELEASE}
exit 0 ;;
Power*:Rhapsody:*:*)
echo powerpc-apple-rhapsody${UNAME_RELEASE}
exit 0 ;;
*:Rhapsody:*:*)
echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
exit 0 ;;
esac
#echo '(No uname command or uname output not recognized.)' 1>&2
#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
cat >$dummy.c <<EOF
#ifdef _SEQUENT_
# include <sys/types.h>
# include <sys/utsname.h>
#endif
main ()
{
#if defined (sony)
#if defined (MIPSEB)
/* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed,
I don't know.... */
printf ("mips-sony-bsd\n"); exit (0);
#else
#include <sys/param.h>
printf ("m68k-sony-newsos%s\n",
#ifdef NEWSOS4
"4"
#else
""
#endif
); exit (0);
#endif
#endif
#if defined (__arm) && defined (__acorn) && defined (__unix)
printf ("arm-acorn-riscix"); exit (0);
#endif
#if defined (hp300) && !defined (hpux)
printf ("m68k-hp-bsd\n"); exit (0);
#endif
#if defined (NeXT)
#if !defined (__ARCHITECTURE__)
#define __ARCHITECTURE__ "m68k"
#endif
int version;
version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`;
if (version < 4)
printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
else
printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
exit (0);
#endif
#if defined (MULTIMAX) || defined (n16)
#if defined (UMAXV)
printf ("ns32k-encore-sysv\n"); exit (0);
#else
#if defined (CMU)
printf ("ns32k-encore-mach\n"); exit (0);
#else
printf ("ns32k-encore-bsd\n"); exit (0);
#endif
#endif
#endif
#if defined (__386BSD__)
printf ("i386-pc-bsd\n"); exit (0);
#endif
#if defined (sequent)
#if defined (i386)
printf ("i386-sequent-dynix\n"); exit (0);
#endif
#if defined (ns32000)
printf ("ns32k-sequent-dynix\n"); exit (0);
#endif
#endif
#if defined (_SEQUENT_)
struct utsname un;
uname(&un);
if (strncmp(un.version, "V2", 2) == 0) {
printf ("i386-sequent-ptx2\n"); exit (0);
}
if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
printf ("i386-sequent-ptx1\n"); exit (0);
}
printf ("i386-sequent-ptx\n"); exit (0);
#endif
#if defined (vax)
#if !defined (ultrix)
printf ("vax-dec-bsd\n"); exit (0);
#else
printf ("vax-dec-ultrix\n"); exit (0);
#endif
#endif
#if defined (alliant) && defined (i860)
printf ("i860-alliant-bsd\n"); exit (0);
#endif
exit (1);
}
EOF
${CC-cc} $dummy.c -o $dummy 2>/dev/null && ./$dummy && rm $dummy.c $dummy && exit 0
rm -f $dummy.c $dummy
# Apollos put the system type in the environment.
test -d /usr/apollo && { echo ${ISP}-apollo-${SYSTYPE}; exit 0; }
# Convex versions that predate uname can use getsysinfo(1)
if [ -x /usr/convex/getsysinfo ]
then
case `getsysinfo -f cpu_type` in
c1*)
echo c1-convex-bsd
exit 0 ;;
c2*)
if getsysinfo -f scalar_acc
then echo c32-convex-bsd
else echo c2-convex-bsd
fi
exit 0 ;;
c34*)
echo c34-convex-bsd
exit 0 ;;
c38*)
echo c38-convex-bsd
exit 0 ;;
c4*)
echo c4-convex-bsd
exit 0 ;;
esac
fi
#echo '(Unable to guess system type)' 1>&2
exit 1

239
config.h.in Normal file
View File

@ -0,0 +1,239 @@
/* config.h.in. Generated automatically from configure.in by autoheader. */
/* Define to empty if the keyword does not work. */
#undef const
/* Define to `int' if <sys/types.h> doesn't define. */
#undef gid_t
/* Define if you don't have vprintf but do have _doprnt. */
#undef HAVE_DOPRNT
/* Define if your system has a working fnmatch function. */
#undef HAVE_FNMATCH
/* Define if your struct stat has st_blksize. */
#undef HAVE_ST_BLKSIZE
/* Define if you have the strftime function. */
#undef HAVE_STRFTIME
/* Define if you have <sys/wait.h> that is POSIX.1 compatible. */
#undef HAVE_SYS_WAIT_H
/* Define if your struct tm has tm_zone. */
#undef HAVE_TM_ZONE
/* Define if you don't have tm_zone but do have the external array
tzname. */
#undef HAVE_TZNAME
/* Define if utime(file, NULL) sets file's timestamp to the present. */
#undef HAVE_UTIME_NULL
/* Define if you have <vfork.h>. */
#undef HAVE_VFORK_H
/* Define if you have the vprintf function. */
#undef HAVE_VPRINTF
/* Define to `long' if <sys/types.h> doesn't define. */
#undef off_t
/* Define to `int' if <sys/types.h> doesn't define. */
#undef pid_t
/* Define as the return type of signal handlers (int or void). */
#undef RETSIGTYPE
/* Define if the `setpgrp' function takes no argument. */
#undef SETPGRP_VOID
/* Define to `unsigned' if <sys/types.h> doesn't define. */
#undef size_t
/* Define if you have the ANSI C header files. */
#undef STDC_HEADERS
/* Define if you can safely include both <sys/time.h> and <time.h>. */
#undef TIME_WITH_SYS_TIME
/* Define if your <sys/time.h> declares struct tm. */
#undef TM_IN_SYS_TIME
/* Define to `int' if <sys/types.h> doesn't define. */
#undef uid_t
/* Define vfork as fork if vfork does not work. */
#undef vfork
/* Define if lex declares yytext as a char * by default, not a char[]. */
#undef YYTEXT_POINTER
/* Memory debugging */
#undef MEMWATCH
/* If you have gettimeofday function */
#undef HAVE_GETTIMEOFDAY
#undef HAVE_DECLARED_TIMEZONE
#undef HAVE_TM_GMTOFF
#undef HAVE_TM_ZONE
/* If you don't have pid_t */
#undef DONT_HAVE_PID_T
/* Add pid to mbmail */
#undef ADD_PID
/* FSC-0070 */
#undef FSC_0070
/* News postings */
#undef RESTAMP_FUTURE_POSTINGS
#undef RESTAMP_OLD_POSTINGS
/* From mbftpd: */
#undef FNM_PATHNAME
#undef IP_TOS
#undef M_UNIX
#undef NBBY
#undef REGEX
#undef REGEXEC
#undef SHADOW_PASSWORD
#undef SO_OOBINLINE
/* Define if you have the a64l function. */
#undef HAVE_A64L
/* Define if you have the c64i function. */
#undef HAVE_C64I
/* Define if you have the fchmod function. */
#undef HAVE_FCHMOD
/* Define if you have the fchown function. */
#undef HAVE_FCHOWN
/* Define if you have the fsync function. */
#undef HAVE_FSYNC
/* Define if you have the getcwd function. */
#undef HAVE_GETCWD
/* Define if you have the gethostname function. */
#undef HAVE_GETHOSTNAME
/* Define if you have the gettimeofday function. */
#undef HAVE_GETTIMEOFDAY
/* Define if you have the getwd function. */
#undef HAVE_GETWD
/* Define if you have the lckpwdf function. */
#undef HAVE_LCKPWDF
/* Define if you have the mkdir function. */
#undef HAVE_MKDIR
/* Define if you have the mkstemp function. */
#undef HAVE_MKSTEMP
/* Define if you have the mktime function. */
#undef HAVE_MKTIME
/* Define if you have the putenv function. */
#undef HAVE_PUTENV
/* Define if you have the re_comp function. */
#undef HAVE_RE_COMP
/* Define if you have the regcmp function. */
#undef HAVE_REGCMP
/* Define if you have the regcomp function. */
#undef HAVE_REGCOMP
/* Define if you have the rmdir function. */
#undef HAVE_RMDIR
/* Define if you have the select function. */
#undef HAVE_SELECT
/* Define if you have the socket function. */
#undef HAVE_SOCKET
/* Define if you have the strcasestr function. */
#undef HAVE_STRCASESTR
/* Define if you have the strcspn function. */
#undef HAVE_STRCSPN
/* Define if you have the strdup function. */
#undef HAVE_STRDUP
/* Define if you have the strerror function. */
#undef HAVE_STRERROR
/* Define if you have the strspn function. */
#undef HAVE_STRSPN
/* Define if you have the strstr function. */
#undef HAVE_STRSTR
/* Define if you have the strtol function. */
#undef HAVE_STRTOL
/* Define if you have the strtoul function. */
#undef HAVE_STRTOUL
/* Define if you have the uname function. */
#undef HAVE_UNAME
/* Define if you have the <crypt.h> header file. */
#undef HAVE_CRYPT_H
/* Define if you have the <dirent.h> header file. */
#undef HAVE_DIRENT_H
/* Define if you have the <fcntl.h> header file. */
#undef HAVE_FCNTL_H
/* Define if you have the <malloc.h> header file. */
#undef HAVE_MALLOC_H
/* Define if you have the <ndir.h> header file. */
#undef HAVE_NDIR_H
/* Define if you have the <netinet/in.h> header file. */
#undef HAVE_NETINET_IN_H
/* Define if you have the <sys/dir.h> header file. */
#undef HAVE_SYS_DIR_H
/* Define if you have the <sys/file.h> header file. */
#undef HAVE_SYS_FILE_H
/* Define if you have the <sys/ioctl.h> header file. */
#undef HAVE_SYS_IOCTL_H
/* Define if you have the <sys/ndir.h> header file. */
#undef HAVE_SYS_NDIR_H
/* Define if you have the <sys/time.h> header file. */
#undef HAVE_SYS_TIME_H
/* Define if you have the <syslog.h> header file. */
#undef HAVE_SYSLOG_H
/* Define if you have the <termio.h> header file. */
#undef HAVE_TERMIO_H
/* Define if you have the <unistd.h> header file. */
#undef HAVE_UNISTD_H
/* Name of package */
#undef PACKAGE
/* Version number of package */
#undef VERSION

3881
configure vendored Executable file
View File

File diff suppressed because it is too large Load Diff

160
configure.in Normal file
View File

@ -0,0 +1,160 @@
dnl Process this file with autoconf to produce a configure script.
AC_INIT(lib/libs.h)
AM_CONFIG_HEADER(config.h)
SUBDIRS=". lib mbcico mbfido mbftpd mbmon mbsebbs mbtask mbsetup fbutil import lang examples html script"
AC_SUBST(SUBDIRS)
dnl General settings for MBSE BBS
MBSE_PACKAGE=mbsebbs
MBSE_VERSION=0.33.17
AC_SUBST(PACKAGE, $MBSE_PACKAGE)
AC_SUBST(VERSION, $MBSE_VERSION)
AM_INIT_AUTOMAKE($MBSE_PACKAGE, $MBSE_VERSION)
AC_PREFIX_DEFAULT(/opt/mbse)
GROUP="bbs"
OWNER="mbse"
AC_SUBST(GROUP)
AC_SUBST(OWNER)
dnl Checks for programs.
AC_PROG_CC
dnl ALternate awk check, I skip mawk because it doesn't work for MBSE.
AC_CHECK_PROG(AWK, gawk, gawk)
AC_CHECK_PROG(AWK, nawk, nawk)
AC_CHECK_PROG(AWK, awk, awk)
AC_PROG_INSTALL
AC_PROG_MAKE_SET
AC_PROG_RANLIB
AC_PROG_YACC
AM_PROG_LEX
CFLAGS="$CFLAGS -Wall -Wshadow -Wwrite-strings -Wstrict-prototypes -pipe"
dnl Additional commandline switches
AC_ARG_ENABLE(memwatch, [ --enable-memwatch MEMWATCH debugging], [ memwatch=$enableval ], [ memwatch=no ])
AC_ARG_ENABLE(fsc0070, [ --enable-fsc-0070 Enable FSC 0070], [ fsc0070=$enableval ], [ fsc0070=no ])
AC_ARG_ENABLE(addpid, [ --enable-add-pid Enable add PID], [ addpid=$enableval ], [ addpid=no ])
if test "$memwatch" = "yes"; then
AC_DEFINE(MEMWATCH)
fi
if test "$fsc0070" = "yes"; then
AC_DEFINE(FSC_0070)
fi
if test "$addpid" = "yes"; then
AC_DEFINE(ADD_PID)
fi
dnl Defines for MBSE BBS (must use tests or --enable-stuff later)
AC_DEFINE_UNQUOTED(RESTAMP_OLD_POSTINGS, 21)
AC_DEFINE(RESTAMP_FUTURE_POSTINGS)
dnl Checks for libraries.
AC_CHECK_LIB(shadow,setspent,result=yes,result=no)
if test "$result" = "yes"; then
LIBS="$LIBS -lshadow"
SHADOW_PASSWORD=1
LIBSHADOW=1
else
AC_CHECK_LIB(shadow,getspnam,result=yes,result=no)
if test "$result" = "yes"; then
LIBS="$LIBS -lshadow"
SHADOW_PASSWORD=1
LIBSHADOW=1
else
dnl some libc's (glibc 2.x) keep shadow functions in -lc
AC_CHECK_LIB(c,setspent,result=yes,result=no)
if test "$result" = "yes"; then
if test -f /etc/shadow; then
SHADOW_PASSWORD=1
fi
fi
fi
fi
if test "$SHADOW_PASSWORD" = "1"; then
if test "$ac_cv_func_fgetspent" != "yes"; then
AC_CHECK_LIB(shadow,fgetspent,result=yes,result=no)
if test "$result" = "yes"; then
if test "$LIBSHADOW" != "1"; then
LIBS="$LIBS -lshadow"
fi
fi
fi
AC_DEFINE(SHADOW_PASSWORD)
fi
AC_CHECK_LIB(crypt,crypt,result=yes,result=no)
if test "$result" = "yes"; then
LIBS="$LIBS -lcrypt"
AC_CHECK_HEADERS(crypt.h)
fi
dnl Checks for header files.
AC_HEADER_DIRENT
AC_HEADER_STDC
AC_HEADER_SYS_WAIT
AC_CHECK_HEADERS(fcntl.h malloc.h sys/file.h sys/ioctl.h sys/time.h syslog.h termio.h unistd.h netinet/in.h)
AC_STRUCT_TIMEZONE
dnl Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST
AC_TYPE_UID_T
AC_TYPE_OFF_T
AC_TYPE_PID_T
AC_TYPE_SIZE_T
AC_STRUCT_ST_BLKSIZE
AC_HEADER_TIME
AC_STRUCT_TM
dnl Checks for library functions.
AC_CHECK_FUNCS(c64i a64l fchmod fchown fsync lckpwdf strcasestr mkstemp)
AC_FUNC_FNMATCH
AC_PROG_GCC_TRADITIONAL
AC_FUNC_MEMCMP
AC_FUNC_SETPGRP
AC_TYPE_SIGNAL
AC_FUNC_STRFTIME
AC_FUNC_UTIME_NULL
AC_FUNC_VFORK
AC_FUNC_VPRINTF
AC_CHECK_FUNCS(getcwd gethostname gettimeofday getwd mkdir mktime putenv re_comp regcmp regcomp rmdir select socket strcspn strdup strerror strspn strstr strtol strtoul uname)
dnl Check for external programs
AC_PATH_PROG(COMPRESS,compress,no-compress-found-during-configure)
AC_PATH_PROGS(GZIP,gzip,no-gzip-found-during-configure)
dnl
AC_ARG_WITH(log-compress,[ --with-log-compress=METHOD Log compression method (default gzip)], LOG_COMPRESS=$with_log_compress, LOG_COMPRESS=gzip)
case "$LOG_COMPRESS" in
gzip)
LOG_COMPRESS=$GZIP
LOG_COMPRESSEXT=".gz" ;;
compress)
LOG_COMPRESS=$COMPRESS
LOG_COMPRESSEXT=".Z" ;;
*)
LOG_COMPRESS=$LOG_COMPRESS
LOG_COMPRESSEXT=".unknown" ;;
esac
AC_SUBST(LOG_COMPRESS)
AC_SUBST(LOG_COMPRESSEXT)
dnl
AC_OUTPUT(
Makefile
lib/Makefile
mbcico/Makefile
mbfido/Makefile
mbfido/paths.h
mbftpd/Makefile
mbmon/Makefile
mbsebbs/Makefile
mbtask/Makefile
mbsetup/Makefile
fbutil/Makefile
script/Makefile
import/Makefile
lang/Makefile
examples/Makefile
html/Makefile
INSTALL
FILE_ID.DIZ
)

20
examples/Makefile.am Normal file
View File

@ -0,0 +1,20 @@
## Process this file with automake to produce Makefile.in
SUBDIRS = .
EXTRA_DIST = etc.tar menus.tar txtfiles.tar
install-exec-local:
@if [ ! -f $(sysconfdir)/mareas.data ]; then \
tar xfC etc.tar $(sysconfdir) ; \
echo "Installing default databases" ; \
fi
@if [ ! -f $(prefix)/english/menus/main.mnu ]; then \
tar xfC menus.tar $(prefix)/english/menus ; \
echo "Installing default english menus" ; \
fi
@if [ ! -f $(prefix)/english/txtfiles/main.ans ]; then \
tar xfC txtfiles.tar $(prefix)/english/txtfiles ; \
echo "Installing default english txtfiles" ; \
fi

298
examples/Makefile.in Normal file
View File

@ -0,0 +1,298 @@
# Makefile.in generated automatically by automake 1.4 from Makefile.am
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = ..
ACLOCAL = @ACLOCAL@
AUTOCONF = @AUTOCONF@
AUTOMAKE = @AUTOMAKE@
AUTOHEADER = @AUTOHEADER@
INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
transform = @program_transform_name@
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
AWK = @AWK@
CC = @CC@
COMPRESS = @COMPRESS@
GROUP = @GROUP@
GZIP = @GZIP@
LEX = @LEX@
LOG_COMPRESS = @LOG_COMPRESS@
LOG_COMPRESSEXT = @LOG_COMPRESSEXT@
MAKEINFO = @MAKEINFO@
OWNER = @OWNER@
PACKAGE = @PACKAGE@
RANLIB = @RANLIB@
VERSION = @VERSION@
YACC = @YACC@
SUBDIRS = .
EXTRA_DIST = etc.tar menus.tar txtfiles.tar
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
DIST_COMMON = Makefile.am Makefile.in
DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --gnu --include-deps examples/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
@SET_MAKE@
all-recursive install-data-recursive install-exec-recursive \
installdirs-recursive install-recursive uninstall-recursive \
check-recursive installcheck-recursive info-recursive dvi-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
mostlyclean-recursive clean-recursive distclean-recursive \
maintainer-clean-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
rev=''; list='$(SUBDIRS)'; for subdir in $$list; do \
rev="$$subdir $$rev"; \
test "$$subdir" = "." && dot_seen=yes; \
done; \
test "$$dot_seen" = "no" && rev=". $$rev"; \
target=`echo $@ | sed s/-recursive//`; \
for subdir in $$rev; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done && test -z "$$fail"
tags-recursive:
list='$(SUBDIRS)'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
done
tags: TAGS
ID: $(HEADERS) $(SOURCES) $(LISP)
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
here=`pwd` && cd $(srcdir) \
&& mkid -f$$here/ID $$unique $(LISP)
TAGS: tags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test -f $$subdir/TAGS && tags="$$tags -i $$here/$$subdir/TAGS"; \
fi; \
done; \
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
|| (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags $$unique $(LISP) -o $$here/TAGS)
mostlyclean-tags:
clean-tags:
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
subdir = examples
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pr $$/$$file $(distdir)/$$file; \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
for subdir in $(SUBDIRS); do \
if test "$$subdir" = .; then :; else \
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
chmod 777 $(distdir)/$$subdir; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$(top_distdir) distdir=../$(distdir)/$$subdir distdir) \
|| exit 1; \
fi; \
done
info-am:
info: info-recursive
dvi-am:
dvi: dvi-recursive
check-am: all-am
check: check-recursive
installcheck-am:
installcheck: installcheck-recursive
install-exec-am: install-exec-local
install-exec: install-exec-recursive
install-data-am:
install-data: install-data-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-recursive
uninstall-am:
uninstall: uninstall-recursive
all-am: Makefile
all-redirect: all-recursive
install-strip:
$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs: installdirs-recursive
installdirs-am:
mostlyclean-generic:
clean-generic:
distclean-generic:
-rm -f Makefile $(CONFIG_CLEAN_FILES)
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
mostlyclean-am: mostlyclean-tags mostlyclean-generic
mostlyclean: mostlyclean-recursive
clean-am: clean-tags clean-generic mostlyclean-am
clean: clean-recursive
distclean-am: distclean-tags distclean-generic clean-am
distclean: distclean-recursive
maintainer-clean-am: maintainer-clean-tags maintainer-clean-generic \
distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
maintainer-clean: maintainer-clean-recursive
.PHONY: install-data-recursive uninstall-data-recursive \
install-exec-recursive uninstall-exec-recursive installdirs-recursive \
uninstalldirs-recursive all-recursive check-recursive \
installcheck-recursive info-recursive dvi-recursive \
mostlyclean-recursive distclean-recursive clean-recursive \
maintainer-clean-recursive tags tags-recursive mostlyclean-tags \
distclean-tags clean-tags maintainer-clean-tags distdir info-am info \
dvi-am dvi check check-am installcheck-am installcheck \
install-exec-local install-exec-am install-exec install-data-am \
install-data install-am install uninstall-am uninstall all-redirect \
all-am all installdirs-am installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
install-exec-local:
@if [ ! -f $(sysconfdir)/mareas.data ]; then \
tar xfC etc.tar $(sysconfdir) ; \
echo "Installing default databases" ; \
fi
@if [ ! -f $(prefix)/english/menus/main.mnu ]; then \
tar xfC menus.tar $(prefix)/english/menus ; \
echo "Installing default english menus" ; \
fi
@if [ ! -f $(prefix)/english/txtfiles/main.ans ]; then \
tar xfC txtfiles.tar $(prefix)/english/txtfiles ; \
echo "Installing default english txtfiles" ; \
fi
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

BIN
examples/etc.tar Normal file
View File

Binary file not shown.

BIN
examples/menus.tar Normal file
View File

Binary file not shown.

BIN
examples/txtfiles.tar Normal file
View File

Binary file not shown.

26
files.css Normal file
View File

@ -0,0 +1,26 @@
/*
* Example stylesheet MBSE BBS file listings.
*/
BODY { background: beige }
/*
* H1 is the header in the area pages, H2 in the main page.
*/
H1 { color: red; font-family: Arial; font-size: 13pt; font-weight: bold }
H2 { color: black; font-family: Arial; font-size: 13pt; font-weight: bold }
A:link { color: blue }
A:visited { color: blue }
A:active { color: red }
/*
* The look and feel of the file listings. Use a fixed font in the TD
* fields, not Truetype or it will look ugly.
*/
TABLE { background: #CCCCCC }
TH { background: #99CCFF; font-family: Helvetica }
TH.head { background: #FF9900; font-family: Helvetica }
TD { font-family: Fixed; font-size: 12pt }

84
html/Makefile.am Normal file
View File

@ -0,0 +1,84 @@
## Process this file with automake to produce Makefile.in
# Makefile for @PACKAGE@-@VERSION@ html documentation
SUBDIRS = .
EXTRA_DIST = basic.html date.html dist.html manual.css \
flow.html postfix.html gwnews.html index.htm ups.html \
install.html intergate.html intro.html invoking.html \
known_bugs.html mgetty.html routing.html nodelist.html \
ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \
ftsc/fsp-1003.html ftsc/fsp-1009.html ftsc/fts-0007.html \
ftsc/fsc-0046.html ftsc/fsc-0057.html ftsc/fsc-0091.html \
ftsc/fsp-1004.html ftsc/fta-1005.html ftsc/fts-0008.html \
ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fsc-0092.html \
ftsc/fsp-1005.html ftsc/fts-0001.html ftsc/fts-0009.html \
ftsc/fsc-0049.html ftsc/fsc-0062.html ftsc/fsc-0093.html \
ftsc/fsp-1006.html ftsc/fts-0004.html ftsc/index.htm \
ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fsp-1001.html \
ftsc/fsp-1007.html ftsc/fts-0005.html ftsc/fsc-0053.html \
ftsc/fsc-0072.html ftsc/fsp-1002.html ftsc/fsp-1008.html \
ftsc/fts-0006.html ftsc/fsc-0035.html ftsc/fsp-1010.html \
ftsc/fsp-1011.html ftsc/ftscprod.html ftsc/fsc-0088.html \
ftsc/fts-4001.html \
images/b_arrow.gif images/magic.gif images/nodes1.gif \
images/connec.gif images/mbsetup0.gif images/nodes2.gif \
images/domains.gif images/mbsetup1.6.S.gif images/nodes3.gif \
images/e_menu.gif images/mbsetup1.6.gif images/nodes4.gif \
images/emareas.gif images/mbsetup2.gif images/nodes5.gif \
images/emgroup.gif images/modems0.gif images/oneliner.gif \
images/fdb.gif images/newfiles.gif images/protocol.gif \
images/fegroup.gif images/newgroups.gif images/rarrow.gif \
images/fileecho.gif images/nodelist.gif images/security.gif \
images/filefind.gif images/nodelist1.gif images/tty.gif \
images/files.gif images/nodelist2.gif images/tty1.gif \
images/go_to.gif images/nodelist3.gif images/tty2.gif \
images/hatch.gif images/nodelist4.gif images/tty3.gif \
images/language.gif images/nodelist5.gif images/uarrow.gif \
images/larrow.gif images/nodes.gif images/users.gif \
images/mbse.jpg images/taskmgr.gif \
license/copying.html license/hydracom.html license/index.htm \
license/jam.html \
menus/control.html menus/index.htm menus/menu100.html \
menus/menu300.html menus/menu500.html \
menus/menu0.html menus/menu200.html menus/menu400.html \
misc/dropfile.html misc/fileid.html misc/index.htm \
misc/jam.html misc/semafore.html misc/filefind.html \
misc/ftpserver.html misc/ipmailer.html misc/outbound.html \
misc/usleep.html \
programs/import.html programs/mbchat.html \
programs/mbfido.html programs/mbmon.html \
programs/mbtoberep.html \
programs/index.htm programs/mbcico.html \
programs/mbfile.html programs/mbmsg.html \
programs/mbseq.html programs/mbuser.html \
programs/mbaff.html programs/mbdiff.html \
programs/mbindex.html programs/mbout.html \
programs/mbsetup.html programs/mbuseradd.html \
programs/mball.html programs/mbfbgen.html \
programs/mblang.html programs/mbsebbs.html \
programs/mbstat.html programs/mbpasswd.html \
programs/mbtask.html programs/mbmail.html \
setup/archiver.html setup/index.htm setup/bbs.html \
setup/bbslist.html setup/language.html setup/oneliner.html \
setup/emareas.html setup/magic.html setup/mail.html \
setup/protocol.html setup/emgroup.html setup/safe.html \
setup/fdb.html setup/security.html setup/sitedoc.html \
setup/fegroup.html setup/modems.html setup/softinfo.html \
setup/fidonet.html setup/tic.html setup/timebank.html \
setup/fileecho.html setup/newfiles.html setup/filefind.html \
setup/newgroups.html setup/files.html setup/nodes.html \
setup/ttyinfo.html setup/global.html setup/users.html \
setup/hatch.html setup/virscan.html setup/services.html \
setup/domains.html setup/taskmgr.html
install-exec-local:
rm -Rf $(prefix)/html
$(mkinstalldirs) $(prefix)/html
@echo "Installing html documentation in $(prefix)/html"
@cp -Pr $(EXTRA_DIST) $(prefix)/html
chown -R @OWNER@.@GROUP@ $(prefix)/html
chmod -R 0644 $(prefix)/html/*.htm*
chmod -R 0644 $(prefix)/html/images/*.gif

299
html/Makefile.in Normal file
View File

@ -0,0 +1,299 @@
# Makefile.in generated automatically by automake 1.4 from Makefile.am
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
# Makefile for @PACKAGE@-@VERSION@ html documentation
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
top_builddir = ..
ACLOCAL = @ACLOCAL@
AUTOCONF = @AUTOCONF@
AUTOMAKE = @AUTOMAKE@
AUTOHEADER = @AUTOHEADER@
INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
transform = @program_transform_name@
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
AWK = @AWK@
CC = @CC@
COMPRESS = @COMPRESS@
GROUP = @GROUP@
GZIP = @GZIP@
LEX = @LEX@
LOG_COMPRESS = @LOG_COMPRESS@
LOG_COMPRESSEXT = @LOG_COMPRESSEXT@
MAKEINFO = @MAKEINFO@
OWNER = @OWNER@
PACKAGE = @PACKAGE@
RANLIB = @RANLIB@
VERSION = @VERSION@
YACC = @YACC@
SUBDIRS = .
EXTRA_DIST = basic.html date.html dist.html manual.css flow.html postfix.html gwnews.html index.htm ups.html install.html intergate.html intro.html invoking.html known_bugs.html mgetty.html routing.html nodelist.html ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html ftsc/fsp-1003.html ftsc/fsp-1009.html ftsc/fts-0007.html ftsc/fsc-0046.html ftsc/fsc-0057.html ftsc/fsc-0091.html ftsc/fsp-1004.html ftsc/fta-1005.html ftsc/fts-0008.html ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fsc-0092.html ftsc/fsp-1005.html ftsc/fts-0001.html ftsc/fts-0009.html ftsc/fsc-0049.html ftsc/fsc-0062.html ftsc/fsc-0093.html ftsc/fsp-1006.html ftsc/fts-0004.html ftsc/index.htm ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fsp-1001.html ftsc/fsp-1007.html ftsc/fts-0005.html ftsc/fsc-0053.html ftsc/fsc-0072.html ftsc/fsp-1002.html ftsc/fsp-1008.html ftsc/fts-0006.html ftsc/fsc-0035.html ftsc/fsp-1010.html ftsc/fsp-1011.html ftsc/ftscprod.html ftsc/fsc-0088.html ftsc/fts-4001.html images/b_arrow.gif images/magic.gif images/nodes1.gif images/connec.gif images/mbsetup0.gif images/nodes2.gif images/domains.gif images/mbsetup1.6.S.gif images/nodes3.gif images/e_menu.gif images/mbsetup1.6.gif images/nodes4.gif images/emareas.gif images/mbsetup2.gif images/nodes5.gif images/emgroup.gif images/modems0.gif images/oneliner.gif images/fdb.gif images/newfiles.gif images/protocol.gif images/fegroup.gif images/newgroups.gif images/rarrow.gif images/fileecho.gif images/nodelist.gif images/security.gif images/filefind.gif images/nodelist1.gif images/tty.gif images/files.gif images/nodelist2.gif images/tty1.gif images/go_to.gif images/nodelist3.gif images/tty2.gif images/hatch.gif images/nodelist4.gif images/tty3.gif images/language.gif images/nodelist5.gif images/uarrow.gif images/larrow.gif images/nodes.gif images/users.gif images/mbse.jpg images/taskmgr.gif license/copying.html license/hydracom.html license/index.htm license/jam.html menus/control.html menus/index.htm menus/menu100.html menus/menu300.html menus/menu500.html menus/menu0.html menus/menu200.html menus/menu400.html misc/dropfile.html misc/fileid.html misc/index.htm misc/jam.html misc/semafore.html misc/filefind.html misc/ftpserver.html misc/ipmailer.html misc/outbound.html misc/usleep.html programs/import.html programs/mbchat.html programs/mbfido.html programs/mbmon.html programs/mbtoberep.html programs/index.htm programs/mbcico.html programs/mbfile.html programs/mbmsg.html programs/mbseq.html programs/mbuser.html programs/mbaff.html programs/mbdiff.html programs/mbindex.html programs/mbout.html programs/mbsetup.html programs/mbuseradd.html programs/mball.html programs/mbfbgen.html programs/mblang.html programs/mbsebbs.html programs/mbstat.html programs/mbpasswd.html programs/mbtask.html programs/mbmail.html setup/archiver.html setup/index.htm setup/bbs.html setup/bbslist.html setup/language.html setup/oneliner.html setup/emareas.html setup/magic.html setup/mail.html setup/protocol.html setup/emgroup.html setup/safe.html setup/fdb.html setup/security.html setup/sitedoc.html setup/fegroup.html setup/modems.html setup/softinfo.html setup/fidonet.html setup/tic.html setup/timebank.html setup/fileecho.html setup/newfiles.html setup/filefind.html setup/newgroups.html setup/files.html setup/nodes.html setup/ttyinfo.html setup/global.html setup/users.html setup/hatch.html setup/virscan.html setup/services.html setup/domains.html setup/taskmgr.html
mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
DIST_COMMON = Makefile.am Makefile.in
DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --gnu --include-deps html/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
@SET_MAKE@
all-recursive install-data-recursive install-exec-recursive \
installdirs-recursive install-recursive uninstall-recursive \
check-recursive installcheck-recursive info-recursive dvi-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
mostlyclean-recursive clean-recursive distclean-recursive \
maintainer-clean-recursive:
@set fnord $(MAKEFLAGS); amf=$$2; \
dot_seen=no; \
rev=''; list='$(SUBDIRS)'; for subdir in $$list; do \
rev="$$subdir $$rev"; \
test "$$subdir" = "." && dot_seen=yes; \
done; \
test "$$dot_seen" = "no" && rev=". $$rev"; \
target=`echo $@ | sed s/-recursive//`; \
for subdir in $$rev; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done && test -z "$$fail"
tags-recursive:
list='$(SUBDIRS)'; for subdir in $$list; do \
test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
done
tags: TAGS
ID: $(HEADERS) $(SOURCES) $(LISP)
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
here=`pwd` && cd $(srcdir) \
&& mkid -f$$here/ID $$unique $(LISP)
TAGS: tags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) $(LISP)
tags=; \
here=`pwd`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test -f $$subdir/TAGS && tags="$$tags -i $$here/$$subdir/TAGS"; \
fi; \
done; \
list='$(SOURCES) $(HEADERS)'; \
unique=`for i in $$list; do echo $$i; done | \
awk ' { files[$$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$(ETAGS_ARGS)$$unique$(LISP)$$tags" \
|| (cd $(srcdir) && etags $(ETAGS_ARGS) $$tags $$unique $(LISP) -o $$here/TAGS)
mostlyclean-tags:
clean-tags:
distclean-tags:
-rm -f TAGS ID
maintainer-clean-tags:
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
subdir = html
distdir: $(DISTFILES)
$(mkinstalldirs) $(distdir)/ftsc $(distdir)/images $(distdir)/license \
$(distdir)/menus $(distdir)/misc $(distdir)/programs \
$(distdir)/setup
@for file in $(DISTFILES); do \
d=$(srcdir); \
if test -d $$d/$$file; then \
cp -pr $$/$$file $(distdir)/$$file; \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
for subdir in $(SUBDIRS); do \
if test "$$subdir" = .; then :; else \
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
chmod 777 $(distdir)/$$subdir; \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$(top_distdir) distdir=../$(distdir)/$$subdir distdir) \
|| exit 1; \
fi; \
done
info-am:
info: info-recursive
dvi-am:
dvi: dvi-recursive
check-am: all-am
check: check-recursive
installcheck-am:
installcheck: installcheck-recursive
install-exec-am: install-exec-local
install-exec: install-exec-recursive
install-data-am:
install-data: install-data-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-recursive
uninstall-am:
uninstall: uninstall-recursive
all-am: Makefile
all-redirect: all-recursive
install-strip:
$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs: installdirs-recursive
installdirs-am:
mostlyclean-generic:
clean-generic:
distclean-generic:
-rm -f Makefile $(CONFIG_CLEAN_FILES)
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
maintainer-clean-generic:
mostlyclean-am: mostlyclean-tags mostlyclean-generic
mostlyclean: mostlyclean-recursive
clean-am: clean-tags clean-generic mostlyclean-am
clean: clean-recursive
distclean-am: distclean-tags distclean-generic clean-am
distclean: distclean-recursive
maintainer-clean-am: maintainer-clean-tags maintainer-clean-generic \
distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
maintainer-clean: maintainer-clean-recursive
.PHONY: install-data-recursive uninstall-data-recursive \
install-exec-recursive uninstall-exec-recursive installdirs-recursive \
uninstalldirs-recursive all-recursive check-recursive \
installcheck-recursive info-recursive dvi-recursive \
mostlyclean-recursive distclean-recursive clean-recursive \
maintainer-clean-recursive tags tags-recursive mostlyclean-tags \
distclean-tags clean-tags maintainer-clean-tags distdir info-am info \
dvi-am dvi check check-am installcheck-am installcheck \
install-exec-local install-exec-am install-exec install-data-am \
install-data install-am install uninstall-am uninstall all-redirect \
all-am all installdirs-am installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
install-exec-local:
rm -Rf $(prefix)/html
$(mkinstalldirs) $(prefix)/html
@echo "Installing html documentation in $(prefix)/html"
@cp -Pr $(EXTRA_DIST) $(prefix)/html
chown -R @OWNER@.@GROUP@ $(prefix)/html
chmod -R 0644 $(prefix)/html/*.htm*
chmod -R 0644 $(prefix)/html/images/*.gif
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:

152
html/basic.html Executable file
View File

@ -0,0 +1,152 @@
<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 basic installation.</TITLE>
<LINK rel=stylesheet HREF="manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 27-May-2001</h5>
<P>&nbsp;<P>
<h1>MBSE BBS Basic Installation</h1>
<h3>Introduction.</h3>
<p>
Before you compile and install MBSE BBS you must first setup the basic
environment. If you don't do this, things will fail.
<P>&nbsp;<p>
<h3>Step 1: planning the filesystems.</h3>
<p>
MBSE BBS is default installed in <b>/opt/mbse</b>. The spoolfiles (in and
outbound, message bases) go into <b>/var/spool/mbse</b>. In the <b>/opt/mbse</b>
path are several subdirectories, <b>bin</b> for the binaries, <b>etc</b> for the
configuration and some scripts, <b>english</b> and <b>dutch</b> for the language
files and menus, <b>home</b> for the users homedirectories, <b>log</b> for the
logfiles, <b>magic</b> for the filerequest magicnames, <b>fdb</b> for the files
database, <b>var</b> for some statistic files and <b>tmp</b> as temp directory.
<p>
Don't use UMSDOS or SAMBA filesystems for the bbs, stick by the standard Linux
filesystems (ext2). If you intent to make your bbs also accessible
by FTP and WWW you must create the directory structure under the ftp user
behind the pub directory. Read <a href="misc/ftpserver.html">the
ftp server</a> doc for details. If you don't follow these guidlines, you
will run into trouble later and have to spend a lot of time in correcting
this error.
<p>
The default setup will be as follows:<br>
<pre>
/opt/mbse binaries, config and user home directories.
/var/spool/mbse In/outbound, queues, download directories.
</pre>
<P>&nbsp;<p>
<h3>Step 2: Running the installation script.</h3>
<p>
The installation script must be run by root. It checks if there is a
previous or failed installation on your system. If that's so the script will
not run. In other words, you can only run this script once. The script makes
backup copies of the system files it changes, these files will get the
extension <strong>.mbse</strong> To run the installation script you need
the archive <strong>mbbsebbs-0.33.nn.tar.gz</strong>.
Unpack this archive on your system, in /tmp will do fine:
<pre>
cd /tmp
tar xfvz /path/to/the/mbsebbs-0.33.nn.tar.gz
</pre>
To start the script type:
<pre>
cd mbsebbs-0.33.nn
sh ./SETUP.sh
</pre>
The script does the following:
<ol>
<li>Create the group <strong>bbs</strong>
<li>Create the user <strong>mbse</strong>
<li>Create a <strong>.profile</strong> for user <strong>mbse</strong>
<li>Create and set owner of directory tree under /opt/mbse
</ol>
Then the script will ask you to give a password for user <strong>mbse</strong>
This password is for system maintenance and for you to make changes to the
bbs. You will need that frequently but you should not make that password
easy to guess of course. The script will then continue again:
<ol start="5">
<li>The user <strong>bbs</strong> is added.
<li>The password will be removed from user <strong>bbs</strong> This action
will make changes in /etc/shadow (if you have that) otherwise in /etc/passwd.
<li>If they don't exist in the file /etc/services the services fido, tfido
and binkp will be added.
<li>If they don't exist in the file /etc/inetd.conf the internet protocols
for the mailer will be added. The <strong>inetd</strong> is restarted to
activate the changes.
</ol>
<p>&nbsp;<p>
<h3>Step 3: Check the basic installation</h3>
<p>
The last screen of the script is about sanity checks. Perform those checks!
If something is wrong, now is the time to fix it. Don't panic and remember
the backups of the system files that are changed are in /etc with the
extension <strong>.mbse</strong> i.e: those were the original files.
<p>&nbsp;<p>
<h3>Step 4: Install the basic packages.</h3>
<p>
Login as user <b>mbse</b>. While in the home directory unpack the distribution
archives:
<pre>
tar xfvz /path/to/mbsebbs-0.33.nn.tar.gz
</pre>
You now have the subdirectory with sources in the right place. Indeed, if you
have a new installation, you also have unpacked the archive somewere else
to run the installation script. That one can be removed.
Next build the binaries and install them using the folowing commands:
<pre>
cd ~/mbsebbs-0.33.nn
./configure
make
su
password: <em>enter root password here</em>
make install
exit
</pre>
The last part of the installation procedure shows you the location of the bbs
startup script that is added to your system. Because this is your first
time installation, example menus, textfiles and some databases are installed.
If they already excist on your systems (when you do an upgrade) they
will not be installed again.
<p>
Now you must start the <b>mbtask</b> daemon by hand by typing <b>/opt/mbse/bin/mbtask</b>.
Check the file <b>/opt/mbse/log/mbtask.log</b> for startup problems. You may notice that
the program <b>mbcico</b> is started everytime, this is not a problem, it simply doesn't work right
now because you haven't configured anything yet.
<p>&nbsp;<p>
<h3>Step 5: (RedHat) startup problems.</h3>
<p>
From RedHat 6.1 (not the older versions) the behaviour of the
<strong>su</strong> is changed. This may be true for other distributions since
the end of 1999 and for Mandrake as well. The file <code>/etc/rc.d/init.d/mbsed</code> that is
created by the setup script is different then before. The new command
is <strong>su -</strong> instead of simply <strong>su</strong>. It might be
that other new distributions also need the extra minus sign. If that's the
case, please let me know and tell me how I can test what version it is.
<p>&nbsp;<p>
<h3>Step 6: ready.</h3>
<p>
Now the basic environment is finished, the next thing is to <a href="install.html">install</a>
the scripts, examples and configuration.
<P>&nbsp;<P>
<a href="index.htm"><img SRC="images/b_arrow.gif" ALT="Back to Index" BORDER=0 width="33" height="35" ></a>
<a href="index.htm">Back to Index</a>
</blockquote>
</body>
</html>

1
html/date.html Executable file
View File

@ -0,0 +1 @@
<div align=right><font size=-1>Last update 18-Sep-1999</font></div>

74
html/dist.html Normal file
View File

@ -0,0 +1,74 @@
<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>Linux distributions.</TITLE>
<LINK rel=stylesheet HREF="manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 06-Jun-2001</h5>
<P>&nbsp;<P>
<H1>Linux Distributions.</H1>
<P>
<H3>Which distribution</H3>
<P>
Linux is available in several distributions, they all have advantages and
disadvantages for bbs use. Which distribution to pick is very personal.
You should also consider the fact if the bbs machine is the same machine on
which you do your daily work on or if you use a seperate system for the bbs.
I will describe the distributions below for use on dedicated bbs computers,
that means you don't do daily work on them and don't use them to play games.
Most important is that this is my personal view.
<P>&nbsp;<P>
<H3>Slackware</H3>
<P>
I am using MBSE BBS on several Slackware distributions. You can make a very small
setup for MBSE BBS like Zipslack. Not included is the mgetty package.
<P>&nbsp;<P>
<H3>Redhat and Mandrake</H3>
<P>
I write this as if these are the same which isn't true of course. From MBSE
BBS's point of view they are almost the same, so that's why I treat them as
the same distributions. For people with little Linux experience these
distributions are a good choice if you can spare the diskspace. I haven't
found a simple dedicated setup for the bbs, so the safest way is to install
allmost everything, which is quite simple. This will cost you about 1200 Megs.
Maybe that someone more experienced with these distro's can give more details
on how to build a small server. Please note that from RedHat 6.1 and up the
startup script (/etc/rc.d/init.d/mbsed) is different than before. Maybe
this is needed for Mandrake 6.1 and up too.
<P>&nbsp;<P>
<H3>SuSe</H3>
<P>
Since SuSE 7.1 the setup scripts are working and tested. Older distro's
might work.
<P>&nbsp;<P>
<H3>Debian</H3>
<P>
The installation works on a Debian 2.1 and 2.2 distribution without any problems.
How to build an optimized Debian system is not tested by me.
<P>&nbsp;<P>
<H3>Famous last words...</H3>
<P>
I don't have the diskspace for all kinds of Linux distributions to install
at the same time, with the current size of Linux, I only have 2 versions
installed. Also, I don't buy every new distro that's available. If you have
a problem with that, just send me the new distro on CD to test by snailmail.
<P>&nbsp;<P>
<A HREF="index.htm"><IMG SRC="images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

169
html/flow.html Normal file
View File

@ -0,0 +1,169 @@
<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>Running a BBS under Linux.</TITLE>
<LINK rel=stylesheet HREF="manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 06-Jun-2001</h5>
<P>&nbsp;<P>
<H1>Running a BBS under Linux.</H1>
<P>
<h3>Introduction</H3>
<P>
Everyone who has been running a (single line) BBS under DOS until now will
need to understand that running a BBS under Linux (or any other multitasking
os) is completly different of what you are used to. Under DOS things were
quite simple, from AUTOEXEC.BAT you started a new .BAT file that would run
forever and started all needed programs after each other.
The programs that where started
depended on the errorlevel of the previous program. Only one program could
run at the same time.
<P>
People who had previous run a BBS on another multitasking os, or were running
a BBS on a small lan with a fileserver and workstations for each line, are
already more used to the idea of running more programs at the same time,
and to "signal" what to do next with semafore files.
<P>
The Linux aproach is more or less the same, but there are more differences.
The main difference is that there is no mailer connected with the modem waiting
for a call, instead there is a getty process watching your modem(s). Another
big difference is that you don't see what's happening, there is no screen
with the mailer or bbs picture on it. All programs run in the background. If
you don't like that, stop now and go back to your old DOS bbs. It's just the
way everything is done.
<P>
Programs that must start at specific times (events in DOS), are started from
cron, this is the event scheduler for Linux (and other Unixes). With this
program maintenance can be started, polls created etc. For starting programs
when they are needed there is a taskmanager loaded at system bootup. This
taskmanager "watches" the semafore directory of the bbs and will start what
is needed.
<P>&nbsp;<P>
<H3>Waiting for a call .....</H3>
<P>
Under Linux this is done with the mgetty program, this is the
process that is connected with each modem (or ISDN adapter) and waits for a
call. The mgetty program (written by Gert Doering, gert@greenie.muc.de) will
detect the call, and find out what or who did make the call. It can detect
incoming humans who want a login prompt, PPP calls from users who want to
make a PPP connection (browsing your BBS whith netscape for example), A fax
machine trying to deliver a fax and finally a mailer trying to establish
an EMSI, FSC-0006 or FSC-0001 session. The mgetty program is responsible for
starting the right client programs. How to do this is explained in the
installation manuals, but be sure to compile it with Fido and PPP support.
<P>&nbsp;<P>
<H3>A Human is calling.</H3>
<P>
This could be a bbs user. For each user to login to your bbs there must be a
unix account. They automatic create such an account the first time they login
with the <b>bbs</b> account. During the creation of their account the shell that is
installed for there account is the mbsebbs binary, so that's the only thing
that they get if they call in. When they logout the bbs, or drop carrier etc,
the session is ended and mgetty takes over the line again.
Note that they will never can get a Unix shell
unless you install a <b>door</b> in the bbs that calls a shell for them.
<P>
There are probably more accounts on your system that can callin, <b>mbse</b> is
such an account, this is the MBSE BBS maintenance account. This user will
get the shell prompt. Use good passwords for shell accounts, and never change
your setup so that the <b>root</b> user can directly login except from the console.
If you need root access, login as <b>mbse</b> and type <b>su</b> at the prompt to become
root. You might consider installing SSH on your system for remote maintenance.
<P>&nbsp;<P>
<H3>A PPP call is detected.</H3>
<P>
Installing a PPP server on your system is beyound the scope of this project.
However if you did install it, users can login your bbs with their favourite
browser and use your bbs. Note that the necessary tools to automatic create
newsgroups don't excist at this time. With the proper setup you can automatic
create and maintain html pages for the file areas.
<P>&nbsp;<P>
<H3>A mailer call is detected.</h3>
<P>
If a mailer is detected by mgetty, the <b>mbcico</b> program is started and will
take over from mgetty. It will establish a mail session with the caller and
the mail and or files will be exchanged just like any DOS mailer would do.
After the call, mbcico will hangup and mgetty will take control of your modem
again. If there is any mail received, mbcico will place the semafore <b>mailin</b>
so that another process can take care of the received mail. Mbcico will also
detect some IEMSI terminal programs (Frontdoor), and will start the bbs.
<P>&nbsp;<P>
<h3>There is mail in the inbound</h3>
<P>
As I said before, if the <b>mailin</b> semafore is present, the task manager will
then start the <b>mbfido</b> program that will toss the mail, process any files
received and if necessary it will create other semafore's for example to link
the message bases, start the nodelist compiler etc. Note that this can be done
while there may be a new mailsession going on, a bbs user is online, it doesn't
matter. Processing mail and files can be done real multitasking without any
damage to other processes.
<P>&nbsp;<P>
<H3>It's time to poll a node</h3>
<P>
At the time that you whish to poll a node, let cron create "poll" requests.
When a poll is created, the semafore <b>scanout</b> is also created.
The taskmanager will then start mbcico at regular intervals so that mail will
get out. If there is no more mail to send, the <b>scanout</b> semafore is removed.
If a timeslot ends, you can just remove the "poll" requests that didn't succeed.
<P>&nbsp;<P>
<H3>It's Zone Mail Hour, so now what</h3>
<P>
Relax, if you have netmail ready for nodes the
mailer script will try to send these mails to those nodes. If it was crash
mail, and the destination was a non CM node, the mailer will try to send those
mails too. Note that other crashmails are send anytime. Also note that packed
mail and files are not send during ZMH. If a node calls you during ZMH he will
get everything that's waiting, including packed mail and files. The task manager
(more on that later) calculates the Zone Mail Hour from UTC time, you don't
have to change anything for summer- and wintertime.
<P>&nbsp;<P>
<H3>Daily maintenane</h3>
<P>
This is started by cron jobs. There is no need to take
your bbs lines down during maintenance, you can do it any time of the day.
I have made several scripts for this, daily, weekly and monthly.
<P>&nbsp;<P>
<h3>How about system load</h3>
<P>
Because Linux is a 32 bit os, not bothered with a graphical user interface
(unless you install it), it has all the time in the world to serve your
bbs programs. Background programs are build to release time to the Linux os,
they don't need to run fast because it's background processing. The bbs and
the mailer, have a low server load although there is no timerelease build
in. Only the bbs has some short moments when it needs a lot of your system,
for example when a user logs in and scans for new mail. The bbs I run is a
486-DX4 100 MHz, 20 MB ram, with 2 analogue lines, this seems to work fine.
When this system's MOBO died, I used a 386DX33 for several months with
20 MB ram, and the only thing users ever noticed was that scanning for new
mail was slower. I think this is the slowest harware that will work.
However, you must always use 16550A uarts for the COM ports. For best
performance use SCSI disks. I noticed that old 5"FH SCSI disks perform better
for bbs usage then modern EIDE disks. This is probably caused by the fact that
the kernel needs more time for the cheap IDE bus.
If you want to use X11 on your bbs, you need more ram and a faster CPU or a
separate machine via a lan and export the display to that machine.
<P>&nbsp;<P>
<A HREF="index.htm"><IMG SRC="images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BLOCKQUOTE>
</BODY>
</HTML>

79
html/ftsc/fsc-0035.html Executable file
View File

@ -0,0 +1,79 @@
<HTML>
<HEAD>
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Transparent Gateways to and from FidoNet <tm>
Technical Considerations
FSC-0035
Michael Shiels 22 June 89
Copyright 1989, Michael Shiels. All rights reserved. The right to distribute
for non-commercial use is granted to the FidoNet Technical Standards Committee,
provided that no fee is charged. This may be posted on FidoNet electronic BBSs
which charge no fee for accessing this document. Any and all other reproduction
or excerpting requires the explicit written consent of the author.
Gateways
--------
Gatewaying between Fidonet and other networks seems to be the latest feature
which hopefully brings more benefits to the users of each network. But there
are some real problems with gatewaying and doing "transparent" replies.
This proposal should allow for almost totally transparent gateways but requires
the co-operation of BBS software writers to support this following protocol.
Incoming Messages
-----------------
When a message is entered into fidonet from another network it will be entering
through one machine (say 1/2). The userid on the other network may not match
very will with the 2 word 36 character userid on Fidonet. So the following is
done to store away the proper userid of the sender.
Two (2) lines are added to the message (usually at the top of the text portion
hidden by the infamous ^A KLUDGE).
^AREPLYADDR .....\r
which signifies the FULL userid of the person on the other network. The first
36 characters or the full userid if less than 36 characters long, are stored
in the FROM field of the message header. When replies are done they use a
second line of the following form.
^REPLYTO zone:net/node firstname lastname
which is used to signify the "userid" which mail destined to this other network
must be sent to and on which machine that userids resides. Replies are sent
to this zone:net/node and userid with the first line of the message being
changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR
line.
Should you have constructive correction or criticism, please contact:
Michael Shiels
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
uucp: ?!tmsoft!masnet!michael.shiels
Internet: michael.shiels@masnet.uucp
----------
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe
much thanks for the origin and spirit of FidoNet.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

362
html/ftsc/fsc-0039.html Executable file
View File

@ -0,0 +1,362 @@
<HTML>
<HEAD>
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0039
Version: 04
Date: 29-Sep-90
A Type-2 Packet Extension Proposal
Mark A. Howard 1:260/340@FidoNet
Status of this document:
------------------------
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements. Distribution
of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
FTS-0001 is a copyrighted work of Randy Bush.
Introduction
------------
This document serves two major purposes. The first is an attempt to define
and document the Type-2 packet which is widely in use in FidoNet today.
Although FTS-0001 defines the structure of a Type-2 packet, the natural
evolution of our network, mostly with regards to addressing methodology,
has made it necessary to utilize hitherto unused portions of the header
to insert Zone and Point information. Also, it has become apparent that
some of the existing fields are not large enough to accomplish their
original tasks.
The second is to propose a simple mechanism to allow FidoNet to begin to
utilize advanced mail packing techniques. It is quite apparent that while
Type-2 has served us faithfully for some time now, the evolution of our
network in terms of technical and physical complexity has caused us to
consider more efficient and functional ways to pack mail.
It should be made clear that with the exception of the Capability Word,
Capability Word Validation Copy, ProductCode(hi), and Revision(minor),
which are proposed extensions to the Type-2 packet header, this FSC is
an attempt to correctly document existing practices with regards to the
insertion of zone and point info by at least three mail processors in
use today.
The Type-2 Header (Where's the Zone?)
-------------------------------------
Although FTS-0001 has recently been updated to reflect the use of some of
the areas in the packed message header for zone data, at least two other
methods for inserting the zone information have been adopted, making it
necessary to provide support for both formats in all of the zone aware mail
processors. The end result is more code, and redundant information in the
packet header.
This has presented a problem in logistics, as it is difficult to consider
the project of updating mail processors using one type to use the other.
As sufficient indentification is provided, in the form of the product code,
to determine the expected location of the zone information, and because
code already exists in most of the mail processors to overcome this, this
proposal does not attempt to suggest that one method be used over the
other, rather the intent is to attempt to document the extensions in use,
and the products involved.
See the accompanying chart and cross-reference.
The Product Code
----------------
Based upon the current rate of requests for product codes from the FTSC,
it is probable that the Product Code byte will not be large enough to
accomodate all of the codes required. While it is not reasonable to
expect that all Type-2 processors will eventually check the hi-order byte
proposed here, it is likely that 'current' mail processors will. This
can be nothing but benefical, as it will force users to upgrade their
mail processors to a product which will as a minimum, support Type-2
with Zone and Point extensions, and quite possibly, processors that will
utilize more advanced mail packing techniques, making Type-2 extinct once
and for all.
The Capability Word (How do we GET there from here?)
-----------------------------------------------------
Everybody would like to see more efficient and functional ways to pack and
exchange mail. Several Type-3 message bundle proposals exist, but none
really address a problem which must be solved first. The problem is that
since FidoNet is a hobbyist network, no demands can be placed on any one
sysop to upgrade or change their bundling software. Because of this, it
is necessary to consider strategies which allow for the existence of Type-2
bundlers in the network topology.
Considerable advantages can be realized, however, between systems that
consent to use advanced bundling techniques. One way to do this is to
simply send netmail to all of your connecting systems, saying "Hey, I've
got a Type-3 bundler now, how about you?" This could become quite
tiresome, and does not represent much of an improvement on the current
situation.
What would be desirable is a network that would 'upgrade itself'. Given a
situation where mail processors of various capabilities will exist in a
network topology, the goal is to provide a mechanism whereby two links can
determine and utilize the most efficient bundling method to use, in a
manner transparent to the sysop.
For instance, let's say that the FTSC releases the Type-7 All New Singing
and Dancing bundle format. Well, your current version of SlingToss can
only support Types 2, 3, and 5. One of your downlinks gets a new version
of MailMangle which can support Types 2, 3, 4, and 7. Well, it is quite
obvious that since you and he are exchanging 4 megs of mail each night,
and it's an overseas call, that it would be in your interest to obtain a
new version of SlingToss which can support Type 7.
Note that this is *optional*. Because both processors can support Type-3,
they will continue to exchange Type-3 mail quite happily, even though
MailMangle is happily advertising the availability of Type-7. Even your
downlinks which are still using stone-age Type-2 processors will be fine,
as SlingToss will always export Type-2 bundles when no higher capability
can be determined.
So, after dashing off the check to the author, your new version of
SlingToss comes in the mail! You rush over to your system, and install it.
The next time SlingToss exports mail to the MailMangle system, it says
"Hey! I can now support Type 2, 3, 5, and 7! So, whattya got?" This is
no skin off MailMangle's nose, he's had Type-7 for quite a while, and he
begins to export Type-7 bundles to SlingToss. "It's about time.", he says.
Now, this scenario is made possible by implementing a 'Capability Word' in
the present and future packet headers. The Capability Update mechanism
depends on several assumptions:
1) Any Advanced Capability Bundler *MUST* be capable of receiving and
faithfully processing Type-2 bundles. Hopefully, the inbound packets
will be in the new format proposed by this document, but then again,
this is not an exact science. What this means is that it is likely
that some packets may arrive with the Capability Word (CW) set to 0.
In this case, Type-2 is assumed, assuring compatibility. The only
caveat is that it is conceivable that some obscure mail processor
uses the location proposed for the CW for other arcane purposes. This
| can detected through the CWValidation Copy, which is byte-swapped and
| compared with the CW at that time. If a mismatch is found, a CW of
| type 0 is assumed, and a Type-2 bundling method is used.
2) An Advanced Capability Bundler, hereafter referred to as a Type-N
Bundler, must have a method to store and maintain the node-by-node
capability information. This can be done many ways, and in fact
several processors already have begun to maintain node information
outside of that found in AREAS.BBS, mostly to implement pre-arranged
alternate compression methods. In a text configuration file, you
might see the following:
; Address Comp Send LastCW ; Comments
Node 1:260/340 ZIP Auto 7 ; Auto detect & upgrade
Node 1:135/20 LZH 3 2,3,7 ; Always send Type-3
Node 1: ARC 2 0 ; Stone-Age processor
Node 1:135/4 --- Auto 7 ; Sent me netmail
Node 1: --- 0 0 ; Don't send CW
In this example, the fields are:
Address - downlink address. Note that this is not necessarily
relative to echomail, only, it is possible to append
information to the node database as netmail packets are
receieved from different addresses.
Comp - desired mail compression method.
Send - Auto - automatically determined maximum common packing
method to use. Automatically update to LastCW
when packing.
LastCW - Last CW received from remote system.
3) A Type-N Bundle will always advertise it's capabilities in the CW
regardless of the type being sent. As shown in the above example,
it allows Type-N processors to automatically track the capability
of your system. Again, in cases where a stone-age processor is
being used, this field will be ignored, and in the unusual event
that it is not ignored, and is somehow harmful to the far system,
the Type-N processor can be configured to send a CW of 0.
The format of the Capability Word is designed to support up to 15 future
bundle types, and is bit-mapped to facilitate the easy determination of
the maximum common level supported between two nodes:
msb Capability Word lsb
Node Supports ------------FTSC Type Supported----------------
U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2
2, 3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
2, 3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
2 (this FSC) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Stone Age** 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
^
+--- Indicates UseNet RFC-822 capability
** - a mismatch in the CWValidation Copy also
produces a CW=0.
In this example, the Type-N bundler would first compare the remote CW
| and the byte-swapped remote CWValidation Copy, and check for a mismatch.
Prior to the compare, the MSB of the CW's are masked, as this bit is
reserved to indicate whether the mail processor is capable of also
accepting UseNet RFC-822 bundles. Following the MSB mask, and bit
comparison, if they do not match, a remote CW of 0 is assumed. If they
match, the Type-N processor would AND the local and remote CW words,
obtaining a CW expressing the Types which are in common to both systems.
The most significant Type will be used, by default, but note that this
assumes that new bundling Types will be increasingly more efficient or
in some way more beneficial.
Because this may not always be the case, there should be a method provided,
as illustrated above, to override the automatic upgrade should this become
the case.
The MSB of the CW is used to indicate whether the mail processor can accept
UseNet RFC-822 bundles or not. It is a separate indicator, and not intended
to be used as a part of the above comparison, however can be used to also
advertise RFC-822 capability to other systems. Since RFC-822 is 'set in
stone', there is no need to assign more than one capability bit.
It might seem somewhat limiting to only consider the possibility of 15
different future bundling methods, but it is my opinion that the careful
use of a 'Sub-Type' byte in the packet header can allow for the variations
on a single theme, and that proposals for new formats should be evaluated
by the FTSC to determine whether sufficient benefit can be realized in
the implementation of the given format, prior to assigning a new type
code.
Mailers
-------
It is quite clear to me that should this concept take hold, that the
logical place to store node capability data is in the local nodelist
database, or an index-associated data file. As above, it is necessary
to generate Type-2 packets for whatever purpose, unless it is known
by prior association, that the far mailer can accept other types of
packets. It is also quite reasonable to assume that a nodelist flag
could be assigned to advertise the CW for a given node, which the
native mailer nodelist compiler could then immediately determine the
preferred bundling method for any given node in FidoNet.
Another possibility would be to pass a capability advertisement in the
extensible portion of a handshake protocol, which may or may not already
exist in FidoNet.
The approach suggested previously in this document suggests the use of
a text configuration file, but it is quite obvious that many benefits
can be realized through the use of the nodelist, including the use of
additional flags to indicate the preferred compression method, etc.
Summary
-------
This document has been created in an attempt to define a method to allow
the future expansion and enhancement of FidoNet technology mail processors
and mailers, and in a way that is the least disruptive to existing mail
operations. The intent is to provide for an environment that is as open,
and extensible as possible.
The mechanism described should allow many different types of processors
(FTSC-registered) to exist in the network at once, and to provide an
environment which is designed to operate at it's maximum efficiency
wherever possible or practical.
Revision 2 of this document was produced to implement suggestions made
primarily by Jan Vroonhof, who suggested the use of the CW Validation
Copy. Jan presented this idea in his FSC-0048, along with other concepts
relating to the correct indentification and handling of zone and point
addressing. This document sanctions the improvements to the CW as
recommended, but does not address or support the other extensions
recommended in FSC-0048.
Thanks
------
To Ward Christensen, creator of XModem and BYE.
Tom Jennings, who started this whole mess.
Joaquim Homrighausen, for lots of good ideas, and motivation. Here's
another Lamborghini to work on.
Wynn Wagner, Oliver McDonald, Roeland Meyer, Andrew Farmer, Claude
Warren, Jan Vroonhof, Bob Hartman, and Vince Perriello, who all
contributed in some way to the creation of this document, mostly
through their messages in NET_DEV.
Type-2 Packet Format (proposed, but currently in use)
-----------------------------------------------------
Field Ofs Siz Type Description Expected value(s)
------- --- --- ---- -------------------------- -----------------
OrgNode 0x0 2 Word Origination node address 0-65535
DstNode 2 2 Word Destination node address 1-65535
Year 4 2 Int Year packet generated 19??-2???
Month 6 2 Int Month " " 0-11 (0=Jan)
Day 8 2 Int Day " " 1-31
Hour A 2 Int Hour " " 0-23
Min C 2 Int Minute " " 0-59
Sec E 2 Int Second " " 0-59
Baud 10 2 Int Baud Rate (not in use) ????
PktVer 12 2 Int Packet Version Always 2
OrgNet 14 2 Word Origination net address 1-65535
DstNet 16 2 Word Destination net address 1-65535
PrdCodL 18 1 Byte FTSC Product Code (lo) 1-255
* PVMajor 19 1 Byte FTSC Product Rev (major) 1-255
Password 1A 8 Char Packet password A-Z,0-9
* QOrgZone 22 2 Int Orig Zone (ZMailQ,QMail) 1-65535
* QDstZone 24 2 Int Dest Zone (ZMailQ,QMail) 1-65535
Filler 26 2 Byte Spare Change ?
| * CapValid 28 2 Word CW Byte-Swapped Valid Copy BitField
* PrdCodH 2A 1 Byte FTSC Product Code (hi) 1-255
* PVMinor 2B 1 Byte FTSC Product Rev (minor) 1-255
* CapWord 2C 2 Word Capability Word BitField
* OrigZone 2E 2 Int Origination Zone 1-65535
* DestZone 30 2 Int Destination Zone 1-65535
* OrigPoint 32 2 Int Origination Point 1-65535
* DestPoint 34 2 Int Destination Point 1-65535
* ProdData 36 4 Long Product-specific data Whatever
PktTerm 3A 2 Word Packet terminator 0000
* - extensions to FTS-0001
Ofs, Siz are in hex, other values are decimal.
Zone/Point Aware Mail Processors (probably a partial list)
----------------------------------------------------------
Prod
Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
---- ----------- ------------- ------------- --------------
0x0C FrontDoor Reads/Updates Yes Yes
0x1A DBridge ????? Yes Yes
0x45 XRS Reads/Updates Yes Yes
0x29 QMail Yes ????? Not point-aware
0x35 ZMailQ Yes ????? Not point-aware
0x3F TosScan Reads/Updates Yes Yes
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

227
html/ftsc/fsc-0046.html Executable file
View File

@ -0,0 +1,227 @@
<HTML>
<HEAD>
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0046
Version: 005
Date: 30-Aug-94
A Product Idenfifier for FidoNet Message Handlers
Joaquim Homrighausen
2:270/17@fidonet or joho@abs.lu
August 30, 1994
Copyright 1994 Joaquim Homrighausen; All rights reserved.
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
This document should serve as a guide for the product identfier, PID
hereafter, format for FidoNet message handlers. The purpose behind PIDs
is related to my attempt to remove the requirement of Origin lines in
conference mail messages.
While I fully understand that this won't happen in all conferences, I
would like to provide the facility to those who can use it (i.e. for
conferences where all the participants are using software that supports
messages without origin lines).
Another use for PIDs is to minimize the excessive amount of information
some programs put on the tear lines which increases overall
transportation cost and time of conference mail.
PID
A PID replaces the program identifier often seen on the tear line of
conference mail messages and is hidden behind a ^A (ASCII SOH, 01h).
This also allows for better tracking of software causing problems in
conferences.
: Only one PID per message is allowed and should only be added by the
: program that creates the message. I.e. programs passing the message on
: to someone else may not add additional PIDs. If a PID is added, no
: program information may be present after the tear line.
A PID also offers the ability to add serial numbers to identify a
specific copy of a program as being the source of a message with little
or no effort.
Format
^APID: <pID> <version>[ <serial#>]<CR>
Sample
^APID: FM 2.11.b<CR>
Would identify FrontDoor's editor, beta version 2.11 and replace:
--- FM 2.11 (beta)
Fields
pID The ID of the product responsible for creating the message.
This should be kept as short as possible. The maximum
length for this field is 10 characters.
version The version of the product including any alpha, beta, or
gamma status. Only the relevant part of the version should
be included. I.e. 1.00 should be expressed as 1, 1.10 as
1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
be expressed by appending a / or . followed by a, b, or g
and optionally a revision indicator, such as a1, b2, etc.
The maximum length for this field is 10 characters.
serial# The serial number of the product, omitted if irrelevant
or zero. The maximum length for this field is ten (10)
characters.
TID
TIDs or "Tosser IDs" started to appear shortly after the first
revision of this document was released. They are added by Conference
Mail ("EchoMail") processors when a message is exported from the
local message base and injected into the network distribution scope
for a conference.
When a Conference Mail processor adds a TID to a message, it may not
add a PID. An existing TID should, however, be replaced. TIDs follow
the same format used for PIDs, as explained above.
List of products
The accompanying file, PIDLIST.TXT, is a list of products known to
support the PID proposal. Software authors are encouraged to inform
the author of this document of changes and additions to this list.
--- end of file "fsc-0046.005" ---
</PRE>
<HR>
<PRE>
Document: PIDLIST.TXT (FSC-0046)
Date: 30-Aug-94
A list of used product idenfifiers
Joaquim Homrighausen
2:270/17@fidonet or joho@abs.lu
Product identifiers
Product Version ID Author
-----------------------------------------------------------------------------
!!MessageBase 1.6+ !!MB Holger Lembke 2:240/500.20
Alert 2.1+ Alert Richard Kail 2:310/25.2
ANet 921213+ ANet Thomas Ekstroem 2:201/411
ArcMail RISC OS 1.04+ AM Philip Blundell 2:440/34.4
Artmail Mailer System 1.00+ ART Klaus Landefeld 2:247/402
Auto Message Taker 1.00+ AMT Patrik Torstensson n/a
AVALON 3.10+ AVALON Stephan Slabihoud 2:2401/103.6
CrossPoint 2.10+ XP Peter Mandrella 2:243/97.80
EchoSprint 1.02+ ES Ben Elliston 3:620/262
Enhanced Mail MAnager .01+ EMMA Johan Zwiekhorst 2:292/118
Enhanced Message EDitor .02+ EMED Johan Zwiekhorst 2:292/118
EZMail .67+ EZMail Torben Paving 2:234/41
F_POINT 1.1+ F_POINT Florian Rupp 2:248/107.2
FastEcho 1.21a+ FastEcho Tobias Burchhardt 2:245/39
FileScan 1.5+ FileScan Matthias Duesterhoeft 2:241/4513
Freqit (Windows) 1.0+ FIW Marvin Hart 1:106/462
Freqit (MS-DOS) 1.0+ FID Marvin Hart 1:106/462
FrontDoor APX 1.00+ FDAPX Joaquim Homrighausen 2:270/17
FrontDoor (Editor) 2.00+ FM Joaquim Homrighausen 2:270/17
FrontDoor (Mailer) 2.00+ FD Joaquim Homrighausen 2:270/17
FrontEnd FX 1.00+ FEFX Eric Theriault 1:132/220
GEcho 1.00+ GE Gerard van der Land 2:2802/110
GeeMail 2.00+ GeeMail Lech Szychowski 2:480/4.7
HbToSca 1.00+ HTS Jani Laatikainen 2:220/150
HyperBBS 2.00+ HyperBBS Jani Laatikainen 2:220/150
JetMail 1.00+ JetMail Daniel Roesen 2:243/93.8
LazyBBS .5+ LazyBBS Franck Arnaud 2:320/100
Mail FX 1.00+ MFX Eric Theriault 1:132/220
MsgTrack 3.20+ MT Andrew Farmer 1:243/1
NewsFlash 1.01+ NwF Chris Lueders 2:2402/330
NodeDiff Processor 3.00+ NDP Serge Vikulov 2:5080/5
Notify 2.1 Notify Frank Schuhardt 2:247/160
OFFFax 3.03 OFFFax Frank Schuhardt 2:247/160
Pobble 0.15+ Pobble Josh Parsons 3:771/340
QBBed 2.64+ qbbed Werner Berghofer 2:310/90.100
RemoteAccess 1.10+ RA Andrew Milner 2:270/18
RASS 1.00+ RASS Yossi Gottlieb 2:403/139.75
SendFile 1.00+ SendFile Mike Shoyher 2:5020/17.3
Synchronet 1.00+ SYNC Rob Swindell 1:103/705
TB-Edit 1.10+ TB-Edit Arjen Lentz 2:283/512
TB-Mailer 1.97+ TB-Mailer Arjen Lentz 2:283/512
TB-Point .10+ TB-Point Arjen Lentz 2:283/512
TechBBS 1.00 TECHBBS Marcel Tegelaar 2:281/409
TechMail 1.00 TECHMAIL Raymond van der Holst 2:281/409.2
TosScan 1.10+ TosScan Joaquim Homrighausen 2:270/17
TPCS .89b TPCS Krister Hansson-Renaud 2:201/201.7
Mikael Kjellstrom 2:201/201.10
XRobot 3.00+ XRobot Joaquim Homrighausen 2:270/17
Xrs Alternative Packer 1.04+ XAP Jeroen Smulders 2:512/1.8
ZeroToss 1.00 ZeroToss Jeff Masud 1:103/115
-----------------------------------------------------------------------------
Product identifier registration
Simply fill in the required information and send this form to the author of
this document via private netmail.
Product: _________________________________________
Version: __________
PID info: _________________________________________
Author: _________________________________________
Address: ___________________________ (eMail address)
--- end of file "pidlist.txt" ---
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

417
html/ftsc/fsc-0048.html Executable file
View File

@ -0,0 +1,417 @@
<HTML>
<HEAD>
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0048
Version: 002
Date: 21-Oct-90
A Proposed Type-2 Packet Extension
Jan Vroonhof
2:281/1.12@fidonet
Oct 21, 1990
Status of this document
=======================
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
=======
The final goal of this document is to become a widely used
standardised extension to FTS-0001, like FTS-0006, 0007 and
0008 are, and provide an elegant way to switch to a new
bundling method without requiring major effort or breaking
anything.
Prologue
========
The main thing that needs stressing is that the additions
covered by this document are FULLY (I repeat FULLY) BACKWARDS
COMPATIBLE with FTS-0001 (and other existing standards and
practices in FidoNet and WhatEverOtherNets that I know of).
When I say "backwards compatible" I mean that problems it would
create already exist in the current FTS-0001 system (e.g.
zone conflicts when dealing with a non compliant system). In
short it only corrects some flaws in FTS-0001 WITHOUT
generating new ones.
In this document I have tried to stay as much as possible on
the paths of existing practices. Therefore I think
implementation of the additions it proposes will not be too
hard.
! Prologue to revision 2
! ======================
! Revision 2 of this document reserves a bit in the
! CapabilityWord for one bundle type already in use outside of
! FidoNet, RFC-822. A small change was made to the "receiving"
! flowchart in order to ensure compatibility with FSC-0039.004.
! In the process a lot of errors and omissions in the spelling,
! credits etc. were corrected.
===============
! All references in the following to FSC-0039 are to Revision 1
! of that document.
My thoughts on FSC-0039 and FTS-0001 rev 12
===========================================
First, revision 12 of FTS-0001 introduced the term "(some
impls)" to indicate that some implementations used their own
! extensions to FTS-0001 (Note that in later revisions this was
! changed to "optional"). The problem is that this info cannot be
relied upon, because there is no way to actually validate the
data. One can only check whether the values of these fields are
in the range of valid values and hope for the best.
Second, FSC-0039 introduced the idea of having a bitfield
(called the Capability Word) indicating whether extension data
was valid. Through the Capability Word, it also made it
possible to indicate the ability to support other, non type 2,
packets, thus allowing for flexible migration towards type 3.
It also documented the addressing extensions used by various
programs.
However, FSC-0039 has two flaws:
1. One cannot be sure the bitfield is zero because other
implementations might use this field for their own purposes.
Therefore this document includes a second validation copy
for the Capability Word (CW hereafter). This copy allows the
FSC-xxxx compliant software to validate the CW by comparing
the two. The chance of some junk portraying itself as a CW
is significantly reduced by this.
! Please note that the validation copy is byte swapped
! compared to the normal capability word. While this started
! out as a typo, I decided to leave it in as it introduces
! some extra safety, without requiring much extra code effort.
! In later revisions of FSC-0039, Mark adopted this idea of a
! validation copy too and eliminated the problem.
2. Although FSC-0039 provides a way to make packet headers 4D
it is not backwards compatible. It cannot be used in FTS-
0001 sessions to unknown systems, making FidoNet still not
totally 4D capable. Although it implements fields for zone
and point number, an FTS-0001 compliant application is not
required to look at these fields. When a point mails using
these fields to implement its 4D address, a system only
looking at the net/node info, as is required by FTS-0001,
still sees it as a boss node, causing the obvious problems.
This document provides a way for transparent point handling,
using a technique already exploited by many mailers
internally. It will allow this document to be implemented
and used by mailers not supporting it. At the same time the
danger that a point is seen as the boss node is eliminated.
It does NOT provide full inter-zone backwards compatibility,
but that is not needed as badly, as problems are not yet too
great. Any measures to ensure backwards compatibility in
this area might harm communication with non-supporting
programs, when the old system could handle the situation.
Packet Header
=============
The "|" character is used to indicate extensions documented in
FTS-0001 revision 12, the ":" character indicates those
documented here and in FSC-0039.
Offset
dec hex
.-----------------------------------------------------.
0 0 | origNode (low order) | origNode (high order) |
+--------------------------+--------------------------+
2 2 | destNode (low order) | destNode (high order) |
+--------------------------+--------------------------+
4 4 | year (low order) | year (high order) |
+--------------------------+--------------------------+
6 6 | month (low order) | month (high order) |
+--------------------------+--------------------------+
8 8 | day (low order) | day (high order) |
+--------------------------+--------------------------+
10 A | hour (low order) | hour (high order) |
+--------------------------+--------------------------+
12 C | minute (low order) | minute (high order) |
+--------------------------+--------------------------+
14 E | second (low order) | second (high order) |
+--------------------------+--------------------------+
16 10 | baud (low order) | baud (high order) |
+--------------------------+--------------------------+
18 12 | 0 | 2 | 0 | 0 |
+--------------------------+--------------------------+
20 14 | origNet (low order) | origNet (high order) |
: | Set to -1 if from point |
+--------------------------+--------------------------+
22 16 | destNet (low order) | destNet (high order) |
+--------------------------+--------------------------+
| 24 18 | ProductCode (low order) | Revision (major) |
| +--------------------------+--------------------------+
| 26 1A | password |
| | 8 bytes, null padded |
| +--------------------------+--------------------------+
|: 34 22 | origZone (low order) | origZone (high order) | }
| +--------------------------+--------------------------+ } As in
|: 36 24 | destZone (low order) | destZone (high order) | } QMail
: +--------------------------+--------------------------+
: 38 26 | AuxNet (low order) | AuxNet (high order) |
: +--------------------------+--------------------------+
: 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) |
: +--------------------------+--------------------------+
: 42 2A | ProductCode (high order) | Revision (minor) |
: +--------------------------+--------------------------+
: 44 2C | CapabilWord (low order) | CapabilWord (high order) |
: +--------------------------+--------------------------+
: 46 2E | origZone (low order) | origZone (high order) | }
: +--------------------------+--------------------------+ } As in
: 48 30 | destZone (low order) | destZone (high order) | } FD etc
: +--------------------------+--------------------------+
: 50 32 | origPoint (low order) | origPoint (high order) | }
: +--------------------------+--------------------------+ } As in
: 52 34 | destPoint (low order) | destPoint (high order) | } FD etc
: +--------------------------+--------------------------+
: 54 46 | Product Specific Data |
: + +
: | 4 Bytes |
+--------------------------+--------------------------+
58 3A | zero or more |
~ packed ~
| messages |
+--------------------------+--------------------------+
| 0 | 0 | 0 | 0 |
'-----------------------------------------------------'
Packet = PacketHeader { PakdMessage } 00H 00H
PacketHeader = origNode (* of packet, not of messages in packet *)
destNode (* of packet, not of messages in packet *)
year (* of packet creation, e.g. 1986 *)
month (* of packet creation, 0-11 for Jan-Dec *)
day (* of packet creation, 1-31 *)
hour (* of packet creation, 0-23 *)
minute (* of packet creation, 0-59 *)
second (* of packet creation, 0-59 *)
baud (* max baud rate of orig and dest *)
PacketType (* old type-1 packets now obsolete *)
origNet (* of packet, not of messages in packet
set to -1 if orig=point *)
destNet (* of packet, not of messages in packet *)
+ productCode Lo (* 0 for Fido, write to FTSC for others *)
|+ serialNo Maj (* binary serial number (otherwise null) *)
| password (* session pasword (otherwise null) *)
| origZone (* zone of pkt sender (otherwise null) *)
| destZone (* zone of pkt receiver (otherwise null) *)
| auxNet (* contains Orignet if Origin is a point *)
+! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *)
+ ProductCode Hi
+ revision Minor
+ origZone (* zone of pkt sender (otherwise null) *)
+ destZone (* zone of pkt receiver (otherwise null) *)
+ ProdData (* Product specific filler *)
When the two copies of the CW match they can be asumed to be
valid and used.
Stone-Aged: Old FTS-0001
Type-2+ : Old FTS-0001 plus changes indicated by "|" and ":"
are valid
A Type-N Bundle will always advertise its capabilities in the
CW regardless of the type being sent. As shown in the example
below, the CW allows Type-N processors to automatically track
the capability of your system. Again, in cases where a stone-
age processor is being used, this field will be ignored, and in
the unusual event that it is not ignored, and is somehow
harmful to the far system, the Type-N processor can be
configured to send a CW of 0.
The format of the Capability Word is designed to support up to
15 future bundle types, and is bit-mapped to facilitate the
easy determination of the maximum common level supported
between two nodes:
msb Capability Word lsb
Node Supports ------------FTSC Type Supported **)------------
U 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2+
2+,3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
2+,3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
2+ (this Doc) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Stone Age 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
! ^-- "U" Indicates nodes able to process RFC-822
! bundles.
** - In the example bit definitions only type 2,
and the Stone-Age type, are defined now.
The rest are to be concidered "reserved by
FTSC".
The receiving Type-N bundler would AND the two words, obtaining
a word expressing the Types which are common to both the
receiving and the sending system. The most significant Type
will be used for future sessions, by default. Please note that
this assumes that new bundling Types will be increasingly more
efficient or in some way more beneficial. Because this may not
always be the case, there should be a method provided to
override the automatic upgrade, as illustrated above, should
this ever happen.
! N.B. The one bit left over (Msb) is now used as indicator for
! RFC-822 type bundles. For info on RFC-822 please check out
! the relevant documents themselves.
! For a more explanatory text on using the CW to its full
! potential, refer to the FSC-0039 text by Mark Howard.
! Mark also gives some more rationale for the origional idea
! of the CW.
Generating Type-2+ bundles
==========================
Do we have a CW Does CW indicate
stored for dest? YES ----> higher packets YES ---> Generate higher
NO we support? packet
| NO
\|/ |
+-----<----------------------+
|
Fill header with all info
|
\|/
|
Are we sending from a point? (origPoint != 0) YES --+
| |
NO |
| \|/
| set AuxNet = OrigNet
\|/ set OrigNet = -1
| |
+-----<----------------------------------------+
|
Add Messages
|
Terminate packet
|
Send packet
Receiving Type-2+ bundles
=========================
Receive Packet
|
Packettype = 2 NO -------------> Process Type-Other
YES
|
|
CWcopies match NO --------+------> Treat as normal Stone-Age packet
YES | |
| | |
Store CW /|\ |
| | /|\
CW is 0 YES --------------+ |
NO |
| |
| |
CW indicates support for 2+ NO --+
YES
|
|
! OrigPoint is not 0 and OrigNet = -1 YES -------+
NO |
| \|/
! \|/ Set OrigNet is AuxNet
| |
+------<-----------------------------------+
|
Process using added info
Credits
=======
To Mark Howard, for introducing the idea of a CW in his FSC-
0039 document and quite rightly pointing out one big omision
in revision 1 of this document.
To Rick Moore, for doing a good job in processing all these
revisions by Mark and myself, and for his work for the FTSC in
general.
To Joaquim Homrighausen, for his contributions to FidoNet
software in general, and especially for his time devoted to
reading, discussing and implementing the ideas Mark and I
introduced.
To Andre van de Wijdeven, for producing and letting me beta
test his TS-MM software, which in my opinion is the best point
software around. (I'm not saying available, because it isn't
:-()
To john lots, for shipping this stuff to the US.
To Jon Webb, for doing a much needed grammar and spelling
check.
To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff,
aXel Horst, Arjen van Loon, jim nutt, Odinn Sorensen, David
Nugent, Peter Janssens and many others, for making FidoNet
what it is now, for me and for everybody.
Epilog
======
So this it, now it's up to you to decide whether or not to
implement it. A small change was made in the receivers
flowchart and a small incompatibility with the later revisions
of FSC-0039 was removed. That will ensure that FSC-0048 and
FSC-0039 mailers can happily talk to each other....
The best way to implement this would be to always support FSC-
0048 on inbound trafic and generate FSC-0048 on outbound by
default. A switch on a per-node basis will force your software
to be FSC-0039 or even FSC-0001 only, and you will cover all
bases.
This can be done easily, as FSC-0048 is a superset of FSC-0039
(The -1 thing on points being the difference) which in turn is
a superset of FTS-0001 (CW). I'd be glad to get some feedback.
You can put it in NET_DEV or netmail me.
Jan Vroonhof (2:281/1.12@fidonet)
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

103
html/ftsc/fsc-0049.html Executable file
View File

@ -0,0 +1,103 @@
<HTML>
<HEAD>
<TITLE>A Proposal for Passing Domain Information During an FST-0006 Session.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0049
Version: 001
Date: 03-Jul-90
A Proposal for
Passing Domain Information
During an FTS-0006 Session
by
Bob Hartman
1:104/501@fidonet.org
July 3, 1990
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
FSC-0045 proposes a method for sending five dimensional FidoNet addresses
(ie, zone:net/node.point@domain) via the type 2 packet header. This
document describes a proposed method for sending the same five dimensional
address in the Hello packet of an FTS-0006 session, with the additional
advantage of being able to utilize the full Internet recognized domain name
for various Fidonet technology networks. This proposal, combined with
FSC-0045 will help to solve one of FidoNet's most pressing problems: How to
recognize alternative networks without the need of some centralized
management looking at all of them and what they are doing with Zone numbers,
etc. Like FSC-0045, this proposal remains backwards compatible with what it
is replacing.
Currently FTS-0006 has provisions for zone, net, node, and point information
to be passed in the Hello packet. To extend this to allow the domain name
to be passed, an extra capability bit is used. This bit corresponds to the
0x4000 bit, and will be called the DO_DOMAIN bit. If this bit is set, it
means that the sender is domain aware, and has enclosed his domain in the
Hello packet. The domain is stored in the system name field, after the null
that terminates the real system name. The system name field is a maximum of
60 characters, so the sender must make the real system name, a null, the
domain name, and another null byte fit within the 60 bytes. The domain will
start at the byte immediately after the first null byte. The domain is
arbitrary length and should correspond to the Internet assigned domain name.
This is NOT the same as the FSC-0045 domain, and therefore there needs to be
a mapping between real Internet domains, and the FSC-0045 style domain name,
if FSC-0045 is accepted by the FTSC as a standard for use by all mailers.
This mapping is normally straightforward (for example, Internet fidonet.org
would correspond to FSC-0045 domain FidoNet). Since most alternative nets
do not have a registered Internet domain, the naming convention should be
"known by" domain (ie, FSC-0045 domain name) followed by .ftn (for FidoNet
Technology Network). So, the FSC-0045 domain "Alternet" would be converted
to alternet.ftn under this proposal. This allows domains which are not
normally FidoNet aware to use FTS-0006 to talk to FidoNet technology mail
programs. For example, a mailer located at Camex in Manchester, NH might
send it's mail as 'man.camex.com' during an FTS-0006 session. When parsing
the domain name, the parsing should try to match the domain from right to
left (Internet naming is hierarchical from right to left), so that if a
mailer knew about man.camex.com, that could also match something of the form
super.machine.silly.name.man.camex.com. The domain name should be case
INSENSITIVE, and the FSC-0045 abbreviation of it should be unique within the
first 8 characters, and also should not include any periods ('.') or at-signs
('@') since those characters are significant in the Internet domain naming
scheme.
In order for this proposal to be adopted, the FTSC would have to assign the
DO_DOMAIN bit, and have it documented in FTS-0006. This method is fully
backwards compatible, since a domain aware mailer could send the domain
information, and if the other end was not domain aware, it would ignore it.
If the other end was domain aware, it would be able to extract the domain
information easily and would then have a full five dimensional address
available for the sender. This proposal remains fully backward compatible
with the current uses of all FTS-0006 fields, and should not affect operation
of any mailer that has used reserved bytes in the Hello packet.
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

98
html/ftsc/fsc-0050.html Executable file
View File

@ -0,0 +1,98 @@
<HTML>
<HEAD>
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0050
Version: 001
Date: 14-Jul-90
A Character Set Identifier For FidoNet Message Editors
Draft I
Thomas Sundblom
2:201/114@fidonet
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
This document should serve as a guide for the character set
identifier, CHARSET hereafter, format for FidoNet message Editors.
The purpose behind CHARSET is related to my attempt to make it
easier for each reader of a FidoNet message to identify the
characters used in the messages.
Since FidoNet messages aren't restricted to use any special character
sets in the messages, there will be differences between computer
kinds and special country dependent characters. To avoid confusion
in such cases, I'm hereby introducing the CHARSET kludge.
There is no need that each FidoNet Message reader should be able
to understand every possible character set. If the reader can't
handle the special character set found in a message, then it should
use a default character set (as most readers do today).
Format
^aCHARSET: <Character set identifier>
Sample
^aCHARSET: ISO-11
Would identify that the message is written using the ISO-11
character set, which relates to the character set mainly used
in Sweden.
Supported character sets
No special character set is specified, but it is recomended to
use the ISO numbering of the different character sets. Where no
ISO number is available, an easy to understand code should by used.
Character set identifier examples
ISO-6 Relates to plain ASCII 7 bit character set.
ISO-11 Swedish character set, 7 bit.
ISO-21 Germany character set, 7 bit.
ISO-69 French character set, 7 bit.
Other character set identifiers could be
PC-8 IBM PC complete character set.
ATARI ATARI ST complete character set
AMIGA AMIGA complete character set
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

187
html/ftsc/fsc-0053.html Executable file
View File

@ -0,0 +1,187 @@
<HTML>
<HEAD>
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0053
Version: 002
Date: 08-Dec-92
Specifications for the ^aFLAGS field
Joaquim H. Homrighausen
2:270/17@fidonet or joho@ae.lu
December 8, 1992
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Purpose
To explain and document the existing usage of the ^aFLAGS field used
by many software packages, including FrontDoor, TosScan, and
D'Bridge. And to inform software authors of its proper usage.
Prologue
One of the problems with the FTS-1 (stored) message format is its
limitations in regards to message attributes. Several bits are used
(reserved) by SEAdog, another by several packers and editors - even
though most mailer authors don't support them, they remain. One
reason would be backward compatibility with older software.
Unfortunately, this presents a problem for software authors that
would like to pass extended message attributes for use and handling
by other software.
Some software packages have been using an alternate method called
"FLAGS" which is 7-bit ASCII placed behind <SOH>FLAGS somewhere near
the beginning of a message. The various flags will now be described.
Flags
The FLAGS string should be placed somewhere near the beginning of
the message text, and is preceeded by a <SOH> (^a) character. There
is no need to support all or any of the below mentioned flags.
If flags are stripped when a message passes through a system, all
relevant and correct FTS-1 status bits should be updated to indicate
the original contents of the FLAGS field.
Flag Brief Long description
--------------------------------------------------------------------
PVT Private Indicates that the message may only be read
by its addressee and author.
HLD Hold Message should be held for pickup by its
destination system.
CRA Crash High-priority mail.
K/S Kill/Sent Remove message after it has been success-
fully sent.
SNT Sent Message has been successfully sent (used
for message without Kill/Sent status).
RCV Received Message has been read by its addressee.
A/S Archive/Sent Place message in "sent mail" archival
system after it has been successfully sent.
DIR Direct Message must be sent directly to its
destination and may not be routed.
ZON Zonegate Send message through zonegate (if
possible).
HUB Hub/Host-route Host- or Hub-route message (as
appropriate).
FIL File attach Message has one or more files attached to
it.
FRQ File request Message has one or more file requests in
subject field.
IMM Immediate NOW!-priority mail. Send at first
opportunity, override any transmission
restrictions enforced by events, costs, or
qualification.
XMA Xmail Message has alternate form of compressed
mail attached.
KFS Kill file Remove attached file(s) after they have
been successfully sent. Only valid for file
attach message.
TFS Truncate file Truncate attached file(s) to zero length
after they have been successfully sent.
Only valid for file attach message.
Primarily used by Conference Mail
processors.
LOK Lock Prevent message from being processed.
This includes sending, deleting,
purging, and editing.
RRQ Receipt REQ When the mailer/packer at the message's
final destination unpacks the message, it's
asked to generate a receipt to the author
of the message that indicates that the
message arrived at its final destination.
CFM Confirm REQ When message is read by its addressee, a
Confirmation Receipt should be generated to
the author of the message.
HIR HiRes FAX: Hi-Resolution image.
COV CoverLetter FAX: Cover sheet.
SIG Signature FAX: Signature.
LET LetterHead FAX: LetterHead.
| FAX Fax image The filename specified in the message's
| subject field contains a fax document that
| should be viewed using software capable of
| doing so.
| FPU Force pickup Treated as a message with an IMM flag. This
| instructs the mailer to keep calling the
| destination system, if the connection is
| aborted for some reason, until a valid "End
| of files" signal is received (i.e. no more
| files remain to pick up).
Notes
Xmail is related to the ARCmail 0.60 standard as adopted by the FTSC.
The exception is that any type of compression method may be used and
the naming convention isn't necessarily limited to that of the
ARCmail 0.60 standard.
Epilogue
Feedback would be appreciated and can be sent to me at the addresses
specified on the title page. Please send feedback via netmail.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

1078
html/ftsc/fsc-0056.html Executable file
View File

File diff suppressed because it is too large Load Diff

533
html/ftsc/fsc-0057.html Executable file
View File

@ -0,0 +1,533 @@
<HTML>
<HEAD>
<TITLE>Conference Managaers - Specifications for Requests.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0057
Version: 003
Date: 07-Dec-92
Conference Managers - Specifications for Requests
December 7, 1992
Fabiano Fabris Joaquim H. Homrighausen
2:285/304.100@fidonet 2:270/17@fidonet
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community, and
requests discussion and suggestions for improvements. Revision 3
presents several additions and enhancements over the previous revision.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
1 Purpose
This document will explore the methods implemented by various
conference managers which process requests (in net mail form)
for changes to the conference mail links on the system on which
they are in use.
Until now, it would appear that no real standard exists, so most
software authors have either tried to emulate another program, or
to create a new method of their own, or both.
Here, an attempt will be made to define a standard, one which tries
to maintain compatibility with methods already in use, while also
extending them to provide new functions.
2 Conventions
The names of the commands described in the following paragraphs are
given in upper case, for legibility. However, a conference manager
should be able to interpret them even if they are given in lower
or mixed case.
Similarly, conference names, or tags, are given in upper case, but
the conference manager should be able to handle them even if typed
in lower or mixed case.
Optional information is enclosed with square brackets, while
variable information is enclosed with angle brackets. For example:
+CONF [,R=<n>]
indicates that the section within square brackets is optional, and
if supplied, requires a parameter after the equals sign.
Some conference managers may allow commands to be abbreviated to the
shortest non-ambiguous string. For example, %LIST might be reduced
to %L.
3 Format of the request
A request to a conference manager is generally made in a net mail
message containing specific information in some of the fields. In
particular, the addressee is the name of the conference manager
itself, and the subject of the message is a password assigned by
the sysop of the system running the program.
For example:
From: John Doe, on 2:123/56
To: Program, on 2:234/0
Subject: password
Here the first problem is encountered. Each of the existing programs
recognizes a different addressee. For this reason it is proposed
that all such programs recognize requests made to a single,
"standard" addressee, besides any other they may wish to implement.
The term "ConfMgr" has been arbitrarily chosen, and should be used
by those programs which adhere fully to all the standards proposed
in this document.
The text of the message itself contains the request proper, and is
the subject of the following paragraphs.
4 Linking and Unlinking of conferences.
The current methods for requesting that a conference be linked are
basically two:
+CONFNAME
CONFNAME
For reasons of uniformity, it is proposed that all conference
manager programs recognize the first method.
Requests that a conference be unlinked are given by:
-CONFNAME
It might be interesting to implement some form of pattern matching,
similar to the unix shell. The following basic wildcards should be
considered:
* matches zero or more characters
? matches any one (not zero) character
Since the requests are processed top-down, a request of the form
+CONFNAME
-*
would be redundant, since the ConfMgr would link CONFNAME from the
first line, and then immediately unlink it again because of the
second line, which requests that all linked conferenecs be unlinked.
It should also be possible to specify more than one conference tag
on the same line. For example:
+CONF1 CONF2 CONF3
would link the three conferences CONF1, CONF2 and CONF3.
5 Rescanning Conference Mail
Many conference managers currently allow a system to request that an
area be "rescanned". In other words, the system receiving the
request will export all mail in one or more areas to the requesting
system.
This may be accomplished by specifying the %RESCAN command in the
body of the request. This will force the ConfMgr to generate a scan
request for those areas which the remote system requested with the
message containing the %RESCAN command.
Rescans of a single area, newly linked, could be requested as
follows:
+CONFNAME, R[=<n>]
where 'n' is the number of messages in that area to be rescanned.
(The space following the comma is optional, but allowed.)
Rescanning has one serious drawback: dupes! It is very possible for
the requesting system to have already set up the area with several
downlinks. Thus, when the rescanned mail is received, it could be
exported to other systems. In a tree-based topology, this is
harmless, but in circular topologies this would create dupes.
Thus, it is proposed that system receiving the rescan request add a
kludge to the messages, so that they can be recognized by the
requesting system and not re-exported.
The proposed kludge is:
^ARESCANNED <addr>
where <addr> is the network address, including domain, of the
system from which the mail was rescanned.
In alternative to a rescan, a sysop might request a "sample",
consisting of a series of messages contained in a text file. The
ConfMgr would export some or all messages from an area to a plain
ASCII text file, and send it along with the reply, to the requesting
system. A "sample" request would be made as follows:
+CONFNAME, S[=<n>]
where 'n' indicates how many messages should be sampled.
a) Updating Conferences
Update requests allow a sysop to rescan or "sample" an area
without having to first unlink from it, and then relink with the
rescan or "sample" parameter.
The format of this command is:
=CONFNAME, <param>[=<n>]
Thus a rescan request for the most recent 50 messages would be
specified as:
=CONFNAME, R=50
6 Information Requests
Requests for information have until now taken two forms. In one
case, they are given as switches after the password on the subject
line, while in the second they are given as "commands" within the
body of the message text. It is proposed that the second method be
chosen as standard, since it is considerably more flexible.
Below are listed the proposed commands:
%HELP Sends a (pre-defined) help text to the
requesting system, explaining how the
ConfMgr is to be used.
%LIST[,B] Lists the conferences currently available
to the requesting system, on the basis
of a method internal to the conference
manager itself. This list would flag the
areas which are already linked. The 'B'
modifier would generate the list in
binary format (see section 8e).
%BLIST Equivalent to %LIST,B above.
%QUERY Lists the conferences currently linked to
the requesting system.
%UNLINKED Lists the conferences which are available
to the requesting system, but not
currently linked. This is the logical
difference between a %LIST and a %QUERY.
7 Remote Maintenance
Besides these simple functions, it is becoming more and more
interesting to make handling of the conference mail flow even more
automatic. For this reason, for example, it might be useful to
allow another sysop control over your own system, adding and
removing conferences as need requires. Thus a hub or coordinator
could automatically have a new area added to their conference
lists, or discontinued ones removed.
Naturally, the ConfMgr must be able to distinguish which system has
the ability to make such changes, but that is beyond the scope of
this document.
It is proposed that a conference manager be able to automatically
add a new conference to the system's list if/when it is detected.
Thus no special commands would be required. The manager should be
able to determine a default list of down-links for the new area,
and also the "group" of systems which could then request it.
However, should it be desired to explicitly create a new conference
via remote, this could be done by including a line such as the
following in the message text:
&CONFNAME
In order to remote delete an area, the requesting sysop should
include a line like this in the body of the message text:
~CONFNAME
Thus, if the system has remote privileges, the conference would be
deleted (and optionally, all systems linked to the conference could
be informed of this fact).
Similarly, it would also be possible to allow a system to change the
tag of a conference. This would be accomplished by a line such as:
# OLD_NAME NEW_NAME
The ConfMgr should inform all downlinks of the change by sending a
net mail message.
It might also be desirable to allow a sysop to make changes on
behalf of another system. This could be done by inserting a special
command at the beginning of the request itself. For example:
From: John Doe, on 2:123/1
To: Program, on 2:987/65
Subject: password
Text:
%FROM: 2:234/56
+CONFNAME
The %FROM command would make the ConfMgr carry out the changes as if
the system 2:234/56 had requested them. The password should
nonetheless be the one assigned to 2:123/1.
8 Further Automation
In order to make the system more powerful, and to reduce the
necessity for human intervention, several extensions are feasible.
a) ARCmail Compression Method
One interesting application is the possibility of allowing a
remote system to change the compression program used to "pack"
mail bound for his system. This could be done with the following
command in the message to a ConfMgr:
%COMPRESS <method>
where <method> is one of the compression programs supported by
the system. Of course, the remote system should also be able to
determine which compression methods are available; this could be
done with
%COMPRESS ?
Requests for an unsupported compression method should also be
responded to with a list of those available.
From the practical point of view, only systems which pick up
their mail (as opposed to those to whom mail is sent) should be
allowed to change the compression method used. How this
distinction is achieved is beyond the scope of this document.
b) Passwords
A sysop should be able to change the password used to make
requests to a ConfMgr without requiring the intervention of the
other system's sysop. This could easily be done if the
conference manager implemented the following command:
%PWD <new_password>
The new password (case insensitive) would replace the current
one as of the next request.
c) Temporary Unlink
Should a system's sysop be absent for a prolonged period of time,
he might want to temporarily cut all conferences from his
uplink. This could be accomplished with the
%PAUSE
command. This would tell the ConfMgr to temporarily stop sending
conferences to that system. On his return, the sysop could
reactivate them all with the
%RESUME
command.
d) Forwarding Remote Requests
If a conference manager receives a remote request to delete an
area, it could very easily "forward" that request to all its
downlinks by producing a similar request. In that way, a single
request originating from, for example, a Region Coordinator,
would result in the conference being deleted from all systems
"below" him.
Similarly, remote requests for conference name changes could
also be passed on to downlinks.
e) Automatic Requests for Conferences
A conference manager should also be able to automatically request
an area from an uplink. This would become necessary if, for
example, it processed a request for an area not currently
available on the system. In this case, it would scan a series of
conference lists for the requested area, and if found, would
send a request for that area.
In order to be able to do this, the ConfMgr would need to have
one or more lists of conferences from the uplinks. These lists
could be produced on request by the ConfMgr itself. In order to
simplify matters, a binary format is proposed. (Note that these
are C-style structures, with everything which that implies.)
This binary file is called a Binary Conference List (BCL).
The file starts with a header, containing some basic system
information:
struct bcl_header {
char FingerPrint[4]; /* BCL<NUL> */
char ConfMgrName[31]; /* Name of "ConfMgr" */
char Origin[51]; /* Originating network addr */
long CreationTime; /* UNIX-timestamp when created */
long flags; /* Options, see below */
char Reserved[256]; /* Reserved data */
}
The currently defined flags for the header are:
BCLH_ISLIST 0x00000001L
File is complete list
BCLH_ISUPDATE 0x00000002L
File contains update/diff information
The BCL would then contain a series of entries having the
following format:
struct bcl {
int EntryLength; /* Length of entry data */
long flags1, flags2; /* Conference flags */
char *AreaTag; /* Area tag [51] */
char *Description; /* Description [51] */
char *Administrator; /* Administrator or contact [51] */
}
The flags currently defined are:
FLG1_READONLY 0x00000001L
Read only, software must not allow users to enter mail.
FLG1_PRIVATE 0x00000002L
Private attribute of messages is honored.
FLG1_FILECONF 0x00000004L
File conference.
FLG1_MAILCONF 0x00000008L
Mail conference.
FLG1_REMOVE 0x00000010L
Remove specified conference from list (otherwise add/upd).
Thus, instead of scanning an AREAS.BBS style list, the ConfMgr
would parse and use lists in the above format. Naturally, each
list would be in some way "attached" to a node number, and a
corresponding ConfMgr password.
Each system may only have one master file, called anything they
want. But when transmitted to other systems, this file must
always be named ????????.BCL.
The list would be generated in response to a
%LIST, B
command in the message text.
f) Receipts
It might be useful to have the ConfMgr generate a receipt to be
sent to another system, perhaps a co-sysop or a sysop point
node. This could be done with the command:
%RECEIPT <name>,<address>
embedded in the request message. For example:
%RECEIPT JoHo,2:270/17
9 Comments in the request
It should be possible for a sysop to insert a comment in the request
made to a conference manager. These comments, naturally, would be
destined to the sysop of the system, and not to the conference
manager itself. Such comments should be placed at the end of the
message, following a %NOTE command.
In all cases except the above, the request can be deleted by the
ConfMgr once processed, but messages containing comments should be
retained.
Note: the current method used is to supply comments after a tear-
line. This practice is somewhat "messy", but it might be wise to
support it until such time as all conference managers have
implemented the %NOTE command.
10 Summary
+CONFNAME[,R|S] Request to link to CONFNAME
-CONFNAME Request to unlink from CONFNAME
=CONFNAME,R|S Rescan or "sample" linked conference
&CONFNAME Request to create CONFNAME
~CONFNAME Request to delete CONFNAME
#OLD NEW Name change request
%LIST[,B] List available areas, flag linked
%QUERY Only list linked areas
%UNLINKED List available but unlinked areas
%HELP Send help text
%FROM <addr> Simulate request from another system
%RESCAN Rescan conferences linked in current request
%COMPRESS <method> Change compression method
%PWD <new_pwd> Change ConfMgr password
%PAUSE Suspend link
%RESUME Resume link
%RECEIPT <name>,<addr> Send copy of receipt to another system
%NOTE Introduces comment to the sysop
11 Final Note
This document is to be considered as a suggestion for software
developers to make their programs compatible with one another, so as
to make life easier for the average sysop when dealing with
conference managers.
Feedback would be appreciated and can be sent to us at the addresses
specified on the title page. Please send feedback via netmail only.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

1622
html/ftsc/fsc-0059.html Executable file
View File

File diff suppressed because it is too large Load Diff

363
html/ftsc/fsc-0062.html Executable file
View File

@ -0,0 +1,363 @@
<HTML>
<HEAD>
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0062
| Version: 003
| Date: April 14, 1996
| Author: David J. Thomas
A Proposed Nodelist flag indicating Online Times of a Node
David J. Thomas
2:442/600@fidonet.org
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Note
----
Changes in content between the previous edition of this document, and this
edition, are signified by bars (|) in the left margin, except where
otherwise specified. I have changed the format of the document slightly to
allow this. Where the format of the document has changed, but the actual
text has not, bars are not present.
Purpose
-------
There are currently several systems within FidoNet that offer file request
or mail holding capabilities but are not continuously online. The only time
during which these nodes can be contacted with reference to the nodelist is
currently the Zone Mail Hour of the zone to which the systems belong. In
theory, mailers can only use the zone mail hour(s) specified by the system
in question to contact these nodes, which does not provide for any method
of file requesting or calling for echomail that does not conflict with the
Policy requirement that no echomail or files be transferred during the zone
mail hour. This means that, in practice, if it is known that a particular
node is online for more time than ZMH alone, but less than 24 hours a day,
it is necessary to "kludge," or set this up as a special situation, in most
mailers whenever a node has to be contacted a number of times, whether
regularly or irregularly. The proposed flag would benefit the mailers in
such a way as to provide for them the online times that the node is usually
online for, thus cutting on the costs of calling a non-continuous mail
node, only to find that it is not available; and also, hopefully preventing
annoyance for a sysop whose mailer is being called whilst it is not online,
for example in the case of a voice/data shared line.
Compatibility
-------------
Since the current nodelist format is always being extended and nodelist
processors look only for the flags that they know about, there are no
expected compatibility problems with the suggestion outlined below.
Format of additional nodelist flag
----------------------------------
The proposed nodelist flag has the following form:
Txy
where x represents the startup time, and y the end time, in the following
format:
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
|Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time|
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| A |0000| | F |0500| | K |1000| | P |1500| | U |2000|
| a |0030| | f |0530| | k |1030| | p |1530| | u |2030|
| B |0100| | G |0600| | L |1100| | Q |1600| | V |2100|
| b |0130| | g |0630| | l |1130| | q |1630| | v |2130|
| C |0200| | H |0700| | M |1200| | R |1700| | W |2200|
| c |0230| | h |0730| | m |1230| | r |1730| | w |2230|
| D |0300| | I |0800| | N |1300| | S |1800| | X |2300|
| d |0330| | i |0830| | n |1330| | s |1830| | x |2330|
| E |0400| | J |0900| | O |1400| | T |1900| | | |
| e |0430| | j |0930| | o |1430| | t |1930| | | |
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| This flag is not intended to be a user flag. The flag is intended to provide
| information to computerised mailer processes, and is not easily read by
| human beings (although they can of course interpret the meaning of the
| flag); most mailers however do not attempt to interpret any information that
| is specified as a user flag, assuming that it is there for the benefit of
| human beings. Such mailers would not be able to make use of the information
| provided, which is the purpose of the flag.
| This flag is of course not specified in FTS-0005 at the time of writing, but
| this is not regarded by FidoNet as a problem because other flags in current
| use are not specified in FTS-0005.
The case of the letter could be relevant. Whereas the case is currently not
used by any flags in the document describing the current format of the
nodelist, there exists the potential for the case of a letter to have
relevant meaning. The case has to be correct for the CRC check calculation
to prove correct, and this would be a good use for the case of the letter.
If it is necessary to ignore the case, then the upper on-the-hour time
should be used, i.e. the time that is listed after the upper-case letter.
| These times are expressed in UTC so that the flag is useful for systems all
around the world, without the need for specific time zone information to be
included in the nodelist. They do not adjust with daylight saving time for a
similar reason. Note the section on daylight saving time for information
about handling adjustments without changing the flag; this is important.
Where necessary, the times can wrap around midnight, so for example, for a
| node that is online between the hours of 1800 and 0600 UTC, the flag TSG
would be a valid indication of this time.
This nodelist entry is not required by any node. It is supplementary to the
#01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
meaning is different. It has been suggested to me about the possibility of
an additional flag with the same meaning, but having a W as the first
letter, indicating that the node is also available for all hours during
weekends; however, I believe that the simple inclusion of the single flag
indicated above will solve most problems, as it does indicate a period for
non-CM nodes during which the node is available, which is all that is
really required.
Daylight saving time
--------------------
If a node changes online times with respect to UTC when daylight saving
time becomes effective (which would be the case with most part time nodes),
then this is to be taken into account when assigning this flag. An online
times flag assigned to a node should not be altered for the specific
purpose of adjusting due to daylight saving time, since large difference
files (NODEDIFF's) would result if every node was allowed to do this, e.g.
my node used to be online from 2300 to 0800 in local time, which in winter
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
| hour ahead of UTC, and the corresponding availability times of my node
| during the summer period were 2200 to 0700 UTC. Therefore my online times
flag would have indicated availability between the hours of 2300 and 0700
| UTC, the daily time period encompassing both times, so the flag would be
TXH.
Policy considerations
---------------------
This is a technical document. However, since the flag could make for an
increase in the size of difference files, the author feels that the
following guidelines should be adopted concerning the use of the flag.
The online times flag does not replace the requirement for exclusivity of
zone mail hour to be maintained. It is still annoying behaviour to have
this flag and be unavailable during ZMH, just as it is annoying behaviour
to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
Except for during ZMH, the sysop of a node using this flag finding that
they need to take their mailer offline during the specified times to
perform system maintenance, or for any other reason, would not be acting in
an annoying manner to do so, unless the practice is found to be continuous,
in which case the flag's times could be reduced, or the flag itself could
be removed from their node entry.
It should be noted that this flag is present for the benefit of mailers,
not human beings. This means that the flag should be used only to indicate
when a mailer is ready to receive calls. A system that uses a FidoNet-
technology mailer in ZMH, and a human-access only system during other
period(s) of the day that cannot receive mail, should not use this flag.
This flag does not explicitly specify online times of a public access BBS,
although for presumably most nodes with FidoNet-capable software, a public
access BBS will be available during the times indicated.
Where the flag is used, it should not often be changed. If a situation
exists, for example, where a node uses a certain set of times during the
first two weeks of a month, and a different set of times during the
remainder period, the flag should be set to a time during each day of the
month when the node is online. For example, if a node is online during
1800-0800 for the first two weeks, and then during 2200-1000 for the
remainder, the time flag should specify 2200-0800 only. If there is no such
time (other than ZMH) then no flag should be used. Of course, any permanent
changes, and any necessary reductions in the times, should be permitted at
any time, but changes owing only to daylight saving time should certainly
be expressly forbidden.
File requests and user access are of course permitted during the online
times indicated (except ZMH).
The above list may seem rather frightening! Please note that they are
guidelines rather than rules, unless FidoNet policy has included them as
rules. In the vast majority of situations where a node is online for a
fixed set of hours per day, the only thing to watch out for is that you get
the daylight saving time period right. Then you don't have to worry about
changing it at any time, except when your own online times change.
Example
-------
With regard to time zones now; this is a complicated topic, so I wish to
express an example. Imagine a node in Indiana, USA. It is online for the
time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
This changes with daylight saving time, so the times expressed effectively
| become an hour earlier with respect to UTC during daylight saving time.
| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
| the online times in UTC can be expressed as 0000-1400 UTC during winter.
| During daylight saving time, however, the local time for Indiana is 5 hours
| behind UTC. The online times during this period are 0100-1500 UTC. The
| subset should be used, so that the online times flag for the node should
| indicate availability between 0100 and 1400 UTC, which is indicated
| by the flag TBO.
| (Thanks to a few people for pointing out that the previous example was in
| error; it assumed that Indiana was ahead of UTC, and not behind as is
| actually the case.)
ANSI C routines to Calculate the Online Times Flag
--------------------------------------------------
These were not provided in the first edition. Change bars will not be used
here, since they would interfere with the syntax of the presented routines.
The first program calculates the online times flag from the user's entry of
the online times of a system, expressed in the local time zone, and the
offset to UTC used by the user's country. It takes into account that the
clock is put forward and back once a year by reducing the end time by one
hour. The program should work on any platform, and has been tested.
=== start of code ===
/* TIMEFLAG.C
Calculates FSC-0062 time flag requirement from user input */
#include <stdio.h>
char *onlineflag(char *on, char *off, int utc_diff);
void main()
{
char on[6], off[6]; int utc_diff;
printf("\nPlease specify the time you come online [HH:MM]: ");
scanf("%s", on);
printf("\nPlease specify the time you come offline [HH:MM]: ");
scanf("%s", off);
printf("\nSpecify the difference between your local time zone in winter\n"
"time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
"enter 6): ");
scanf("%d", &utc_diff);
printf("\nYour online time flag is %s\n\n",
onlineflag(on, off, utc_diff));
}
char *onlineflag(char *ontime, char *offtime, int utcdiff)
{
int onhour, onmin, offhour, offmin;
static char flag[4]="T ";
sscanf(ontime, "%d:%d", &onhour, &onmin);
sscanf(offtime, "%d:%d", &offhour, &offmin);
if(onmin>30) ++onhour;
--offhour; /* to correct for daylight saving time */
onhour = (onhour+24+utcdiff) % 24;
offhour = (offhour+24+utcdiff) % 24;
flag[1]='A'+onhour;
flag[2]='A'+offhour;
if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
if(offmin>29) flag[2] += 'a'-'A';
return flag;
}
=== end of code ===
The second program calculates the online times from the time flag, input
as a pointer to char to the routine (this being of the format "Txy"). It
returns a pointer to a structure which contains the on- and off-times in
UTC. This is not a complete program; it is designed to be used by mailers
to determine the valid online times. It has also been tested.
=== start of code ===
/* INTFLAG.C
Interprets online time flags and converts them to a set of UTC times */
struct TIMES {
int on_hour;
int on_min;
int off_hour;
int off_min;
};
struct TIMES *interpret_flag(char *time_flag);
struct TIMES *interpret_flag(char *timeflag)
{
static struct TIMES times;
times.on_min=0;
times.off_min=0;
times.on_hour=timeflag[1]-'A';
if(times.on_hour>23) {
times.on_hour -= 'a'-'A';
times.on_min=30;
}
times.off_hour=timeflag[2]-'A';
if(times.off_hour>23) {
times.off_hour -= 'a'-'A';
times.off_min=30;
}
return &times;
}
=== end of code ===
| The above routines can be copied and re-used as desired. I am now an
| amazing C programmer, but I still make no guarantees about them! :-)
Summary
-------
I believe this to be a neat and compact solution to, what is in my opinion,
one of the gravest problems currently facing FidoNet. In FidoNet, most
nodes are continuous mail, but it is important for the growth and
popularity of FidoNet that non-CM nodes do not receive many mailer calls at
times when they are off line. Users are bad enough in this respect. It is
also useful for people wishing to contact hubs that are non-CM with mail
for a downlink, and for people wishing to file request from a node that is
not CM. There is no need for systems that are only online in zone mail hour
to adopt this flag; also, there is no need for CM systems to adopt this
flag.
Contacting the Author
---------------------
My board is now online continuously, except for periods of down time during
| which the board is maintained (few and far between now that Linux is used).
Netmail contact is therefore possible at any time. I went CM because of a
certain number of nodes calling at the wrong times, and also users. Users
weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
three-minute intervals for an hour, by mailers, rather intensely :-)
End of document.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

122
html/ftsc/fsc-0070.html Executable file
View File

@ -0,0 +1,122 @@
<HTML>
<HEAD>
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FSC-0070
Date: 15-Jul-94
Revision: 002
Improving Fidonet/Usenet gating and Dupe Checking
Franck Arnaud, Fidonet 2:320/213.666
Status of this document
-----------------------
This FSC suggests a proposed standard for the FidoNet(r) community,
and invites discussion and suggestions for improvements. Distribution of
this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
Introduction
------------
The complexity of Usenet/Fidonet gating and the large number of gateways
has led to a non-negligible quantity of duplicates appearing regularly in
both the Usenet and Fidonet worlds. This proposal defines a standard method
for gateway software to deal with conversion of message identifiers between
both worlds, so that we can improve the reliability of Usenet/Fidonet
gateways.
In this document "^" means <control-A> (character 01h).
History
-------
Revision 002 adds details and makes the Fidonet to Usenet sheme FTS-0009
compliant.
Usenet To Fidonet Message Identifier Conversion
-----------------------------------------------
A major problem is preventing messages gated into Fidonet from RFC822 from
being gated back to Usenet at another gateway with a new message id. The
easy way to solve that is simply to store the RFC message ID in a kludge
line. This kludge line could also allow identifying messages gated from
Usenet (this could be used by message editors to allow private replies to
the nearest uucp gateway for example).
It is proposed that the ^RFCID: kludge is used to store the RFC Message-ID:
in Fidonet messages. Of course, the use of the RFCID kludge doesn't replace
the standard fts-0009 Message-ID:.
(Usenet) Message-ID: <92_feb_10_19192012901@prep.ai.mit.edu>
to (Fido) ^MSGID: 2:300/400.5 6789fedc
^RFCID: 92_feb_10_19192012901@prep.ai.mit.edu
Note ^RFCID does not include the Message-ID enclosing "<" and ">".
Then if a gateway finds a ^RFCID line in a Fido message, it will use it in
the Usenet message ID, instead of converting the ^MSGID.
Fidonet to Usenet Message Identifiers Conversion
------------------------------------------------
The dupe checking in Usenet is based on the message ID. Fidonet now has its
own standard message identification standard (fts-0009).
So it would be interesting if the same Fidonet message gated at different
gateways had the same ID in Usenet to help news processing programs in
stopping dupes.
The proposed fido ^MSGID: to RFC1036 Message-ID: conversion method is
defined as below:
The ^MSGID: value (a string) is not parsed and converted as below to the ID
part of Usenet's Message-ID. The Message-ID domain is the fidonet domain,
"fidonet.org" if the gated echomail comes from the Fidonet(tm) network.
To convert the MSGID string, the following rules are applied:
- Alphanumeric (a-z,A-Z,0-9) characters are kept intact (case preserved).
- Non-alphanumeric characters - including the space beetwen the origin
address and the serial number - are converted to '-'.
Some examples:
(Fido) ^MSGID: 2:300/400 12345AbC
to (Usenet) Message-ID: <2-300-400-12345AbC@fidonet.org>
(Fido) ^MSGID: 15:300/400.50@somenet abcd6789
to (Usenet) Message-ID: <15-300-400-50-somenet-abcd6789@fidonet.org>
(Fido) ^MSGID: Internet.Domain.org aBcD1234
to (Usenet) Message-ID: <Internet-Domain-org-aBcD1234@fidonet.org>
(Fido) ^MSGID: "LZKkoe$1982 98a" 45678bcd
to (Usenet) Message-ID: <-LZKkoe-1982-98a--45678bcd@fidonet.org>
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

1925
html/ftsc/fsc-0072.html Executable file
View File

File diff suppressed because it is too large Load Diff

305
html/ftsc/fsc-0087.html Executable file
View File

@ -0,0 +1,305 @@
<HTML>
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0087
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
File Forwarding in Fidonet Technology Networks
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
To document current practices in File Forwarding and the minimum
requirements and known extensions of the TIC file format.
Acknowledgements:
The TIC file format was introduced by Barry Geller, in the MSDOS
File Forwarder, Tick. Useful extensions to this format were introduced
by Harald Helms, in the MSDOS FileForwarder, AllFix.
Terminology:
FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or IBMNET.
Sometimes used interchangably with the term DOMAIN.
FNC - FileName Conversion, process of converting filenames to msdos 8.3
format for transmission.
FQFA - Fully Qualified FTN Address, the format is
FTN#Zone:Net/Node.Point
CRC - Cyclic Redundancy Check, method to determine whether some data
has been altered. CRC-32 is used in File Forwarding.
TIC - a file that contains control information for the File Forwarding
system. These files are named xxSTAMP.TIC, where xx is an
abbreviation representing the File Forwarding program name and
stamp is a unixdate stamp truncated to 6 characters.
UTC - Universal Time Coordinated, the time at the 0o meridian
(Greenwich); previously called GMT
forwarding - the process of creating and sending tic files and the
associated file to one's downlinks.
ticking - the processing of reading and verifying a tic file and it's
associated file.
hatching - the process of introducing a new file into a fileecho
cross-hatching - the process of forwarding a file from one fileecho
(ususally restricted) to another
Associated File - The file listed in the FILE field of the TIC file.
Note that use of UPPERCASE on tic file keywords in this document in
for display purposes only.
Format of a TIC file:
Addressing:
In a tic file any form of FTN address representation from 3d to
FQFA may be used. All File Forwarders must understand the
following formats:
zone:net/node - 3D
zone:net/node.point - 4D
zone:net/node@ftn - 5D - point 0 assumed
zone:net/node.point@ftn - 5D
ftn#zone:net/node.point - fqfa
File Forwarders should have configurable options per site as to the
type of addressing each of it's downlinks can understand.
Dates:
All dates are expressed in UTC.
TimeDateStamps:
All TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
1, 1960) in UTC and expressed in hexadecimal notation.
Case Insensitivity:
the format is completely case-insensitive. It is general practice
that the first letter of a keyword is uppercase. This is not a
requirement.
Order Dependancy:
keywords are not order dependant.
Order dependancy is required in some groupings of a keyword, such
as PATH, VIA, DESC and APP.
Modification of address fields on PassThrough:
The forwarding site may modify the addresses in any keyword field
to make them compliant with the addressing limitations of each
downlink.
Stripping of SeenBys:
The forwarding site may strip seenbys to current FTN, ZONE or NET,
when not forwarding outside of current FTN, ZONE or NET. This does
not imply nor permit the stripping of of a direct downlink which is
outside the current strip filter.
Keywords:
There are no colons on keywords.
Each keyword line is terminated with CR LF pair.
The maximum length of a keyword line is 256 characters, including the
CRLF termination. Some keyword lines may have a shorter limit.
Keywords are separated from their data by a single space. There is
no space if there is no data associated with the keyword.
eg: ReturnReceipt
Keywords are case-insensitive and order independant.
Keywords not understood are to be passed-though.
Known Keywords that are blank should not be passed though.
For example, an empty AREADESC, could be either dropped or the
blank replaced with the proper description.
Most Keywords are passed through when processing.
There are exceptions. In some cases, a site-specific replacement
may be created.
Keywords marked with a ^ should not be passed-through.
Keywords marked with a * are REQUIRED when processing a TIC file.
If any of these are missing, the tic file should be considered as
BAD and the associated file not forwarded to downlinks.
Keywords marked with a # are CREATED when hatching or forwarding.
*# AREA [AreaName]
the TagName of the file area.
AREADESC [description of area] OPTIONAL
a short (80 chars) description of the file area. This could be
the description found in FileBone.NA
*# FILE [File being sent]
the name of the file being sent, no path
the filename must conform to msdos 8.3 format, unless it is known
that the receiving site can handle longer filenames.
^# FULLNAME [original filename before FNC] OPTIONAL FNC only
the original filename (no path) before FileName Conversion
*# CRC [CRC-32 in hex]
crc of the file being sent, 8 hexadecimal characters
^ MAGIC [MagicName] OPTIONAL
Name under which the file can be FREQed from the site listed in
FROM. This is NOT passed though when forwarding, unless the
MAGIC name is the same on the forwarding site. It can be
replaced by the appropriate name.
REPLACES [FileName] OPTIONAL
Filename (no path) of a file hatched in the AREA that the
associated file replaces. If the site expects FNC files, and the
filename does not confrom to msdos 8.3 convention, the REPLACES
name should also be FNC.
# DESC [Description]
Description of the file, limited to 80 characters per line,
including CRLF termination.
If multiple LDESC lines are used, the DESC line must provide the
maximum information. No File Forwadrer is required to passthough
or make use of any extra DESC line after the first.
# LDESC [multiple lines]
A long description of the file. LDESC does NOT replace DESC, it
is used IN ADDITION to the short description. No File Forwarder
is required make use of LESC lines.
# SIZE [Bytes] OPTIONAL, SHOULD be required
Length of the file in bytes
DATE [TimeDateStamp]
TimeDateStamp of the file. Can be date of creation of archive.
RELEASE [TimeDateStamp]
Date when file is TO BE released. Usually used by SDS, but can
be used by ADS as well.
AUTHOR [name]
Name of the author of the software package being hatched. This
field is obviously not applicable to Newsletters, Nodelists and
Diffs and the like.
SOURCE [authors_address]
FTN address of the Author of the software package being hatched.
Not necessary the same as the ORIGIN hatch site. Does not have
to be an FTN address.
^ APP [program] [Application Specific Information]
The APP keyword is a keyword known to programs of the name
indicated. APP'S are order dependent and must be passed though.
*# ORIGIN [Address]
Site where file entered the fileecho
*^# FROM [Address] [Pwd]
Site that is forwarding the file to the next site. Pwd is
optional and rarely used, IF AT ALL. Pwd is NEVER passed through.
^ TO [Address] OPTIONAL
Site to which this TIC and the assocaited file are being sent.
This keyword is included in the .TIC file when:
a) the file is being routed via another system which permits
such routing.
b) the platform in use does not have any FTN software
independant method of associating a file nd it's
destination. eg. platforms that do not have filenotes
that could contain this information as part of the
filesystem.
If the address in the TO line is that of the receiving site, the
field is not passed through when forwarding. If the address in
the TO lines IS NOT that of the receiving site, it should be
forwarded to the TO site, if a routing agreement is in place with
the sending site.
*^# CREATED [by] [Program Banner]
File Forwarder which created the TIC file. This is generally in
the form:
Created [by] program_name version [copyright_info]
VIA [FROM CREATED] OPTIONAL (tracking)
Copy of CREATED line of FROM, with 'Created [by]' stripped and
FROM prepended. Always passed though. The VIA is only created
by the receiving site when forwarding. It is never created by the
hatching site. Therefore, in any TIC file, the addresses in the
FROM and VIA should never be the same.
examples:
Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0
*# PATH [Address] [TimeDateStamp] [date and time]
Address of Site which has forwarded the file. TimeDateStamp,
date and time is that of when the Site received and Processed the
file.
* # SEENBY [Address]
Site which has received the file. There are multiple lines of
Seenby and they are unordered.
* PW [password]
Site or Area password. This is case-insensitive and should be at
least 5 characters in length.
PGP [signature]
PrettyGoodPrivacy signature. To be discussed.
^ ReceiptRequest -no data- OPTIONAL
A request to the receiving system to generate a IsReturnReceipt
(attribute word bit 13) messsage, in the same manner it would if
it had received a message with the FileAttach an ReturnReceipt
attributes and a subject of the filename.
There is NO requirement to recognize this keyword. It should
never be passed through.
Transmission of Files:
The associated file, that is, the file Listed in the FILE field of the
TIC file, should always be sent FIRST. In the case of a failed session,
sending the FILE first prevents the orphaning of the file that is
normally caused by the deletion or movement of the TIC file to BAD.
File Forwarders should not move or delete orphaned TIC files, but this
can neither be relied upon nor mandated.
File Forwaders should be transparent to the renaming of file by
mailers. This means that if the mailer renames a duplicate file by
renaming or bumpinmg a numeric extension, the File Forwarder should be
able to use the size and crc fields of the TIC to find and properly
rename the associated file referred to in the TIC.
File Forwaders should always delete and dequeue unsent TIC files when
re-hatching the same or updated version of an associated file. The
implementor may wish to allow exceptions for periodicals such as
nodediffs and newsletters.
-to be continued-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

326
html/ftsc/fsc-0088.html Executable file
View File

@ -0,0 +1,326 @@
<HTML>
<HEAD>
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0088
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
Compatibility and Link Qualifier Extensions for EMSI Sessions
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
The basic purpose of this document is to start discussions which will
hopefully result in an improved handshake negotiation protocol.
Scope:
Relation of flags to Types of files transferred:
The FSC-0056 EMSI specification (hereafter referred to as EMSI-I)
makes little distinction between ARCmail/packets and other types of
files, such as files attached and TIC'ed files. In EMSI-I, the term
'Mail' when not used in conjunction with the term 'compressed', is
interpreted to mean ANY file.
This extension (hereafter referred to as EMSI-II) makes reference to
and allows control of types of files in addition to 'compressed mail'.
References to 'Mail' are changed to 'File' where common practice so
indicates. The additional qualifier flags described provide for more
control as to the types of files a system is prepared to receive.
Relation of flags to presented addresses:
The EMSI-I specification does not allow qualification for any address
other than the PRIMARY address. This means that Link flags are limited
in application to either all presented addresses or to the primary
presented address only.
This extension also allows application of Link flags to specific
addresses other than the primary.
Distinctions between Calling and Answering System:
In the EMSI-I spec, the type of flags that may be presented is limited
by the status of the site. Certain flags may only be presented when
the site is the caller and other flags may only be presented when the
site is the answerer. This proposed extension removes this
distinction.
In the EMSI-I spec, certain Link and Capability (a.k.a: Compatibility)
flags are caller-driven, while others are controlled by the answering
system. This specification attempts to harmonize these discrepancies.
A attempt is made to remain somewhat backwards compatible and to have
new flags follow the original flag naming convention. However, IMHO,
it would be preferable to harmonize the flags; reducing the number of
them while retaining the fine type control, so that the same codes are
used in all sessions.
Under both EMSI-I and EMSI-II, any flags that are not understood, are
to be ignored. Therfore, if a site presents it's flags in EMSI-II
format and the other site does not do EMSI-II, it is permissable for
that site to interpret all flags according to EMSI-I specifications.
Specifics:
Compatibility flags:
Compatibility flags consist of a string of codes that specify the
PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
ARC, XMA
These EMSI-I compatibility flags have no meaning relavant to the
transfer of files and are not to be presented under EMSI-II. If
received, they are to be ignored.
FNC
The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
the author of EMSI-I. This is agreeable as that specification called
for the creation of a filename that was ALWAYS 8.3, not
up-to-8.up-to-3.
It is not to be presented under EMSI-II. If received as a
compatibility flag, it is to be ignored.
Protocol Selection:
In the EMSI-I spec, a requirement is placed upon the calling system to
present it's available protocols in order of preference. A quote
follows:
The calling system must list supported protocols first and
descending order of preference (the most desirable protocol
should be listed first).
The answering system should only present one protocol and it
should be the first item in the compatibility_codes field.
Some mailer authors have interpreted 'the compatibility_codes field' in
the second sentence to mean that of the answering system, thereby
making protocol selection RECEIVER-PREFS driven. This interpretation
makes unnecessary the 'decending order' requirement placed upon the
calling system, so shall be considered in conflict with that
requirement.
Most mailer authors have interpreted that phrase to mean the
'compatibility_codes field' OF THE CALLER, thereby making protocol
selection CALLER-PREFS driven. Since EMSI-I was intended to be "a
clear protocol definition for state-of-the-art E-Mail systems to
follow", they cannot be faulted for interpretation. Caller-prefs
driven selection is state-of-the-art, receiver-prefs driven selection
is older technolgy, such as Wazoo.
This specification requires that the second interpretation,
CALLER-PREFS driven, be mandatory.
New Compatibilty Flags:
----------------------
EII
Indicates that the system will interpret flags under this
specification, if other end also presents this flag. IF either or both
systems do not present this flag, all interpretations are done
according to EMSI-I.
DFB
Indicates that the system presenting is capabable of fall-back to
FTS1/WAZOO negotiation in the case of failure of EMSI handshake or no
common protocol. Since ZMO is the minimum required protocol, NCP
should only occur if the answering system presents more than one
protocol.. (ie. it's broken)
FRQ
Indicates that the system will accept and process file requests
received during outbound calls. In other words, the calling system
will do a second turnaround for uni-directional protocols, to send the
files requested, at his cost.
NRQ
NRQ should be presented ONLY IF the mailer does not have a file request
server, task or function and cannot accept requests.. It should NOT be
used to indicate that the function is temporarly disabled.
When examined, No requests will be sent. It would be advisable that
the mailer alert the system operator of this occurance to prevent
continued polling of the remote site.
Protocol Capabilities:
Protocol capability flags are presented in decending order of
preference by the caller. The answering system selects and presents
the FIRST protocol from the callers list that it supports. The
answering system must present only ONE protocol.
HYD Hydra bi-directional (link flags define parameters)
JAN Janus bi-directional
TZA DirectZap (TrapDoor DirectZap varient)
DZA DirectZap (Zmodem variant, reduced escape set)
ZAP ZedZap (Zmodem variant, upe 8K blocks)
ZMO Zmodem w/1,024 packets (Wazoo ZedZip)
SLK SeaLink (no TYSNC, No MDM7, No TeLink)
(8-32k window/ReSync/OverDrive/LongNames)
NCP
This is presented if no compatible protocol can be negotiated under
EMSI. Since in most FTN networks, a common protocol DOES exist,
fallback to WaZoo and FTS1 negotiation is expected. If these
negotiation methods are not available, the session is terminated.
This condition should never occur under normal circumstances. It
should be considered as a problem with the design or configuration of
one of the mailers involved.
Link flags:
----------
Link flags consist of a string of codes that specify DESIRED CONNECT
CONDITIONS. They apply to the CURRENT SESSION ONLY. Under EMSI-I,
there are four TYPES of link flags: communications parameters, session
parameters, pickup options and hold options. Under EMSI-II, only three
types are used, the communications parameters type is REMOVED, as it
serves no purpose whatsoever in FTN operations.
Link Session options:
FNC
If either system presents this flag, it is an indication that the
presenting system requires filename conversion to cp/m-msdos
conventions. The other system will convert filenames to cp/m cpm/msdos
8.3 conventions before sending.
The convention is defined as a filename consisting of two
parts, the filepart and extension. The filepart and extension are
separated by a period ".". The filepart may be from 1 to 8 characters
in length and the extension may be from 0 to 3 characters. The
character set shall be any uppercase character in the range A-Z and any
numeric character in the range 0-9. If the extension is of zero
length, the period may or may not be present.
RMA
Indicates that the presenting site is able to send and process multiple
file requests. If both sites present this flag, the caller will send
any REQ files found for each AKA presented by the answering system.
The answering system will process each received REQ.
RH1
Indicates that under the Hydra protocol, batch one contains file
requests only, while batch 2 is reserved for all other files.
(others to be defined)
Pickup and Hold Flags:
Under the EMSI-I specification, Link Pickup flags are only presented
when calling (an Outbound Session) and are examined and processed only
when answering (an Inbound Session) and Link Hold flags are only
presented when answering (an Inbound Session) and are examined and
processed only when calling (an Outbound Session).
With EMSI-II, BOTH Pickup and Hold flags are presented by both sites
during a session. This allows more control for those systems, for
example, which cannot modify addresses presented or rotate akas to
change the primary address presented on a per-session or per-site
basis.
Link Pickup and Hold:
Each system can present one of three (or more) Link options related to
application of addresses. If neither of these flags are presented, PUA
is to be assumed.
Neither PUA nor PUP is to be presented if only one address was
presented.
PUP Pickup FILES for primary address only
/ PUA Pickup FILES for all presented addresses
/ PUn Pickup FILES for address number n in AKA list
one of |
\
\ NPU No FILE pickup desired. (calling system)
HAT Hold all FILES (answering system)
HAn Hold all FILES for address number n in AKA list
Qualifiers:
Qualifiers are processed in the order presented, with any conflict
being resolved by subsequent qualifiers overridding any conflicting
previous qualifier in the list.
Qualifiers may be not be presented with either NPU or HAT and should be
ignored if received with NPU or HAT.
PickUp:
PMO PickUp Mail (ARCmail and Packets) ONLY
PMn PickUp Mail ONLY for address number n in AKA list
NFE No TIC'S, associated files or files
attachs desired
NFn No TIC'S, associated files or file attaches,
for address number n in AKA list
NXP No compressed mail pickup desired
NXn No compressed mail pickup desired,
for address number n in AKA list
NRQ File requests not accepted by caller
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
NRn File requests not accepted by caller
for address number n in AKA list
Note that NFE,NPX,NRQ != NPU
Hold:
HNM Hold all traffic EXCEPT Mail (ARCmail and Packets)
HNn Hold all traffic EXCEPT Mail (ARCmail and Packets)
for address number n in AKA list
HXT Hold compressed mail traffic.
HXn Hold compressed mail traffic.
for address number n in AKA list
HFE Hold tic's and associated files
and file attaches other than mail
HFn Hold tic's and associated files
and file attaches other than mail
for address number n in AKA list
HRQ Hold file requests (not processed at this time)
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
HRn Hold file requests (not processed at this time)
for address number n in AKA list
Note that HXT,HRQ,HFE == HAT
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

60
html/ftsc/fsc-0091.html Executable file
View File

@ -0,0 +1,60 @@
<HTML>
<HEAD>
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: fsc-0091
| Version: 001
| Date: 01 Jun 1996
| Arjen Lentz, 2:283/512
ISDN nodelist flags (rev.002) Arjen Lentz (agl@bitbike.com)
addendum to FTS-0005 FidoNet 2:283/512
superceding FSC-0075 October 30th, 1995
Input from Michael Buenter, Jan Ceuleers, Chris Lueders, and others. Thanks!
The proposed new information text in nodelist trailer is as follows:
Nodelist Specification of minimal support required for this flag;
flag any additional support to be arranged via agreement between users
======== =================================================================
V110L ITU-T V.110 19k2 async ('low').
V110H ITU-T V.110 38k4 async ('high').
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7, modulo 8.
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7, modulo 8.
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B channel;
layer 2 max.framesize 2048, window 2, non-ext.mode (modulo 8);
layer 3 transparent (no packet layer).
ISDN Other configurations. Use *only* if none of the above fits.
===========================================================================
NOTE: No flag implies another. Each capability MUST be specifically listed.
If no modem connects are support, the nodelist speed field should be 300.
Conversion from old to new ISDN capability flags:
- Nodes in the USA currently use the 'ISDN' flag.
Most will be able to change to V120H (64k lines).
Also many to V120L,V120H (64k lines) with autodetecting equipment.
Some to only V120L (still with 56k lines).
- Nodes in Europe currently use the ISDNA, ISDNB and ISDNC flags.
A simple translation will do the trick here.
ISDNA -> V110L
ISDNB -> V110H
ISDNC -> X75
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

243
html/ftsc/fsc-0092.html Executable file
View File

@ -0,0 +1,243 @@
<HTML>
<HEAD>
<TITLE>New control lines for forwarded messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0092
| Version: 001
| Date: September 12th 1996
| Author: Michael Hohner
New control lines
for forwarded messages
by
Michael Hohner
2:2490/2520.17
September 1996
Status of this document:
This document proposes a standard for the Fidonet(tm) community
and for other networks using Fido technology. It may be freely
distributed if unchanged.
You can reach the author at one of the addresses listed at the end
of the document.
Abstract:
Most fidonet message editors offer a "forward" function. Using
this function a user A can sort of "redirect" a message from user B
to another user C, maybe because A is not the correct recipient or
because C is a better person to answer the message. The name and
address of B are usually included in the forward in free-text format.
The message text is included in non-quoted format.
A problem arises when the final recipient C wants to reply to sender B
of the forwarded message. The forward contains the intermediate user A
as the sender. So user C must insert the name and address of B
manually, using the information contained in the message text. The
message editor of C can't do this automatically because of the
free-text format. The editor will also use incorrect quote initials,
which is at least irritating.
This document introduces 6 new control lines which contain the header
information of the original message. With these control lines the
message editor can use the original header information automatically.
Specifications:
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
ASCII 01 character followed by the control line name followed by
whitespace followed by the control line's content followed by ASCII 13.
Please note that all these control lines do not have a colon (like the
control lines in FTS-0001). This would be just waste of space.
FWDFROM
-------
This control line contains the name of the original sender as found in
the FROM field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the FROM field is empty.
FWDTO
-----
This control line contains the name of the original recipient as found
in the TO field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the TO field is empty.
FWDORIG
-------
This control line contains the address of the original sender as found
in the ORIG field of the original message. The usual 5D ASCII notation
(zone:net/node.point@domain) should be used. This control line should
be omitted altogether if the address is not known.
FWDDEST
-------
This control line contains the address of the original recipient as
found in the DEST field of the original message. The usual 5D ASCII
notation (zone:net/node.point@domain) should be used. This control line
should be omitted altogether if the address is not known or unsure
(as it is the case with forwarded echomail messages).
FWDSUBJ
-------
This control line contains the subject line of the original message.
This control line should be omitted altogether if the SUBJ field is
empty.
This control line should by made optional for security reasons. Echo
manager passwords are too easily revealed with it.
FWDAREA
-------
This control line contains the name of the echomail area where the
original message was forwarded from. It should be omitted altogether
if the original message was not forwarded from an echomail area.
FWDMSGID
--------
This control line contains the MSGID control line of the original
message. It should be omitted altogether if a MSGID control line is not
present in the original message.
Usage:
When the "forward" function of the message editor is invoked, the
editor program should generate the proposed control lines from the
header of the original message. If the original message already was
a forwarded one (indicated by the presence of at least a FWDORIG
control line), the editor should keep all FWD* control lines and should
not add any FWD* control lines. This preserves the FWD* control lines
of the first forwarder, containing the header data of the author of
the original message.
The editor should not generate FWD* control lines, if the message isn't
to be forwarded. A mail forwarding robot may also generate these
control lines, if it not just readdresses the message.
When the "reply" function of the editor is invoked the program should
use the control lines' contents instead of the header information. The
control lines should not be included in the reply.
Since it may not be immediately clear whether the user wants to reply
to the forwarder or to the original sender, the editor should offer a
means to ignore the proposed control lines and start a "normal" reply
instead, e.g. by two distinct functions, user preference or dialog.
Pseudo code:
forwarding_message:
if is_forwarded_message then
don't change FWD* control lines
else
add FWD* control lines
quoting_message:
if is_forwarded_message then
if reply_to_forwarder then
use header data (normal quoting)
else
use FWD* control lines
remove FWD* control lines from reply
else
use header data (normal quoting)
other_functions:
remove/ignore FWD* control lines
Example:
Message from Joe User to my boss node:
From: Joe User 1:234/567
To: Harry Herrmannsdoerfer 2:2490/2520
Subj: Some questions
@MSGID: 1:234/567 12345678
Text: Hello Harry!
...
Harry forwards the message to me:
From: Harry Herrmannsdoerfer 2:2490/2520
To: Michael Hohner 2:2490/2520.17
Subj: Joe's message
@FWDFROM Joe User
@FWDORIG 1:234/567
@FWDTO Harry Herrmannsdoerfer
@FWDDEST 2:2490/2520
@FWDSUBJ Some questions
@FWDMSGID 1:234/567 12345678
Text: Hi Michael!
...
My answer using the new control lines:
From: Michael Hohner 2:2490/2520.17
To: Joe User 1:234/567
Subj: Some questions
@REPLY: 1:234/567 12345678
Text: Hi Joe!
JU> ...
...
Compatiblity:
Editor programs which are not prepared for the proposed control lines
usually just ignore them and remove them from a reply. A reply goes
to the forwarder. Nothing gained and nothing lost.
Implementations:
This proposal is implemented in the author's Fidonet editor
"FleetStreet for OS/2" (versions 1.17 and above).
Contacting the author:
The author may be contacted electronically at the following addresses:
Fidonet: 2:2490/2520.17
Internet: miho@osn.de
CompuServe: 100425,1754
Suggestions, comments and corrections are always welcome.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

156
html/ftsc/fsc-0093.html Executable file
View File

@ -0,0 +1,156 @@
<HTML>
<HEAD>
<TITLE>Reduced seen-by lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FSC-0093
| Version: 001
| Date: 13 September, 1996
| Title: Reduced seen-by lines
| Author: Frank Ellermann, 2:240/5815.1
Reduced seen-by lines
Frank Ellermann, 2:240/5815.1
Abstract
--------
A way to save great amounts (estimated 10 %) of echo mail traffic by
reducing "seen by" informations, compatible with existing echo mail
tossers conforming to FTS-0004.
Definitions
-----------
A thorough understanding of FTS-0004 is required, the reader should
be familiar with PATH and SEEN-BY lines in echo mail, illegal and
legal echo mail distribution topologies, i.e. dup-rings, as well
as with some pre-requisite knowledge of zones, 4D and 2D addresses,
and the "sticky" 2D notation in PATH and SEEN-BY lines.
PATH: path lines as specified in FTS-0004
FSB: full seen-by informations as specified in FTS-0004
TSB: tiny seen-by informations as mentioned in FTS-0004, see below
RSB: reduced seen-by informations specified below
dupe: multiple arrival of the same echo mail (e.g. different paths)
Examples of echo mail distribution topologies
---------------------------------------------
In all examples a) to d) echo mail entered at system 1 is sent to
systems 2 and 3 with FSB 1 2 3. Therefore system 2 (3) knows, that
system 3 (2) already got this mail, topology a) is perfectly legal.
a) 1 - 3 b) 1 - 3 c) 1 - 3 d) 1 - 2
| / | | | / | | X |
2 2 - 4 2 - 4 2 - 4
In the exanmples b) and c) both systems 2 and 3 forward all mails
from system 1 to system 4, these topologies contain a dup-ring and
are therefore illegal following FTS-0004.
The examples a) and d) show fully connected polygons with three or
four nodes. In example d) a mail entered at system 1 is sent to
systems 2, 3, and 4 with FSB 1 2 3 4. The topologies a) and d) are
perfectly legal, there are no dupes caused by distribution.
In example b) each mail entered at system 1 reaching system 4 via
system 2 carries FSB 1 2 3 4, therefore system 4 will not forward
such mails to 3. Using TSB at system 2 the same mails would carry
TSB 2 4, therefore system 4 would forward them to 3 as dupes.
Note that illegal topologies as in example b) and c) cause dupes
with either FSB or TSB. The real problem with TSB is example b),
as it allows for loop mails on the dup-ring 1 - 2 - 3 - 4 - ...
and vice versa, if no additional checks for dupes are employed.
With RSB (specified below) systems contained in the PATH are not
stripped from the seen-by informations, therefore RSB avoid loop
mail much like FSB.
FSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the FSB qualify as recipients.
3) add own address(es) to the FSB set if not already contained.
4) add recipients to FSB, sort FSB, forward mail to recipients.
TSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the TSB qualify as recipients.
3) strip old TSB and start new TSB with own address(es).
4) add recipients to TSB, sort TSB and forward mail to recipients.
RSB algorithm
-------------
1) add own system to the PATH.
2) all area links not contained in the RSB qualify as recipients.
3) strip RSB addresses not matching an address in the PATH, then
add own address(es) to the RSB set if not already contained.
4) add recipients to RSB, sort RSB and forward mail to recipients.
PATH considerations
-------------------
There are 2 problems with the PATH kludge as specified in FTS-0004:
First like in the FSB the addresses in the PATH are 2D, and having
the same 2D address in different zones is possible. Therefore zone
gates are required to use the TSB algorithm. Unfortunately the PATH
is forwarded without regarding zone gating, therefore detection of
loop mail based solely on the PATH could be erroneous.
Further FTS-0004 (written 1989) expects future echo mail tossers to
implement PATH support, but doesn't require this support from old
implementations. Strictly spoken the PATH is still only an option.
In some areas of FidoNet (e.g. in zone 2) at least all non-terminal
nodes are required to fully support the PATH line, therefore this
problem will probably not show up in praxis. Of course any tosser
implementing the RSB feature is required to fully support the PATH.
Summary
-------
To show the benfits of RSB compared with FSB assume the following:
An echo mail travels from node to echo hub, host, major star, echo
host, hub, and finally arrives at a recipient. Each routing system
has 10 links, i.e. FSB at the recipient contain 51 addresses, about
400 characters, but RSB only 15 addresses in about 150 characters.
Therefore in an echo mail with 2500 characters about 10 % of its
size can be reduced using RSB in favour of FSB. If this estimation
is applicable on world wide FidoNet echo mail traffic, RSB can save
us an immense amount of costs.
This document can be adopted by the FTSC as FTS, in this case it
has to be regarded as an addition to FTS-0004 with the extension,
that all non-terminal nodes are required to support PATH lines as
specified in FTS-0004.
For additional informations (e.g. aspects of zone gating) feel free
to send mails to Frank Ellermann 2:240/5815 or leo@bfispc.hanse.de
- eof -
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

210
html/ftsc/fsp-1001.html Executable file
View File

@ -0,0 +1,210 @@
<HTML>
<HEAD>
<TITLE>Timezone information in FTN messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1001
Revision: 2
Title: Timezone information in FTN messages
Author: Odinn Sorensen, 2:236/77
Revision Date: 27 September 1997
Expiry Date: 13 September 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Current practice
3. Kludge specification
4. Timezone table
5. Examples
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
Current practice for Fidonet Technology Network (FTN) messages is to
store dates in local time. Timezone information (if known) is
usually lost. This document specifies a standard for storage of
timezone information in FTN messages, in the form of a kludge named
TZUTC.
1. Scope
--------
This standard is specified for FTN messages in any form where
timezone information is not integrated in the message storage or
transport format. Specifically any form where the information would
be lost if not stored in a kludge, such as in FTS-1 stored messages
or packets.
2. Current practice
-------------------
Some kludges already exist to specify the timezone of messages,
notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
To the authors knowledge, no official specification exists for any
of these kludges.
From observations of these kludges in actual messages, TZUTC and
TZUTCINFO are identical except for the name. TZUTCINFO is probably
named after the JAM msgbase subfield of the same name.
This document adopts and documents the TZUTC kludge because it is
the shortest of them.
3. Kludge specification
-----------------------
Messages which conform to this specification must add the kludge:
^aTZUTC: <current offset from UTC>
The offset has the format <[-]hhmm>, where hhmm is the number of
hours and minutes that local time is offset from UTC. If local time
is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
table below for typical offsets.
Note that the hh in a timezone offset is not limited to a maximum of
12. This is because the International Date Line does not run exactly
along the boundary between zone -1200 and +1200. The minutes part is
00 for most timezones.
All four digits must be present. If the offset is negative, there
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
the offset for positive numbers, but robust implementations should
be prepared to find (and ignore) a plus if it exists.
If local time changes as a result of, for example, daylight savings
time, then the offset in TZUTC need to be changed to reflect this.
When this kludge is present in a message, the "date written" field
in the stored message is guaranteed to be in local time for the
given timezone. Note that this specification does not specify the
timezone for any other date fields. Other date fields (such as "date
received, arrived, processed, etc.") are usually in local time for
the system on which the messages are stored.
4. Timezone table
-----------------
This table gives examples of typical timezones.
-1000 Alaska-Hawaii Standard Time
-0900 Hawaii Daylight Time
-0800 Pacific Standard Time
-0700 Pacific Daylight Time
-0700 Mountain Standard Time
-0600 Mountain Daylight Time
-0600 Central Standard Time
-0500 Central Daylight Time
-0500 Eastern Standard Time
-0400 Eastern Daylight Time
-0400 Atlantic Standard Time
-0330 Newfoundland Standard Time
-0300 Atlantic Daylight Time
-0100 West Africa Time
0000 Greenwich Mean Time
0100 Central European Time
0100 British Summer Time
0200 Central European Summer Time
0200 Eastern European Time
0800 Australian Western Time
0800 China Coast Time
0900 Japan Standard Time
0900 Australian Western Daylight Time
0930 Australian Central Standard Time
1000 Australian Eastern Standard Time
1030 Australian Central Daylight Time
1100 Australian Eastern Daylight Time
1200 New Zealand Standard Time
1300 New Zealand Daylight Time
5. Examples
-----------
^aTZUTC: 0000
^aTZUTC: 0200
^aTZUTC: -0700
6. Redundancy
-------------
If the TZUTC data duplicates a field in a storage format in such a
way that no information is lost in conversion to or from the field,
then it is recommended that the kludge is not stored in the message.
However, implementations are allowed to store the TZUTC even when
redundant.
A. References
-------------
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
Bush. September 1995.
[JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
Milner, Mats Birch and Mats Wallin. July 1993.
B. Author contact data
----------------------
Odinn Sorensen
Fidonet: 2:236/77
E-mail: odinn@goldware.dk
WWW: http://www.goldware.dk
C. History
----------
Rev.1, 970913: First release.
Rev.2, 970927: Updated the timezone table. Added section about
redundancy. Clarified what happens when local time
changes. Clarified some of what the specification
doesn't cover.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

140
html/ftsc/fsp-1002.html Executable file
View File

@ -0,0 +1,140 @@
<HTML>
<HEAD>
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1002
Revision: 2
Title: Numeric reply indication in FTN subject lines
Author: Odinn Sorensen, 2:236/77
Revision Date: 19 October 1997
Expiry Date: 11 October 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Format
3. Reply procedure
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
When making a reply to a message, there are currently three common
ways to handle the subject line:
1. Don't change it.
2. Insert the string "Re: " in front of it.
3. Insert the string "Re^n: " in front of it, where 'n' is increased
by one if the original subject was already a reply.
This document concerns itself with specifying the third variant.
1. Scope
--------
This standard is specified for all FTN messages. Implementations
will typically be message editors and other software that creates
replies to messages.
2. Format
---------
The format is "Re^n: ", where n is an unsigned integer number with
one or more digits. The range of the number must be at least 0 to
255. Negative numbers are not allowed. Note that there must be a
space after the colon. The letters are not case sensitive, but
uppercase 'R' and lowercase 'e' is recommended.
3. Reply procedure
------------------
When making a reply that conforms to this specification, this
procedure, or a functionally identical one, must be followed:
1. If the original subject does not have a leading "Re: " or
"Re^n: ", put the string "Re: " in front of it. Don't use a
number here.
Example: "Hello world" -> "Re: Hello world"
2. If the original subject has a leading "Re: ", put the string
"Re^2: " in front of the subject.
Example: "Re: Hello world" -> "Re^2: Hello world"
3. If the original subject has a leading "Re^n: ", increase the
number 'n' by one and modify the subject accordingly.
Example: "Re^4: Hello world" -> "Re^5: Hello world"
Notes:
* The numbers 0 and 1 should not occur in the "Re^n: " string under
normal circumstances, but a robust implementation should just
increase the number in any case.
* The number should not be increased beyond the range of the number
type used in the implementation, or in other words, it should not
roll around to zero. If it can't be increased, leave it alone.
* When inserting the "Re: " or "Re^n: " string in front of the
subject, information from the end might be lost, because the
message storage or packet formats use fixed length subject fields.
Intelligent subject-based reply linking software should be aware
of this and try to link correctly anyway.
A. Author contact data
----------------------
Odinn Sorensen
Fidonet: 2:236/77
E-mail: odinn@goldware.dk
WWW: http://www.goldware.dk
B. History
----------
Rev.1, 971011: First release.
Rev.2, 971019: Added note that "Re" is not case sensitive.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

116
html/ftsc/fsp-1003.html Executable file
View File

@ -0,0 +1,116 @@
<HTML>
<HEAD>
<TITLE>Suggested use of Nodelist Fields.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1003
Revision: 1
Title: Suggested use of Nodelist Fields
Author: Lee Kindness
Revision Date: 15 May 1997
Expiry Date: 15 May 1999
----------------------------------------------------------------------
Contents:
1. Field 3, Node Name
2. Field 4, Location
3. Field 5, Sysop Name
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Introduction
------------
This document makes recommendations on the use of various fields in
the distribution nodelist (St. Louis nodelist format", fts-0005).
Naturally it is the choice of the *C's if they want to use them.
Remember the fts-0005 requirements should still be adhered to.
1. Field 3, Node Name
---------------------
The node name field should be no more than 20 characters long. For
comparison in nodelist.122'1997 the minimum entry was 1, maximum 51!
and the average was 14.
For zone entries this field should contain a description of the
zones area, (eg North America, Europe). For region entries it should
contain the country/state, for host entries the local area name and
for hub entries a description of the area the hub serves.
2. Field 4, Location
--------------------
This field contains the location of the node. It should usually be
expressed as the primary local location (town, suburb, city, etc.)
plus an identifier of the regional geopolitical administrative
district (state, province, department, county, etc.). Wherever
possible, standard postal abbreviations for the major regional
district should be used (IL, BC, NSW, UK, etc.).
For zone and region entries this field should also have the julian
day of segment creation appended to it (eg "Somearea_(122)") to aid
checks on the validity of the nodelist.
3. Field 5, Sysop Name
----------------------
This field contains the name of the system operator. Entries such as
"postmaster" and "uucp" should not be used. Aliases should not be
permitted in this field (as they give Fidonet a 'less respectable'
image).
A. Author contact data
----------------------
Lee Kindness
Fidonet: n/a
E-mail: wangi@earthling.net
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
B. History
----------
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
article. Transformed into FSP document by Odinn
Sorensen.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

257
html/ftsc/fsp-1004.html Executable file
View File

@ -0,0 +1,257 @@
<HTML>
<HEAD>
<TITLE>Standard FidoNet Addressing.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1004
Revision: 1
Title: Standard Fidonet Addressing
Author: Lee Kindness
Revision Date: 15 May 1997
Expiry Date: 15 May 1999
----------------------------------------------------------------------
Contents:
1. Standard Fidonet Addressing
2. Internet Gateway Addressing
3. Routing Address Syntax
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Introduction
------------
This document describes the standard form of addressing in Fidonet
today along with the common method of addressing via internet
gateways. In addition it proposes an extended addressing syntax,
useful for routing purposes. This is a draft for comments and
suggestions.
1. Standard Fidonet Addressing
------------------------------
Fidonet addressing uses the following format:
ZZ:NN/FF.PP@DO
where the fields refer to...
ZZ - Zone Number: The zone the node is part of.
Min: 1 Max: 32767
If 'ZZ:' is missing then assume 1 as the zone.
NN - Net Number: The network the node is a member of.
Min: 1 Max: 32767
Must be present.
FF - Node Number: The actual node number.
Min: -1 Max: 32767
Must be present.
PP - Point Number: If the system is a point rather than a node then
this is their point number off the node.
Min: 0 Max: 32767
If '.PP' is missing then assume 0 (ie not a
point) as the point number.
DO - Domain: The name of the 'Fidonet Technology Network'.
Maximum length of 8 characters. The domain
should not include periods, thus 'fidonet.org'
is invalid (should be fidonet).
If '@DO' is missing then fidonet can be assumed.
The following are all valid examples:
1:234/5.6@fidonet (a '5D' address) => 1:234/5.6@fidonet
2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
4:610/34 (a '3D' address) => 4:610/34.0@fidonet
123/45 (a '2D' address) => 1:123/45.0@fidonet
955:95/2@othernet (another FTN) => 955:95/2.0@othernet
2:259/-1 (node application) => 2:259/-1.0@fidonet
The limits on each various part of the address are a result of
fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
(-1 node address for node application).
2. Internet Gateway Addressing
------------------------------
An internet user can send email/netmail to a fidonet user via one of
the fidonet->internet gateway systems (it's out-with the scope of
this document to describe the semantics of posting). The internet
user would send an email to a Fidonet user by using an email address
of the following syntax:
user.name@pPP.fFF.nNN.zZZ.gateway.domain
where the fields refer to...
user.name - Name: Name of the user the email is being sent
to, spaces replaced by periods.
PP - Point Number: As Fidonet address (FA)
If '.pPP' is missing 0 is assumed.
FF - Node Number: As FA
Must be present.
NN - Net Number: As FA
Must be present.
ZZ - Zone Number: As FA
Must be present.
gate.way - Gateway: Internet domain of the gateway, for
example 'fidonet.org'.
Must be present.
The following are all valid examples (assuming 'fidonet.org' is an
internet gateway):
joe.bloggs@p6.f5.n234.z1.fidonet.org => 1:234/5.6@fidonet
harry.cat@p78.f6.n34.z2.fidonet.org => 2:34/6.78@fidonet
i.be.jolly@f34.n610.z4.fidonet.org => 4:610/34.0@fidonet
and if 'foo.bar.org.uk' is a gateway for 'othernet':
louise.hat@f2.n95.z955.foo.bar.org.uk => 955:95/2.0@othernet
3. Routing Address Syntax
-------------------------
The two previous address types (Fidonet and Internet->Fidonet
gateway) are common practice, this however is a suggested standard
of addressing for routing tables. The routing address has the
following syntax:
DD:ZZ:RR:NN:HH:FF:PP
where the fields refer to:
DD - Domain: As FA
Must be present, even if blank (ie a leading
':') to ensure we always have 6 ':'s in an
address to aid pattern matching.
ZZ - Zone Number: As FA
Must be present.
RR - Region Number: The region (from fts-0005 nodelist) that the
following network is in.
Min: 1 Max: 32767
Must be present.
NN - Net Number: As FA
Must be present.
HH - Hub: The hub (from fts-0005 nodelist) that the node
is under, or 0 (host hub).
Min: 1 Max: 32767
Must be present.
FF - Node Number: As FA
Must be present.
PP - Point Number: As FA
Must be present.
':' has been chosen as the separator as it is not a POSIX regular
expression character or globing character (where as '.' is) and thus
always easy use of wildcards on the address. The following points
should be noted:
1. All addresses have 6 ':'s
2. The domain is at the front, the address gets more specific to
the right
3. Nodes have 0 as their point number
4. A zone net has identical zone, region and net fields
5. A region net has identical region and net fields
Example fidonet addresses converted to routing addresses:
fidonet:2:25:259:0:7:0 => 2:259/7.0@fidonet, region 25, hub 0
fidonet:1:1:1:0:23:0 => 1:1/23.0@fidonet, zone 1 net
:955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
cnet:12:34:341:100:1:7 => 12:341/1.7@cnet, region 34, hub 100
:2:25:259:300:300:0 => 2:259/300.0, region 25, hub 300
Example POSIX regular expression patterns on routing addresses:
[a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
[a-z]*(:[0-9]+)+ (any address)
fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
fidonet:2:25(:[0-9]+)+ (region 25 node)
fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
fidonet:1:12:125:[0-9]+:(25|34|56):0
(nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
Example 'DOS style' patterns on routing addresses:
*:*:*:*:*:*:* (any address)
fidonet:2:25:*:*:*:* (region 25 node)
fidonet:1:12:125:*:*:* (all net 1:125 nodes)
fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
fidonet:1:12:125:200:2:* (all 1:125/2 points)
fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
The standard doesn't define which standard of pattern matching to
use, only the format of the addresses. These routing addresses would
be used in routing tables and configurations.
A. Author contact data
----------------------
Lee Kindness
Fidonet: n/a
E-mail: wangi@earthling.net
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
B. History
----------
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
article. Transformed into FSP document by Odinn
Sorensen.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

450
html/ftsc/fsp-1005.html Executable file
View File

@ -0,0 +1,450 @@
<HTML>
<HEAD>
<TITLE>Zone 2 nodelist flags.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1005
Revision: 6
Title: Zone 2 nodelist flags
Author: Frank Ellermann, 2:240/5815.1
Revision Date: 27 November 1997
Expiry Date: 27 November 1999
---------------------------------------------------------------------
Contents:
1. Introduction
2. FTS-0005 flags
3. User flags
4. Approved zone 2 user flags
5. Flag implications
6. Invalid combinations
7. Baud rate field
8. Thanks to...
---------------------------------------------------------------------
1. Introduction
---------------
This document informs about known differences of FidoNet zone 2
nodelist flags from FTS-0005.003. The ultimate sources for these
informations are the current Z2 nodelist epilogue and the setup
for flag corrections at Z2C, but it may be difficult to get these
sources for readers in other zones.
| All changes since version 5 are marked by a bar at the left edge.
It is (again) possible to list V32b and V42b in zone 2, upper case
V32B or V42B is not more enforced. Currently new flags needed for
IP-connectivity are under test in zone 2 (only internally), e.g.
-> VM VModem, default port 3141, dummy country code 000-
-> IFC IFCico, default port 60179, dummy country code 000-
-> BND BinkP, default port 24544, dummy country code 000-
-> IP general IP connectivity, dummy country code 000-
-> TELN Telnet dummy country code 000-
2. FTS-0005 flags
-----------------
The following flags are used as specified in FTS-0005.003:
CM Continuous Mail, node accepts mail 24 hours a day
MO Mailer Only (no BBS)
LO Listed Only, node accepts calls only from listed
node numbers in the current FidoNet nodelist
-> V21 ITU-T V21 300 bps full duplex (obsolete)
V22 ITU-T V22 1200 bps full duplex (obsolescent)
| In zone 2 the value 1200 in the baud rate field implies V22. Only
| two nodes not supporting at least V22bis, ISDN, or IP still exist
| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
| already removed in Z2. Both flags should be dropped from the next
| FTS-0005 version.
V29 ITU-T V29 9600 bps half duplex (obsolescent)
-> V33 ITU-T V33 14400 bps half duplex (obsolete)
V33 cannot be used in connecting FidoNet nodes over public dial-up
lines and is most probably a historical error in FTS-0005. A very
similar argument is applicable on V29, all nodes flying this flag
support at least V32. Today only one node in Z2 still flies V29,
and V33 is already removed in Z2. Both flags should be dropped in
the next FTS-0005 version.
V32 ITU-T V32 9600 bps full duplex
V32b ITU-T V32bis 14400 bps full duplex (implies V32)
| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
FTS-0005 specifies V32b and V42b (capital V and small b), current
nodelist practice in FidoNet shows all combinations of small and
capital letters for flags. This was no problem before FSC-0062
introduced case-sensitive flags. The best solution is to stick to
the current practice and treat all old flags as case-insensitive.
H96 Hayes V9600
HST USR Courier HST up to 9600 (implies MNP)
H14 USR Courier HST up to 14400 (implies HST)
-> H16 USR Courier HST up to 16800 (implies H14 and V42b)
MAX Microcom AX/96xx series (almost obsolete)
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
-> ZYX Zyxel series 16800 bps (implies V32b and V42b)
-> V32T V.32 Terbo 19200 bps (implies V32b)
VFC V.Fast Class 28800 bps (should imply V32b and V42b)
If a flag directly or indirectly implies other flags, then these
other flags are not shown in a nodelist entry, because this would
be redundant. Unfortunately the rules for redundancies in zone 2
and FTS-0005 are different. Zone 2 continued to avoid redundancy
with most "new" flags, but FTS-0005.003 specified no redundancies
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
context are flags approved by FidoNet International Coordinators
since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
was published.
For details see the chapter "implications" below, for now only
note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b,
and V32T implies V32b.
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
corresponding Zone Coordinator. User flags are discussed later,
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
for all Zyxel protocol speeds.
Today only one node in FidoNet still really flies MAX, this flag
is obsolete and should be dropped from FTS-0005. The flags CSP
(7 nodes worldwide) and H96 should be marked as obsolescent.
| MNP Microcom Networking Protocol 2-4 error correction
| V42 ITU-T LAP-M error correction w/ fallback to MNP 2-4
| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
The next version of FTS-0005 should adopt the better V42b and
MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
specifies an implication of V42 by V42b, but the exact meaning of
the flag MNP is unclear. Most probably this flag was meant to
| indicate support of MNP 2-4, and in this sense V42 implies MNP.
| Note the difference between the flag V42b (implying V42) and the
| standard V.42bis (not necessarily based on LAP-M as data link
| layer protocol), without this difference the flag V42b would be
| ambiguous for combined modem and ISDN node entries.
MN No compression supported in insecure inbound
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
XC Bark file requests, WaZOO file/update requests
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
XX WaZOO file/update requests
These flags are equivalent in FTS-0005 and in the zone 2 segment.
Gx..x Gateway to domain 'x..x'
Valid values for this flag are assigned by the Fido International
Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
only GUUCP gateways are flagged.
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
#20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
The variants !01, !02, !08, !09, !18, and !20 indicate missing
Bell 212A support. In zone 2 #02 or !02 would be obviously
redundant.
Today less than four 1200 modems (V22 or Bell 212A) are listed.
A future version of FTS-0005 should drop !mn variants together
with V21 and V22 flags.
Further most non-CM systems flagging #mn or !mn today probably
want to show additional online times instead of additional mail
hours. As soon as FSC-0062 flags have been approved by the IC
or adopted as FTS by the FTSC, the following version of FTS-0005
should mark #mn as obsolescent and recommend the more flexible
FSC-0062 flags (see below).
3. User flags
-------------
An example for one of several problems in zone 2 with user flags:
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
These flags indicate a modern Zyxel ISDN-modem and two additional
user flags ENC and NEC. This possible user flags string contains
34 characters, but at most 32 characters are allowed in FTS-0005.
...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
During the period for the replacement of old by new ISDN flags
(several months !) many nodes listed both old and new flags for
maximal compatibility, and no problems with nodelist compilers
or mailers caused by too long user flags strings were reported.
Therefore the length limit in FTS-0005 is probably unnecessary
and at least inconsequent: Other nodelist fields like the system
name are unlimited, so why only restrict the user flags string ?
To help developpers an upper limit of e.g. 255 characters for a
nodelist line and 63 characters for fields 3 to 6 would be more
useful.
The next problem with user flag strings as specified in FTS-0005
is their introduction by the letter U with no comma following:
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
and USR. But USR cannot be approved as "real" flag, because the
combination ...,USR,UISDN would then be parsed in SR and UISDN.
Other side effects of the FTS-0005 specification are additional
difficulties in finding flags. Almost all flags are separated
by a comma, only the first user flag can be an exception to this
simple rule. If the order of user flags has no meaning, then...
...,UV120L,V120H
...,UV120H,V120L
... are equivalent. A "simple" solution of this problem could be
to treat UV120L as synonym for V120L, and UV120H as synonym for
V120H. Similar problems show up, if user flags are counted, etc.
Obviously a nodelist compiler looking for user flags has always
to consider the case "user flag separated by comma". In zone 2
this idea was simply extended to the first user flag:
All flags are separated by commas. Flags not yet approved by the
International Coordinator or the FTSC (i.e. user flags only used
experimentally or locally) are separated by a new pseudo flag U.
-> U pseudo flag to the left of at least one user flag
All flags following this pseudo flag U are user flags, all flags
before this pseudo flag are "real" flags specified in FTS-0005 or
approved by the International Coordinator.
Because this definition should be compatible with any reasonable
software implementation based on FTS-0005.003, and simplifies the
handling of user flags significantly, a future FTS-0005 version
will hopefully adopt it.
4. Approved zone 2 user flags
-----------------------------
In zone 2 user flags have to be approved by the Zone Coordinator.
Currently the following zone 2 user flags exist:
-> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
-> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
-> X75 ITU-T X.75 SLP (single link procedure),
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
window size W = 2, frame numbering modulo 8;
layer 3 transparent (no packet layer)
-> ISDN Other configuration, used only if none of above fits
These ISDN flags follow the specification in FSC-0091.
-> Tyz Online time flags as specified in FSC-0062
The flag Tyz is used by non-CM nodes online not only during ZMH,
y is a letter indicating the start and z a letter indicating the
end of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
-> Z19 Zyxel series 19200 bps (implies ZYX)
-> X2C x2 client w/ 56000 bps (should imply V34 and V42b)
-> X2S x2 server w/ 64000 bps (should imply V34 and V42b)
-> K12 Systems offering all educational K12-conferences
-> ENC The node accepts inbound encrypted mail
-> NC Network Coordinator (only if the NC is not the host)
-> NEC Net Echomail Coordinator (at most one per net)
-> REC Region Echomail Coordinator (at most one per region)
Redundant AKAs used to indicate echomail coordination in zone 2
are no longer permitted. One *EC flag is valid for all AKAs of
a given sysop.
5. Flag implications
--------------------
Flag implications directly or indirectly specified in FTS-0005:
HST => MNP
H14 => MNP HST
H16 => MNP HST H14
V42b => V42 (MNP ?)
V32b => V32
Flag implications specified in the zone 2 nodelist epilogue:
HST => MNP
H14 => HST MNP
-> H16 => V42 MNP V42b H14 HST
-> V42b => V42 MNP
-> ZYX => V42 MNP V42b V32 V32b
-> Z19 => V42 MNP V42b V32 V32b ZYX
V32b => V32
-> V32T => V32 V32b
-> V110L => ISDN
-> V110H => ISDN
-> V120L => ISDN
-> V120H => ISDN
-> X75 => ISDN
The latter ISDN flag redundancies are a consequence of FSC-0091.
Maybe some of the following implications could be added in zone 2:
VFC => V32 V32b MNP V42 V42b
X2C => V34 MNP V42 V42b
X2S => V34 MNP V42 V42b
Flag implications (i.e. not listing redundant flags) have several
advantages: Some old nodelist tools are unable to handle too long
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
if they are implied by H16, V42b, V32b, or better. Redundancies
defined globally for the whole nodelist help to avoid flag errors.
6. Invalid combinations
-----------------------
All file request flags exclude each other (at most 1 is possible):
XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting
implications a good approximation based on FTS-0005 definitions is
| XA => XW XR XP XB XC XX,
| XB => XW XR XP,
| XC => XW XR XX,
| XR => XW,
| XX => XW.
Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are
not possible with CM. Also Tyz with y = z is of course incorrect.
Some modem protocols are "proprietary" in a sense, that all today
known modems can fly at most one of the corresponding modem flags:
MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
A few "old" modem protocol flags are known to be invalid if used
together with "new" protocol flags, i.e. each "old" flag excludes
all "new" flags and vice versa:
"Old" in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.
"New" in this sense are X2S, X2C, V34, VFC, V32T, and H16.
For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
test some known inconsistencies is available as NLSCHECK.REX at
the site of the author. While erroneously listing redundant flags
causes no harm, other errors like combining V34 with HST or Z19
with H16 indicate serious problems, which can result in connection
failures or other damage.
7. Baud rate field
------------------
The baud rate field 7 in the nodelist as specified in FTS-0005 is
nearly useless today: Except from a few remaining 1200 and 2400
nodes almost all nodelist entries show either 9600 for all modem
protocols better than V22bis or 300 for ISDN (or IP) only nodes.
No more V21 or Bell 103 modems are listed for more than 2 years.
The baud rate values 19200 and 38400 specified in FTS-0005.003
have not been used in the FidoNet nodelist. So all a reasonable
nodelist compiler can do today, is treat 300 as indicator for
ISDN or IP only, and treat unknown or missing values in field 7
like 9600.
A new meaning for field 7 as speed field could be really useful.
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
as speed values, then their combination with ZYX is all we need
technically, Z19 would be unnecessary. Another example is HST,
flags H14 and H16 are unnecessary, if HST is combined with 9600,
14400, 16800, 28800, or better. Variants of PEP could be shown in
the speed field without new flags. "Enhanced V32.terbo" could be
shown by 21600.
Most important: V34 may have the famous bug not allowing connects
from new "V34+", unless the caller disabled symbol rate 3429. If
"V34+" is indicated by speed 33600 or better, then an appropriate
setup for all kinds of V34 connects is possible.
A future version of FTS-0005 hopefully allows the following speed
values in field 7:
300 reserved for ISDN or IP only (for historical reasons)
1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
2400 implies V22bis, qualifies as least common denominator
9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
12000 rare variant of V32
14400 used with V32b or HST (obsoleting H14)
16800 used with ZYX or HST (obsoleting H16)
19200 used with V32T or ZYX (obsoleting Z19)
21600 rare variant of V32T (no "H21" needed)
28800 used with VFC or V34
33600 used with V34 (no V34+ or V34b needed)
| 56000 used with X2C, X2S, or V.PCM
Allowing more than 12 speed values or allowing speed values above
64000 could break existing software (MakeNL, V7). Therefore the
next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
21600, 28800, 33600, and 56000, where 19200 is already specified
in FTS-5 since 1989.
8. Thanks to...
---------------
Ben Baker St. Louis nodelist format
Rick Moore FTS-0005.TXT
David Nugent FTS-0005.003 and NLTOOLS
Jonny Bergdahl ERRFLAGS 2.6
Ward Dossche Zone 2 nodelist epilogue
David J. Thomas FSC-0062.003 (FRL-0062)
Jan Ceuleers FSC-0075.001 (FRL-0075)
Arjen Lentz FSC-0091.001 (FRL-0091)
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
Jim Barchuk LNDL 2.7
Marius Ellen FASTV7 2.04
| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

159
html/ftsc/fsp-1006.html Executable file
View File

@ -0,0 +1,159 @@
<HTML>
<HEAD>
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1006
Revision: 1
Title: Kludge for specifying addition e-mail reply addresses
Author: Ramon van der Winkel, 1:320/42.46
ramon@wsd.wline.se
Revision Date: 12 December 1997
Expiry Date: 12 December 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Background
3. Format
4. Implementation notes
5. Example
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
An Internet message can have several reply addresses. After gating
to FidoNet, the recipient is only presented with one of the reply
addresses. The others are lost. This is a suggestion for an
additional kludge to FSC-0035 to change that.
1. Scope
--------
This standard is specified for FTN netmail messages sent by a
FidoNet-to-Internet gateway to a recipient. Message editors will
have to support this to allow the user to select the reply address
to use.
2. Background
-------------
An Internet message has three headers to indicate where to send a
reply. These are, in order of priority, Reply-To:, Sender: and
From:. When a message is distributed by a mailing list, then one of
the headers could contain the e-mail address of the poster and one
of the other headers the address of the mailing list.
When the message is gated to FidoNet, the gateway currently selects
of the reply addresses and creates the message so that a reply will
return at the gateway and sent to this one address. The other
addresses are lost.
The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
address only. This is a proposal for an additional kludge inserted
by the gateway to specify an addtional reply address. The message
editor used by the recipient will present a list of all reply
addresses and allows the user to select the appropriate address.
This way, the user can send a message back to the mailing list (for
distribution), or to the e-mail address of the poster only.
3. Format
---------
Following the REPLYTO and REPLYADDR kludges, one or more kludges
with the name REPLYALSO can be inserted, each listing one possible
reply address.
@REPLYALSO <e-mail address>
Where <e-mail address> is in the form of
ramon@wsd.wline.se
or
wsd.wline.se!ramon
Each line MUST contain one address only.
4. Implementation notes
-----------------------
Gateways supporting the REPLYALSO kludge MUST put the the reply
address with the highest priority in the REPLYADDR kludge. The order
of priority is Reply-To:, Sender: and From: header. The other
addresses may be listed in any priority.
5. Example
----------
From: odinn@goldware.dk, 1:320/42
To: Ramon van der Winkel, 1:320/42.46
Subj: Another test
---------------------------------------
@INTL 1:320/42 1:320/42
@TOPT 46
@MSGID: wgmid$<123455@goldware.dk> 45AB23CD
@REPLYTO UUCP 1:320/42
@REPLYADDR odinn@goldware.dk
@REPLYALSO newftsc-l@brazerko.com
This message was distributed by the mailing list "New FTSC"
at brazerko.com.
...
A. Author contact data
----------------------
Ramon van der Winkel
Fidonet: 1:320/42.46
E-mail: ramon@wsd.wline.se
WWW: http://www2.sbbs.se/hp/ramon
B. History
----------
Rev.1, 971212: First release.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

162
html/ftsc/fsp-1007.html Executable file
View File

@ -0,0 +1,162 @@
<HTML>
<HEAD>
<TITLE>Multiple recipient address specification to gateway.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1007
Revision: 1
Title: Multiple recipient address specification to gateway
Author: Ramon van der Winkel, 1:320/42.46
ramon@wsd.wline.se
Revision Date: 12 December 1997
Expiry Date: 12 December 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Background
3. Format
4. Implementation notes for gateways
5. Example
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
Private messages within FidoNet only have one recipient address.
Multiple copies of the same message have to be sent to a FidoNet-
to-Internet gateway in order to address multiple recipients. This is
a proposal to indicate the addresses of multiple recipients in the
body of the message sent to the gateway.
1. Scope
--------
This standard is specified for FTN netmail messages sent to a
FidoNet-to-Internet gateway. Users are able to add this information
manually, although message editors could support this and make it
transparent to the user.
2. Background
-------------
Three types of recipient addresses can be specified on the Internet
and are reflected in this suggestion: To, Cc and Bcc. "To" are the
primary recipient(s) of the message. "Cc" is short for Carbon Copy
and lists the recipients that are intended to receive the message as
"informational". The last option "Bcc" is short for Blind Carbon
Copy. Recipients lists as Bcc recipients will not show up in the
headers of the Internet message, but get a copy anyway.
3. Format
---------
Immediately following the kludge lines, one or more of the following
lines can be inserted in the message. If a To: line is present, then
these lines follow the To: line.
GW-To: <e-mail address>[,<e-mail address>[...]]
GW-Cc: <e-mail address>[,<e-mail address>[...]]
GW-Bcc: <e-mail address>[,<e-mail address>[...]]
Where <e-mail address> is in the form of
ramon@wsd.wline.se
or
wsd.wline.se!ramon
Multiple addresses can be specified on the same line, separated by a
comma with optionally spaces around the comma. There is no limit
regarding the length of the line. The line must be terminated by a
single carriage return.
The GW-To: line replaces the To: lines.
The reason for GW-Cc is that "Cc:" by itself is expanded by some
editors and used to generate multiple copies of a message.
4. Implementation notes for gateways
------------------------------------
Gateways supporting this format add the e-mail addresses mentioned
in any of these three headers to the envelope file and create on
outbound (probably UUCP or SMTP) body text message. Rules for the
maximum length of envelope files (if any) apply.
The headers section of the RFC822 message will list the e-mail
addresses under the To: and Cc: headers. A Bcc: header must not be
added!
5. Example
----------
From: Ramon van der Winkel, 1:320/42.46
To: UUCP, 1:320/42
Subj: New header test
---------------------------------------
@INTL 1:320/42 1:320/42
@FMPT 46
GW-To: groupElist@newftsc.org
GW-Cc: odinn@goldware.dk
GW-Bcc: groupAadmin@newftsc.org
Hi!
This is a test
Ramon
A. Author contact data
----------------------
Ramon van der Winkel
Fidonet: 1:320/42.46
E-mail: ramon@wsd.wline.se
WWW: http://www2.sbbs.se/hp/ramon
B. History
----------
Rev.1, 971212: First release.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

275
html/ftsc/fsp-1008.html Executable file
View File

@ -0,0 +1,275 @@
<HTML>
<HEAD>
<TITLE>New control lines for forwarding messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1008
Revision: 2
Title: New control lines for forwarded messages
Author: Michael Hohner, 2:2490/2520.17
Revision Date: 29 December 1997
Expiry Date: 29 December 1999
----------------------------------------------------------------------
Contents:
1. Specifications
2. Usage
3. Compatiblity
4. Known implementations
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
This revision is an update to FRL-0092.001. The basic specifications
are unchanged.
Abstract
--------
Most fidonet message editors offer a "forward" function. Using this
function a user A ("forwarder") can sort of "redirect" a message
from user B ("author") to another user C ("final recipient"), maybe
because the forwarder is not the correct recipient, or because the
final recipient is a better person to answer the message. The name
and address of the author are usually included in the forward in
free-text format. The message text is included in non-quoted format.
A problem arises when the final recipient wants to reply to the
author of the forwarded message. The forward contains the forwarder
as the sender. So the final recipient must insert the name and
address of the author manually, using the information contained in
the message text. The message editor of the final recipient can't do
this automatically because of the free-text format. The editor will
also use incorrect quote initials, which is at least irritating.
This document introduces 7 new control lines which contain the
header information of the original message. With these control lines
the message editor can use the original header information
automatically.
1. Specifications
-----------------
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
ASCII 01 character (SOH) followed by the control line name followed
by whitespace followed by the control line's content followed by
ASCII 13 (CR).
Please note that all these control lines do not have a colon (like
the control lines in FTS-0001). This would be just waste of space.
FWDFROM
-------
This control line contains the name of the original sender as found
in the FROM field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the FROM field is empty.
FWDTO
-----
This control line contains the name of the original recipient as
found in the TO field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the TO field is empty.
FWDORIG
-------
This control line contains the address of the original sender as
found in the ORIG field of the original message. The usual 5D ASCII
notation (zone:net/node.point@domain) should be used. This control
line should be omitted altogether if the address is not known.
FWDDEST
-------
This control line contains the address of the original recipient as
found in the DEST field of the original message. The usual 5D ASCII
notation (zone:net/node.point@domain) should be used. This control
line should be omitted altogether if the address is not known or
unsure (as it is the case with forwarded echomail messages).
FWDSUBJ
-------
This control line contains the subject line of the original message.
This control line should be omitted altogether if the SUBJ field is
empty.
This control line should by made optional for security reasons. Echo
manager passwords are too easily revealed with it.
FWDAREA
-------
This control line contains the name of the echomail area where the
original message was forwarded from. It should be omitted altogether
if the original message was not forwarded from an echomail area.
FWDMSGID
--------
This control line contains the MSGID control line of the original
message. It should be omitted altogether if a MSGID control line is
not present in the original message.
2. Usage
--------
When the "forward" function of the message editor is invoked, the
editor program should generate the proposed control lines from the
header of the original message. If the original message already was
a forwarded one (indicated by the presence of at least a FWDORIG
control line), the editor should keep all FWD* control lines and
should not add any FWD* control lines. This preserves the FWD*
control lines of the first forwarder, containing the header data of
the author of the original message.
The editor should not generate FWD* control lines, if the message
isn't to be forwarded. A mail forwarding robot may also generate
these control lines, if it not just readdresses the message.
When the "reply" function of the editor is invoked the program
should use the control lines' contents instead of the header
information. The control lines should not be included in the reply.
Since it may not be immediately clear whether the user wants to
reply to the forwarder or to the original sender, the editor should
offer a means to ignore the proposed control lines and start a
"normal" reply instead, e.g. by two distinct functions, by user
preference or a dialog.
Pseudo code:
forwarding_message:
if is_forwarded_message then
don't change FWD* control lines
else
add FWD* control lines
quoting_message:
if is_forwarded_message then
if reply_to_forwarder then
use header data (normal quoting)
else
use FWD* control lines
remove FWD* control lines from reply
else
use header data (normal quoting)
other_functions:
remove/ignore FWD* control lines
Example:
Message from Joe User to my boss node:
From: Joe User 1:234/567
To: Harry Herrmannsdoerfer 2:2490/2520
Subj: Some questions
@MSGID: 1:234/567 12345678
Text: Hello Harry!
...
Harry forwards the message to me:
From: Harry Herrmannsdoerfer 2:2490/2520
To: Michael Hohner 2:2490/2520.17
Subj: Joe's message
@FWDFROM Joe User
@FWDORIG 1:234/567
@FWDTO Harry Herrmannsdoerfer
@FWDDEST 2:2490/2520
@FWDSUBJ Some questions
@FWDMSGID 1:234/567 12345678
Text: Hi Michael!
...
My answer using the new control lines:
From: Michael Hohner 2:2490/2520.17
To: Joe User 1:234/567
Subj: Some questions
@REPLY: 1:234/567 12345678
Text: Hi Joe!
JU> ...
...
3. Compatiblity
---------------
Editor programs which are not prepared for these proposed control
lines usually just ignore them and remove them from a reply. A reply
goes to the forwarder. Nothing gained and nothing lost.
4. Known implementations
------------------------
This proposal is implemented in the author's Fidonet editor
"FleetStreet for OS/2" (versions 1.17 and newer).
Also implemented in Odinn Sorensens Fidonet editor "GoldED"
(versions 3.00.Alpha5 and newer).
A. Contacting the author
------------------------
The author may be contacted electronically at the following
addresses:
Fidonet: 2:2490/2520.17
Internet: miho@osn.de
Suggestions, comments and corrections are always welcome.
B. History
----------
Rev.1, 19960912: First release as FSC-0092.001.
Rev.2, 19971229: Submitted as FSP.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

142
html/ftsc/fsp-1009.html Executable file
View File

@ -0,0 +1,142 @@
<HTML>
<HEAD>
<TITLE>Year 2000 issues in FTN software.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1009
Revision: 1
Title: Year 2000 issues in FTN software
Author: Michael Hohner, 2:2490/2520.17
Revision Date: 29 December 1997
Expiry Date: 29 December 1999
----------------------------------------------------------------------
Contents:
1. Introduction
2. Generating Fidonet timestamps
3. Interpreting Fidonet timestamps
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
The year 2000 causes problems in many computer programs which use
two-digit year numbers. Current Fidonet software faces the very same
problems. This FSP specifies procedures which enable FTN software to
run without problems after the year 2000.
1. Introduction
---------------
Software using two-digit year numbers may cause problems in the year
2000. When the year number rolls over from "99" to "00", some
software may interpret the resulting year number as "1900" instead
of "2000". Such programs may contain code like this:
calendar_year = year_number + 1900; /* wrong! */
Fidonet software faces the very same problem: the year number in
packed messages (see FTS-0001) has only two digits. Some programs
interpreting this number incorrectly may decide that messages from
the year 1900 are too old and discard them. Other programs probably
just display a wrong calendar year.
The long-term solution would be a transition to four-digit year
numbers. However, this would require new data formats and cause
every existing software to fail. So a short-term solution is
required, resulting in only minimal changes in software. This FSP
contains guidelines for proper year-number interpretation. The
author encourages all FTN software authors to check their software
for possible year-2000 problems (and release fixed versions during
the next three years).
2. Generating Fidonet timestamps
--------------------------------
This should not cause much headache. However, some software may use
the following algorithm:
year_number = calendar_year - 1900 /* wrong! */
This will result in a three-digit year number in 2000 and lead to
incorrect Fidonet timestamps.
One correct algorithm is:
year_number = calendar_year mod 100 /* correct! */
3. Interpreting Fidonet timestamps
----------------------------------
We can make use of the fact that Fidonet didn't exist before 1980,
i.e. no messages were created before 1980. So any year number
smaller than 80 can't mean "year 19xx", but can only mean "year
20xx". One algorithm for correct year number interpretation is:
if year_number < 80 then
calendar_year = 2000 + year_number
else
calendar_year = 1900 + year_number
Fidonet software should only use the calendar year for further
processing, not the year number from the timestamp.
This solution will work until 2080, giving us another 80+ years to
finally let some innovation happen in Fidonet.
A. Contacting the author
------------------------
The author may be contacted electronically at the following
addresses:
Fidonet: 2:2490/2520.17
Internet: miho@osn.de
Suggestions, comments and corrections are always welcome.
B. History
----------
Rev.1, 19971229: Submitted as FSP.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

242
html/ftsc/fsp-1010.html Executable file
View File

@ -0,0 +1,242 @@
<HTML>
<HEAD>
<TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1010
Revision: 1
Title: Via kludge specification
Author: Colin Turner,
Joaquim Homrighausen
Revision Date: 26 April 1999
Expiry Date: 26 April 2001
----------------------------------------------------------------------
Contents:
1. Current practice
2. Kludge specification
3. Examples
4. Deprecated formats
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
Current practice for Fidonet Technology Network (FTN) NetMail
messages is to track their progress through the network and
programs by using control lines. These control lines are in
the form of a kludge named Via.
1. Current practice
-------------------
As NetMail messages are routed through a FidoNet Technology Network
or as they are processed on a system, Via control lines are used to
track their progress.
A single NetMail message may have any number of Via control lines.
The Via control lines are stored in a block which starts after any
message text. New Via lines should be added to the end of the block
separated from the preceding control line by a single ASCII &lt;CR&gt;
character (0Dh).
A Via control line is typically added:
when a netmail packer packs the NetMail for transmission to
another system;
when a netmail tracker inspects a NetMail.
2. Kludge specification
-----------------------
The Via control line is formatted as a number of fields, separated
by single space (20h) characters, as follows
^AVia: &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; is the
character (0Dh).
The fields are defined as follows:
FTN Address
-----------
This field is mandatory and is the FidoNet Technology address of
the system inserting the kludge. This may or may not include a
domain indicator.
@YYYYMMDD.HHMMSS
----------------
This field is mandatory and consists of a time stamp. This is the
time at which the stamp was placed. The subcomponents are
YYYY, the calendar year, in full four digit, decimal form;
MM, the calendar month, in the range 01 to 12, this must be a
zero padded, two digit decimal number;
DD, the day of the month, in the range 01 to 31, this must be a
zero padded, two digit decimal number;
HH, hours, in the range 00 to 23, this must be a zero padded,
two digit decimal number;
MM, minutes, in the range 00 to 59, this must be a zero padded,
two digit decimal number;
SS. seconds, in the range 00 to 59, this must be a zero padded,
two digit decimal number.
Precise
-------
This field is optional and takes the form of extra precision in the
time stamp.
If this field is present:
it must begin with a single period character;
this period must be followed by one or more decimal digits;
the field has ended when another period or space is encountered;
each decimal digit in the field following this character
represents the time of the via line in fractions of a second,
such that the the first digit represents tenths of a second,
the second digit represents hundreds of a second and so on.
Time Zone
---------
This field is optional, and must be a short, widely accepted
alphabetical abbreviation of the time zone that the time stamp
in the Via line pertains to.
The use of various Time Zone values is deprecated, implementations
should attempt to convert the timestamp in the kludge to Universal
Time (GMT or UTC) and use the &quot;UTC&quot; Time Zone indicator, where
possible.
The Time Zone field may only be ommitted when it is not possible
for the implementation to determine the correct offset from UTC,
and in this case the time stamp must represent local time on the
generating system.
Program Name
------------
This field is mandatory, and must follow the format used in the PID
control line (detailed in FSC-46).
Version
-------
This field is mandatory, and must follow the format used in the PID
control line (detailed in FSC-46).
Serial Number
-------------
This field is optional, and must follow the format used in the PID
control line (detailed in FSC-46).
Note that unlike many kludges, the &quot;Via&quot; text of the kludge itself
is in mixed, and not all upper case.
3. Examples
-----------
Example of valid usage are
^AVia 2:443/13 @19990305.043212.UTC O/T-Track+ 2.69
^AVia 2:443/13@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
^AVia 2:443/13 @19990323.230132 FakeMail 1.2
^AVia 2:2480/18@fidonet @19990307.182128.47.UTC ITrack+ 1.3/G6 FP000069
4. Deprecated formats
---------------------
Some other formats for the Via line are in use today, but these
formats are rather variable and inconsistent in nature, while
the format specified above is both more widespread and more
consistent.
New implentations may need to parse these formats, but must not
generate them.
The formats in use include, but are not limited to
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
Not that the time stamp in the above formats is also widely
variable, and takes forms which include, but may not be limited to
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]
&lt;Day of Week&gt; &lt;Month&gt; &lt;Day of Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;
@YYMMDDHHMMSS
In the last listed format, observe in particular the two digit year
and lack of period to seperate the date from time.
A. References
-------------
[FTS-1] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy
Bush. September 1995.
[FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,
Joaquim Homrighausen, August 1994.
B. Author contact data
----------------------
Colin Turner
Fidonet: 2:443/13
E-mail: ct@piglets.com
WWW: http://www.piglets.com
Joaquim Homrighausen
Fidonet: 2:201/330
E-mail: joho@defsol.se
WWW: http://www.defsol.se
C. History
----------
Rev.1, 990426: First release.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>

1756
html/ftsc/fsp-1011.html Executable file
View File

File diff suppressed because it is too large Load Diff

268
html/ftsc/fta-1005.html Executable file
View File

@ -0,0 +1,268 @@
<HTML>
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTA-1005
Revision: 3
Title: FTSC Product Codes
Author: Administrator
Revision Date: 22 March 1998
Expiry Date: 22 March 1998
----------------------------------------------------------------------
Contents:
1. Format of product code list
2. Application for a product code
----------------------------------------------------------------------
1. Format of product code list
------------------------------
The FTSC publishes a list of all product codes issued. The filename
is FTSCPROD.nnn, where nnn is a number which increases with each
revision.
The list is an ASCII text file with one line per product. Each line
contains a number of fields, delimited by commas. Some fields may
contain more than one value. In this case, the different values are
delimited with a forward slash ('/'). Spaces in fields are replaced
with underscores ('_'). Fields are not case-sensitive.
These are the fields which are currently defined:
code,name,platform,type,contact,netaddr[,assigned[,updated]]
code The product code. 4 digits hexadecimal.
name Product name.
platform Platforms(s) supported.
type Type(s) of product.
contact Name of contact person.
netaddr FidoNet address of contact person.
assigned Date the product code was originally assigned.
updated Date of last update of the product code data.
Platforms
---------
See the list for examples. (Will be specified more firmly later).
Product types
-------------
Mailer A mailer is a product that exchanges mail with FTS-0001,
FTS-0006, EMSI or other protocols that include a product
code field.
Packer A packer is a product that creates .PKT files.
Dates
-----
The format is YYYYMMDD. A date field may also be blank.
If you write software which is dependant on this format, please make
it tolerant of additional fields after these for upwards
compatibility.
2. Application for a product code
---------------------------------
FidoNet products without an allocated product code which either
create Type-2 packets, or negotiate FTS-0001 sessions must use a
product code FEh (254d) in Type-2 compatible packet headers. This
code as been reserved for that purpose (use by product without a
product code). The product code FFh (255d) has been reserved to
indicate that the product code is stored elsewhere in the packet
header at an as yet unallocated offset.
The FTSC is currently working on an update to the Type-2 packet
specification, to allow 16-bit codes while keeping full backward
compatibility with 8-bit codes (something which the current Type-2
proposals in the FSC's are not). Until the specification is ready,
16-bit codes are issued with the low byte set to FFh (255d).
Below is an application form for an FTSC product code, which is used
to identify your product when used in FidoNet, and providing a means
by which you can be contacted should your product be found
responsible for problems encountered during its use. The issuance of
this product code in no way implies authorisation or approval of
your product for use on the network, only provides a means of ready
identification.
This application should be completed and submitted for only `real'
and completed products which will be used by FidoNet systems. If you
are currently developing a product which is not yet ready for use on
the network out of experimental stage, use product code 0 (zero)
which is, by convention, reserved for this purpose.
Please answer the questions as accurately and completely as
possible. We need to know what will actually be used on the net, so
describe only the current product, and leave future features and
plans for the comments section.
Send the completed form to the administrator of the FidoNet
Technical Standards Committee. Please see FTA-1003 for addresses.
We hope that you will take the time to revise your answers by
submitting updates as your product changes. A summary of the
information you provide is compiled into a list of all product codes
published and updated periodically by the FTSC called
"FTSCPROD.nnn".
A. Application Form
-------------------
--- Cut along here ---------------------------------------------------
FTSC Product Code Application
=============================
Type of application
-------------------
1. Mark whichever is appropriate:
____ New product application
____ Update existing product for existing product code ____
2. If this is an update, please briefly state the nature of the
update (change author's node number, change of product name, etc.)
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
Product information
-------------------
3. What is the name of the product and the current version name or
number?
__________________________________________________________________
4. What is the name, FidoNet node, and postal address, and voice
number of the person(s) or organization responsible for the
product? Where should inquiries be directed and who should be
contacted if the product is thought to cause errors on the
network?
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
5. What operating systems does it currently run on?
__________________________________________________________________
6. Does the product contain a 'mailer'? E.g. the package transmits
mail to other FidoNet systems and can fall back to FTS-0001,
though it may handle other protocols.
__________________________________________________________________
7. If the answer to question (6) is yes, what additional protocols
other than FTS-0001 does the product support? Refer to the
specific FTSC document which details this protocol, if any.
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
With what additions or restrictions?
__________________________________________________________________
8. Is the package capable of servicing file requests, and if so,
'Bark' style (FTS-0008) and/or WaZOO .REQ (FTS-0006) or both?
__________________________________________________________________
With what additions or restrictions?
__________________________________________________________________
9. Is your software capable of functioning as a Continuous Mail
system? i.e. nodes running it might be marked as such in the
FidoNet nodelist?
__________________________________________________________________
10. How is the product distributed?
Public Domain ____________ Shareware ______________
Commercial ____________ Other ______________
Object code ____________ Source code ______________
Comments: ________________________________________________________
__________________________________________________________________
__________________________________________________________________
11. Please give additional comments to describe your product.
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
--- Cut along here ---------------------------------------------------
B. Acknowledgements
-------------------
The application form was inspired by one originally published in
FSC-0022 and later FSC-0090, originally by Bob Hartman, Jim Long,
and Randy Bush and modified by Rick Moore and David Nugent.
C. History
----------
Rev.1, 19970407: First non-draft release. Author Adrian Walker.
Rev.2, 19971229: Author changed to Administrator. Reformatted
document slightly. Changed all dates in the lists
to 4 digit centuries. Added information about
status of 16-bit product codes.
Rev.3, 19980322: Moved the product code list out of the document and
into a separate list, FTSCPROD.nnn. Added an
application form. Revised text about 16 bit codes.
**********************************************************************
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

1260
html/ftsc/fts-0001.html Executable file
View File

File diff suppressed because it is too large Load Diff

414
html/ftsc/fts-0004.html Executable file
View File

@ -0,0 +1,414 @@
<HTML>
<HEAD>
<TITLE>Echomail Specification.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
FTS-0004 EchoMail Specification
This document is directly derived from the documentation of
-------------------------------------------------------------------------------
The Conference Mail System
By
Bob Hartman
Sysop of FidoNet(tm) node 132/101
(C) Copyright 1986,87, Spark Software, Inc.
427-3 Amherst Street
CS 2032, Suite 232
Nashua, N.H. 03061
ALL RIGHTS RESERVED.
-------------------------------------------------------------------------------
version 3.31 of 12 December, 1987.
With Bob Hartman's kind consent, copying for the purpose of technological
research and advancement is allowed.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
WHAT IS THE CONFERENCE MAIL SYSTEM?
Conference Mail is a technique to permit several nodes on a
network to share a message base, similar in concept to the
conferences available on many of the computer services, but it is
most closely related to the Usenet system consisting of more than
8,000 systems world wide. All systems sharing a given conference
see any messages entered into the conference by any of the
participating systems. This can be implemented in such a way as
to be totally transparent to the users of a particular node. In
fact, they may not even be aware of the network being used to
move their messages about from node to node! Unfortunately, this
has its disadvantages also - most users who are not educated
about Conference Mail do not realize the messages transmitted
cost MANY sysops (system operators) money, not just the local
sysop. This is an important consideration in Conference Mail and
should not be taken lightly. In a conference with 100 systems as
participants the cost per message can get quite high.
The Conference Mail System is designed to operate in conjunction
with a FidoNet compatible mail server. The currently supported
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
the mail server is a prerequisite to using the Conference Mail
System, it will be assumed you already have your mail server
operating correctly on your system, and you are connected into
FidoNet or a compatible network.
HISTORY OF THE CONFERENCE MAIL SYSTEM
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
convenient means of sharing ideas with the other Dallas sysops.
He created a system of programs he called Echomail, and the
Dallas sysops' Conference was born.
Within a short time sysops in other areas began hearing of this
marvelous new gadget and Echomail took on a life of its own.
Today, a scant year and a half later, the FidoNet public network
boasts a myriad of conferences varying in size from the dozen-or-
so participants in the FidoNet Technical Standards Committee
Conference to the Sysops' Conference with several hundred
participants. It is not uncommon for a node to carry 30 or more
conferences and share those conferences with 10 or more nodes.
HOW IT WORKS
The Conference Mail System is functionally compatible with the
original Echomail utilities. In general, the process is:
1. A message is entered into a designated area on a FidoNet
compatible system.
2. This message is "Exported" along with some control information
to each system "linked" to the conference through the originating
system.
3. Each of the receiving systems "Import" the message into the
proper Conference Mail area.
4. The receiving systems then "Export" these messages, along with
additional control information, to each of their conference
links.
5. Return to step 3.
As you can see, the method is quite simple - in general. Of
course, following the steps literally would mean messages would
never stop being Exported and transmitted to other systems. This
obviously would not be desired or the network would quickly
become overburdened. The information contained in the 'control
information' section is used to prevent transmitting the same
message more than once to a single system.
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
There are five pieces of control information associated with a
Conference Mail message. Some are optional, some are not.
Normally this information is never entered by the person creating
the message. The following control fields determine how
Conference Mail is handled:
1. Area line
This is the first line of a conference mail message. Its
actual appearance is:
AREA:CONFERENCE
Where CONFERENCE is the name of the conference. This line is
added when a conference is being "Exported" to another
system. It is based upon information found in the AREAS.BBS
(configuration) File for the designated message area. This
field is REQUIRED by the receiving system to "Import" a
message into the correct Conference Mail area.
2. Tear Line
This line is near the end of a message and consists of three
dashes (---) followed by an optional program specifier.
This is used to show the first program used to add Echomail
compatible control information to the message. The tear line
generated by Conference Mail looks like:
--- <a small product-specific banner>
This field is optional for most Echomail compatible
processors, and is added by the Conference Mail System to
ensure complete compatibility. Some systems will place this
line in the message when it is first created, but it is
normally added when the message is first "exported."
3. Origin line
This line appears near the bottom of a message and gives a
small amount of information about the system where it
originated. It looks like:
* Origin: The Conference Mail BBS (1:132/101)
The " * Origin: " part of the line is a constant field.
This is followed by the name of the system as taken from the
AREAS.BBS file or a file named ORIGIN located in the DOS
directory of the designated message area. The complete
network address (1:132/101 in this case) is added by the
program inserting the line. This field is generated at the
same time as the tear line, and therefore may either be
generated at the time of creation or during the first
"export" processing. Although the Origin line is not
required by all Echomail processors, it is added by the
Conference Mail System to ensure complete compatibility.
4. Seen-by Lines
There can be many seen-by lines at the end of Conference
Mail messages, and they are the real "meat" of the control
information. They are used to determine the systems to
receive the exported messages. The format of the line is:
SEEN-BY: 132/101 113 136/601 1014/1
The net/node numbers correspond to the net/node numbers of
the systems having already received the message. In this way
a message is never sent to a system twice. In a conference
with many participants the number of seen-by lines can be
very large. This line is added if it is not already a part
of the message, or added to if it already exists, each time
a message is exported to other systems. This is a REQUIRED
field, and Conference Mail will not function correctly if
this field is not put in place by other Echomail compatible
programs.
5. PATH Lines
These are the last lines in a Conference Mail message and
are a new addition, and therefore is not supported by all
Echomail processors. It appears as follows:
^aPATH: 132/101 1014/1
Where the ^a stands for Control-A (ASCII character 1) and
the net/nodes listed correspond to those systems having
processed the message before it reached the current system.
This is not the same as the seen-by lines, because those
lines list all systems the message has been sent to, while
the path line contains all systems having actually processed
the message. This is not a required field, and few echomail
processors currently support it, however it can be used
safely with any other system, since the line(s) will be
ignored. For a discussion on how the path line can be
helpful, see the "Advanced Features" section of this manual.
METHODS OF SENDING CONFERENCE MAIL
To this point the issue of how Conference Mail is actually sent
has been glossed over entirely. The phrase has been, "the message
is exported to another system." What exactly does this mean?
Well, for starters lets show what is called the "basic" setup:
In this setup exported mail is placed into the FidoNet mail area.
Each message exported from a Conference Mail area has one
message generated for each receiving system. This mail is then
sent the same as any other network mail. When Echomail was first
created this was the only way mail could be sent.
The "basic" method has some disadvantages. First, since Echomail
has grown so large it is not uncommon to get 200 new messages per
day imported into various message bases. It is also not uncommon
for a system to be exporting messages to 4 or 5 other systems.
Simple arithmetic shows 800-1000 messages per day would be sent
in normal netmail! This puts a tremendous strain on any netmail
system, not to mention transmission time and the resultant phone
charges. When this limitation of Echomail was first noticed a lot
of people started scratching their heads wondering what to do. If
a solution could not be found it appeared Echomail would
certainly overrun the capabilities of FidoNet.
Thom Henderson (from System Enhancement Associates) came up with
the original ARCmail program. Having previously written the ARC
file archiving and compression program, he knew the savings
achievable by having all of the netmail messages placed in .ARC
format for transmission. As a byproduct, the messages no longer
appeared in the netmail area, but were included in a file
attached to a message (see your FidoNet mailer manual for file
attaches). In this way the tremendous number of messages
generated, and the phone bill problems were both solved.
Unfortunately, ARCmail required the messages to first be placed
into the netmail area before it could be run. In effect, it
caused the messages to be scanned once when they were exported,
once during the ARCmail phase, once when ARCmail was run at the
other end to get the messages out of .ARC format, and once when
those messages were later imported into a message base on the
receiving system. The Conference Mail System solves this problem
by eliminating the ARCmail program. Conference Mail builds the
ARCmail files during Export, and unpacks them during Import. This
way messages are exported directly to ARCmail style file
attaches, and imported directly from ARCmail style file attaches.
The scanning phases between importing and exporting messages are
totally removed and processing time is proportionally reduced.
This is now the most common method for sending Conference Mail
between systems. The overhead involved in doing it during the
importing and exporting phases is much less than what is involved
if ARCmailing is not utilized. This was a primary consideration
in the design and implementation of the Conference Mail System,
and as a result the entire system is optimized for this type of
use. Please refer to the Import and Export functions for
specifics on how to use the ARCmailing feature.
CONFERENCE TOPOLOGY
The way in which systems link together for a particular
conference is called the "conference topology." It is important
to know this structure for two reasons: 1) It is important to
have a topology which is efficient in the transfer of the
Conference Mail messages, and 2) It is important to have a
topology which will not cause systems to see the same messages
more than once.
Efficiency can be measured in a number of ways; least time
involved for all systems to receive a message, least cost for all
systems to receive a message, and fewest phone calls required for
all systems to receive a message are all valid indicators of
efficiency. Users of Echomail compatible systems have determined
(through trial and error) the best measure of efficiency is a
combination of all three of the measurements given above.
Balancing the equation is not trivial, but some guidelines can be
given:
1. Never have two systems attempting to send Conference mail
to each other at the same time. This results in "collisions"
that will cause both systems to fail. To avoid this, one
system should be responsible for polling while the other
system is holding mail. This arrangement can alternate based
upon various criteria, but both systems should never be
attempting to call each other at the same time.
2. Have nodes form "stars" for distribution of Conference
Mail. This arrangement has several nodes all receiving their
Conference Mail from the same system. In general the systems
on the "outside" of the star poll the system on the
"inside". The system on the "inside" in turn polls other
systems to receive the Conference Mail that is being passed
on to the "outside" systems.
3. Utilize fully connected polygons with a few vertices.
Nodes can be connected in a triangle (A sends to B and C, B
sends to A and C, C sends to A and B) or a fully connected
square (all corners of the square send to all of the other
corners). This method is useful for getting Conference Mail
messages to each node as quickly as possible.
All of these efficiency guidelines have to be tempered with the
guidelines dealing with keeping duplicate messages from being
exported. Duplicates will occur in any topology that forms a
closed polygon that is not fully connected. Take for example the
following configuration:
A ----- B
| |
| |
C ----- D
This square is a closed polygon that is not fully connected. It
is capable of generating duplicates as follows:
1. A message is entered on node A.
2. Node A exports the message to node B and node C placing
the seen-by for A, B, and C in the message as it does so.
3. Node B sees that node D is not listed in the seen-by and
exports the message to node D.
4. Node C sees that node D is not listed in the seen-by and
exports the message to node D.
At this point node D has received the same message twice - a
duplicate was generated. Normally a "dup-ring" will not be as
simple as a square. Generally it will be caused by a system on
one end of a long chain accidentally connecting to a system on
the other end of the chain. This causes the two ends of the chain
to become connected, forming a polygon.
In FidoNet this problem is reduced somewhat by having "Regional
Echomail Coordinators" (RECS) that try to keep track of Echomail
connections within their regions of the world. A further rule
which is followed is that only the RECS are allowed to make
inter-regional connections for the larger conferences. In return,
the RECS have established a very efficient topology which gets
messages from coast to coast, and onto over 200 systems in less
than 24 hours. If no one were willing to follow the rules, then
this system would collapse, but due to the excellent efficiency
it has remained intact for over a year.
Why a PATH line?
As was previously mentioned, the PATH line is a new concept in
Echomail. It stores the net/node numbers of each system having
actually processed a message. This information is useful in
correcting the biggest problem encountered by nodes running an
Echomail compatible system - the problem of finding the cause of
duplicate messages. How does the PATH line help solve this
problem? Take the following path line as an example:
^aPATH: 107/6 107/312 132/101
This shows the message was processed by system 107/6 and
transferred to system 107/312. It further shows system 107/312
transferred the message to 132/101, and 132/101 processed it
again. Now take the following path line as the example:
^aPATH: 107/6 107/312 107/528 107/312 132/101
This shows the message having been processed by node 107/312 on
more than one occasion. Based upon the earlier description of the
'information control' fields in Echomail messages, this clearly
is an error in processing (see the section entitled "How it
Works"). This further shows node 107/528 as the node which
apparently processed the message incorrectly. In this case the
path line can be used to quickly locate the source of duplicate
messages.
In a conference with many participants it becomes almost
impossible to determine the exact topology used. In these cases
the use of the path line can help a coordinator of the conference
track any possible breakdowns in the overall topology, while not
substantially increasing the amount of information transmitted.
Having this small amount of information added to the end of each
message pays for itself very quickly when it can be used to help
detect a topology problem causing duplicate messages to be
transmitted to each system.
-30-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

617
html/ftsc/fts-0005.html Executable file
View File

@ -0,0 +1,617 @@
<HTML>
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| Document: FTS-0005
| Version: 003
| Date: February 7, 1996
| Maintainer: David Nugent, 3:632/348@fidonet
The Distribution Nodelist
Originally by Ben Baker
Amended by Rick Moore, 1:115/333@FidoNet, February 5, 1989
Amended by David Nugent, 3:632/348@FidoNet, February 27, 1996
| Copyright 1986-1996 by the FidoNet Technical Standards Committee.
All rights reserved. Duplication and/or distribution permitted
for non-commercial purposes only.
This document supersedes and replaces the document known under
| the names of FSC002, FSC-0002, and FTS-0002. Significant changes,
| which excludes mere formatting changes, to the previous version
| of this document have been "redlined" (marked with a vertical
| bar in the leftmost column).
This document defines the format and content of the nodelist for
the Public FidoNet Network (PFN) as published on Friday of each
| week. This format is historically known as the "St. Louis nodelist
| format".
The PFN is an international network of independently owned
electronic mail systems, most with interlocking electronic
bulletin board systems. The distribution nodelist, or simply
"nodelist", is the glue which holds the network together. It is
the PFN's "phone book" and it defines the top-level network
| structure and is the means by which FidoNet retains its integrity
| as a point-to-point mail network.
| THE NODELIST
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is a three digit number representing the
| day-of-year of the Friday publication date, with zeros filling
| positions to the left if necessary. This file is packed into a
| archive file named NODELIST.?nn, where 'nn' are the last two
| digits of day-of-year, and the character at the position of the
| '?' indicating the type of compression used. Conventions as to
| which compression method is used for the distributed nodelist is
| a matter of local policy and is usually determined by each zone's
| Zone Coordinator.
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines; comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
| etc.). The file is terminated with a DOS end-of-file character
| (character value 26 decimal, or "control-Z").
Comment lines contain a semicolon (;) in the first character
position followed by zero or more alphabetic characters called
"interest flags". A program which processes the nodelist may use
comment interest flags to determine the disposition of a comment
line. The remainder of a comment line (with one exception,
| treated below) is free-form ASCII text. There are five types of
| comments flags:
| ;S This is of particular interest to Sysops
| ;U This is of particular interest to BBS users
| ;F This should appear in any formatted "Fido List"
| ;A This is of general interest (shorthand for ;SUF)
| ;E This is an error message inserted by the nodelist generator
| ; This comment may be ignored by a nodelist processor
The first line of a nodelist is a special comment line containing
identification data for the particular edition of the nodelist.
The following is an example of the first line of a nodelist:
;A FidoNet Nodelist for Friday, July 3, 1987 -- Day number 184 : 15943
This line contains the general interest flag, the day, date, and
| three-digit (zero-filled) day-of-year number of publication, and
ends with a 5 digit decimal number with leading zeros, if
necessary. This number is the decimal representation of a check
value derived as follows:
Beginning with the first character of the second line, a
16 bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
| in various technical references, and will not be treated further
here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The term "alphanumeric character" is defined as the portion of
the ASCII character set from 20 hex through 7E hex, inclusive.
The following discussion defines the contents of each field in a
data line.
Field 1: Keyword
The keyword field may be empty, or may contain one of the
following:
Zone
Begins the definition of a geographic zone and define its
coordinator. All the data lines following a line with the
"Zone" keyword down to, but not including, the next
occurrence of a "Zone" keyword, are regions, networks, and
| nodes within the defined zone. Node entries defined
| immediately after the "Zone" keyword and before the next
| region or host entry are known as zone adminstrative nodes.
| These are allocated by the Zone Coordinator for use by nodes
| in the entire zone; for example, mail gateways between
| FidoNet zones.
Region
Begins the definition of a geographic region and defines
its coordinator. All the data lines following a line with
the "Region" keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host"
keyword, are independent nodes within the defined region.
Host
Begins the definition of a local network and defines its
| network coordinator. All the data lines following a line
with the Host keyword down to, but not including, the
next occurrence of a "Zone", "Region", or "Host" keyword,
are local nodes, members of the defined local network.
Hub
Begins the definition of a routing sub-unit within a
multi-level local network. The hub is the routing focal
point for nodes listed below it until the next occurrence
of a "Zone", "Region", "Host", or "Hub" keyword. The hub
entry MUST be a redundant entry, with a unique number, for
one of the nodes listed below it, within its hub segment.
This is necessary because some nodelist processors
eliminate these entries in all but the local network.
Pvt
Defines a private node with unlisted number. Private nodes
are only allowed as members of local networks.
Hold
Defines a node which is temporarily down. Mail may be sent
to it and is held by its host or coordinator.
Down
Defines a node which is not operational. Mail may NOT be
sent to it. This keyword may not be used for longer than
two weeks on any single node, at which point the "down"
node is to be removed from the nodelist.
<empty>
| The field contains no text (not the sequence "<empty>"),
| and defines a normal node entry.
| Only one of these may be used in any individual data line.
Field 2: Zone/Region/Net/Node number
This field contains only numeric digits and is a number in the
range of 0 to 32767. If the line had the "Zone", "Region", or
"Host" keyword, the number is the zone, net, or region number,
and the node has an implied node number of 0. Otherwise, the
number is the node number. The zone number, region or net number,
and the node number, taken together, constitute a node's FidoNet
address.
Zone numbers must be unique. Region or net numbers must be unique
within their zone, hub numbers unique be within their net, node
| numbers unique within their net (and region, for regional
| independent nodes, zone for zone administrative entries). Duplicate
node numbers under different hubs within the same net are not
allowed.
Field 3: Node name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces, and
a comma delimits the end of the field. This is the name by which
the node is known, usually as determined by the node or the
coordinator responsible for compiling the segment.
Field 4: Location
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
field contains the location of the node. It is usually expressed
as the primary local location (town, suburb, city, etc.) plus the
identifier of the regional geopolitical administrative district
(state, province, department, county, etc.). Wherever possible,
standard postal abbreviations for the major regional district
should be used (IL, BC, NSW, etc.).
Field 5: Sysop name
This field may contain any alphanumeric characters other than
commas and spaces. Underscores are used to represent spaces. This
is the name of the system operator.
Field 6: Phone number
This field contains at least three and usually four numeric
sub-fields separated by dashes (-). The fields are country code,
city or area code, exchange code, and number. The various parts
of the phone number are frequently used to derive cost and
routing information, as well as what number is to be dialed. A
typical example of the data in a phone number field is
1-800-555-1212, corresponding to country 1 (USA), area 800
(inbound WATS), exchange 555, and number 1212.
Alternatively, this field may contain the notation
"-Unpublished-" in the case of a private node. In this case, the
| keyword "Pvt" must appear at the start of the line.
Field 7: Baud rate
This field contains one of the values: 300, 1200, 2400, 9600,
| 19200, or 38400.
| This baud rate is indicative only of the maximum baud rate that
| may be expected when connecting to a node and is generally of use
| only where a calling node needs to adjust the baud rate used to
| dial to the caller's modem speed in order to achieve a
| connection, a requirement that with modem technology available in
| 1996 is rarely if ever needed. This information is largely
| superseded by modem protocol flags (see next section) where any
| two nodes using a common protocol may have other expectations
| with regards to actual transfer rates. Use of the baud rate field
| alone is therefore depreciated.
Field 8 - Flags
This optional field contains data about the specific operation of
the node, such as file requests, modem protocol supported, etc.
Any text following the seventh comma on a data line is taken
collectively to be the flags field. The required format is zero
or more sub-fields, separated by commas. Each sub-field consists
of a flag, possibly followed by a value.
The following flags define special operating conditions:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
| LO Node accepts calls only from valid listed node
| numbers in the current FidoNet nodelist
The following flags define modem protocols supported:
Flag Meaning
| V21 ITU-T V21 300 bps full duplex
| V22 ITU-T V22 1200 bps full duplex
| V29 ITU-T V29 9600 bps half duplex
| V32 ITU-T V32 9600 bps full duplex
| V32b ITU-T V32bis 14400 bps full duplex
| V33 ITU-T V33
| V34 ITU-T V34 28800 bps full duplex
H96 Hayes V9600
HST USR Courier HST up to 9600
| H14 USR Courier HST up to 14400
| H16 USR Courier HST up to 16800
MAX Microcom AX/96xx series
PEP Packet Ensemble Protocol
| CSP Compucom Speedmodem
| ZYX Zyxel series
| VFC V.Fast Class
| V32T V.32 Terbo
NOTE: Many V22 modems also support Bell 212A.
If no modem flag is given, Bell 212A is assumed for 1200 bps
systems, ITU-T V22bis is assumed for 2400 bps systems.
The following flags define type of error correction available. A
separate error correction flag should not be used when the error
correction type can be determined by the modem flag. For
| instance, a modem flag of HST implies MNP, V32b implies V32 and
| V42b implies V42. Therefore MNP+HST, H14+MNP, H16+MNP, V32+V32b
| and V42+V42b flag pairs are redundant and should not be used.
Flag Meaning
MNP Microcom Networking Protocol error correction
| V42 ITU-T LAP-M error correction w/fallback to MNP 1-4
| V42b ITU-T LAP-M error correction w/fallback to MNP 1-5
The following flags define the type(s) of compression of mail
packets supported.
Flag Meaning
MN No compression supported
| NOTE: While FidoNet nodes usually exchange mail
| using a variety of different file compression
| formats negotiated between individual systems, the
| presence of this flag indicates the INABILITY TO
| RECEIVE MAIL compressed using the SEA ARC version 5
| compression format and/or named according to the
| ARCmail 0.6 mail bundle naming method. This is, by
| convention, the most common mail compression format
| in use within FidoNet. The presence of this flag
| would normally indicate that all mail should be sent
| uncompressed unless there is some overriding
| arrangement with the receiving system.
The following flags indicate the types of file and file update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
| XC Bark file requests, WaZOO file file/update
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
| XX WaZOO file/update requests
The following flag defines gateways to other domains (mail
networks).
Flag Meaning
Gx..x Gateway to domain 'x..x', where 'x..x` is a string
of alphanumeric characters.
NOTE: Valid values for 'x..x' are assigned by the FidoNet
| International Coordinator or the person appointed as
| Internetworking Coordinator by the FidoNet
| International Coordinator. Current valid values of
'x..x' may usually be found in the notes at the end
| of the current FidoNet nodelist. The most common
| gateway flag is "GUUCP", to denote a gateway to the
| Internet mail system that gates on behalf of the
| fidonet.org internet domain.
The following flags define the dedicated mail periods supported.
They have the form "#nn" or "!nn" where nn is the UTC hour the mail
period begins, '#' indicates Bell 212A compatibility, and '!'
indicates incompatibility with Bell 212A.
Flag Meaning
| #01 Zone 5 mail hour (01:00 - 02:00 UTC)
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
| #03 Zone 4 mail hour (08:00 - 09:00 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
| #20 Zone 6 mail hour (20:00 - 21:00 UTC)
NOTE: When applicable, the mail period flags may be strung
together with no intervening commas, e.g.. "#02#09"
| or "!02!09". Only mail hours other than that
standard within a node's zone should be given. Since
observance of mail hour within one's zone is
mandatory, it should not be indicated.
The following flag defines user-specific values. If present,
this flag MUST be the last flag present in a nodelist entry.
Flag Meaning
Ux..x A user-specified string, which may contain any
alphanumeric character except blanks. This string
may contain one to thirty-two characters of
information that may be used to add user-defined
data to a specific nodelist entry.
| NOTE: Ux..x flags are the mechanism by which new flags may
| be experimentally introduced into the nodelist for a
| trial period to assess their worth. They are
| therefore of a temporary nature, and after their
| introduction they are eventually either promoted
| to a non-U flag or dropped from use altogether.
The FTSC recognizes that the FidoNet International Coordinator is
the ultimate authority over what appears in the FidoNet nodelist.
Also, FTSC is by definition a deliberative body, and adding or
changing a flag may take a considerable amount of time.
Therefore, the FidoNet International Coordinator may temporarily
make changes or additions to the flags as defined in this
document. The FidoNet International Coordinator will then consult
with FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,Richard_Martz,1-213-874-9484,2400,XP
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
| THE NODEDIFF
| With more than thirty-five thousand nodes as of this date (1996),
| the nodelist, even in archive form, is a document of substantial
| size. Since distribution of the nodelist occurs via electronic
file transfer, this file is NOT routinely distributed. Instead,
| when a new nodelist is prepared weekly, it is compared with the
previous week's nodelist, and a file containing only the
differences is created and distributed.
| The distribution difference file, called NODEDIFF.nnn, where nnn
is the day-of-year of publication, is actually an editing script
which will transform the previous week's nodelist into the
current nodelist. A definition of its format follows:
The first line of NODEDIFF.nnn is an exact copy of the first line
| of LAST WEEK'S nodelist (i.e. the first line of the nodelist to
| which the current difference file applies). This is used as a
first-level confidence check to insure that the correct file is
being edited. The second and subsequent lines are editing
commands and data.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1 letter command, one of A, C, or D.
<number> is a decimal number greater than zero, and defines the
number of lines to be operated on by the command. Each command
appears on a line by itself. The commands have the following
meanings:
Ann Add the following nn lines to the output file.
Cnn Copy nn unchanged lines from the input to the output
file.
Dnn Delete (or skip) nn lines from the input file.
The following illustrate how the first few lines of a
| hypothetical NODEDIFF.213 might look:
;A Friday, July 25, 1986 -- Day number 206 : 27712
D2
A2
;A Friday, August 1, 1986 -- Day number 213 : 05060
;A
C5
This fragment illustrates all three editing commands. The first
line is the first line from the previous nodelist, NODELIST.206.
The next line says "delete the first two lines" from
NODELIST.206. These are the identification line and the line
following it. The next command says "add the next two lines" to
NODELIST.213 at the "current" location. The two data lines are
followed by a command which says "copy five unchanged lines" from
NODELIST.206 to NODELIST.213. Notice that the first line added
| will ALWAYS contain the new nodelist CRC, so that the software
| applying the changes to the old nodelist may check the result of
| its editing.
Since only the differences will be distributed, it is important
to insure the accuracy of the newly created nodelist. This is the
function of the CRC mentioned above. It is sufficient for a
program designed to perform the above edits to pick the CRC value
from the first line added to the output file, then compute the
CRC of the rest of the output file. If the two CRCs do not agree,
one of the input files has been corrupted. If they do agree, the
probability is very high (but not 100%) that the output file is
accurate.
For actual distribution, NODEDIFF.nnn is packed into an archive
| file named NODEDIFF.?nn, where 'nn' are the last two digits of
| day-of-year, and '?' indicates the compression format used.
| NODELIST COMPILATION
| This section is included for tutorial reasons and is not intended
| as a definition of any specific method by which FidoNet MUST
| compile its weekly nodelist. It merely represents an attempt to
| document the method by which it currently does so. It is intended
| to be explanatory, and seeks to answer commonly asked questions,
| such as how the nodelist is compiled and where the information
| comes from, why the nodelists used in different FidoNet zones are
| not the same document, and why the difference file generated for
| use in one FidoNet zone cannot be applied to the nodelist
| generated for use in a different zone, even though the week
| numbers match.
| Nodelists are compiled via a distributed method, which follows
| the same structure as the FidoNet coordinator hierarchy. At the
| lowest level, network coordinators maintain a list of the nodes
| in their network and are responsible for the addition, removal
| and correction of individual node's listings in their "segment"
| (as portions of the full nodelist are called). In some larger
| networks, it is common for this job to be shared with hub
| coordinators appointed by the net coordinator, though the
| responsibility for those hub segments still remains with the
| network coordinator.
| At a nominated day during the week, before the regional level
| segment is submitted to the zone coordinator, individual net
| coordinators submit their segments to the regional coordinator
| who subsequently compiles these segments and transmits the merged
| copy to the zone coordinator. These are combined by the zone
| coordinator with the separate segments of other zones and
| compiled into that zone's version of the world nodelist. This
| world nodelist is then compared with the previous week's version,
| a difference file is generated and subsequently distributed
| throughout the zone.
| In some cases, in the interest of saving in transmission times
| and therefore costs, the compilation process itself may be better
| served by the submission of DIFFERENCE FILES rather than full
| net- or region-level segments. Each coordinator therefore retains
| a copy of the previously submitted segments and applies
| difference files to those to derive the new one. This process is
| exactly identical to the NODEDIFF/NODELIST scenario described
| earlier in this document, with the same first line and CRC
| validation method used to guard the integrity of the nodelist
| segments.
| For a number of reasons, it is important that publication of the
| nodelist be as timely as possible. These reasons include: the
| nodelist is a definitive list of valid FidoNet addresses that may
| receive mail, and must therefore be as correct and up-to-date as
| possible to save nodes the unnecessary expense of mail routed to
| possibly non-existing addresses; the nodelist contains the list
| of telephone numbers that may be called by any user of the
| FidoNet nodelist and should therefore be accurate so as not to
| unduly annoy owners of those phone numbers should a listed node
| go down and an unsuspecting telephone subscriber inherit the same
| telephone number.
| Given this constraint, the expense of international calls and the
| fact that FidoNet is a worldwide network that exists in many time
| zones, it may be unreasonable to expect the compilation of the
| nodelist to be delayed until each zone coordinator can transmit
| their most up-to-date zone segment to a central authority for
| compilation and subsequent redistribution in any week. For the
| sake of expedience, each zone instead maintains its own separate
| world nodelist which contains a compilation of the current zone's
| latest segments and including the most current copy to hand of
| all other FidoNet zone's segments. The zone level nodelist
| generated each week by each zone coordinator is then transmitted
| to all other zone coordinators for inclusion into their separate
| world nodelist as timing permits.
| In theory, then, the only difference between nodelists
| distributed in each zone in any week are accounted for by timing
| differences in the exchange of each zone's separate segment. In
| practice, other constraints may interfere with timeliness, such
| as the difficulty and expense of international telephonic
| communications. Also, another point of variance is introduced by
| the fact that each zone usually includes its own zone segment
| first into its world nodelist to assist - amongst other things -
| software that uses the nodelist for index generation. Some
| software in common use in FidoNet indexes the nodelist according
| to its sequential order (e.g. version 5 and 6 compiled nodelist
| formats), and including the current zone first before others will
| have a beneficial effect on software performance.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

870
html/ftsc/fts-0006.html Executable file
View File

@ -0,0 +1,870 @@
<HTML>
<HEAD>
<TITLE>YOOHOO and YOOHOO/2U2.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0006
Version: 002
Date: 30-Nov-1991
YOOHOO and YOOHOO/2U2
The netmail handshake used by Opus-CBCS
and other intelligent Fidonet mail handling packages
Vince Perriello
FidoNet 1:2343/491
Status of this document:
This FTS (FidoNet(r) Technical Standard) specifies an optional
standard for the FidoNet community. Implementation of the
protocols defined in this document is not mandatory, but all
implementations of these protocols are expected to adhere to this
standard. Distribution of this document is subject to the
restrictions listed below.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software
LEGAL STUFF
-----------
The original protocol and documentation are by Wynn Wagner III. Updates
have been made to this document by Vince Perriello, who also is
responsible for most of the sample routine included with this document.
They are released to the public for any use whatsoever as long as you
don't modify any transmitted structure or try to make money hawking
either the sample code or this document as if you owned them.
If you choose to use the method or the sample routines, you do so
entirely at your own risk. It is possible that the routines will cause
physical damage to your equipment, an invasion of fire ants, the plague,
or an extended visit from in-laws. If any of that stuff (or anything
else) happens, you accept the consequences totally.
CREDITS
-------
Fido and Fidonet are registered trademarks of Tom Jennings and Fido
Software.
ARCmail was originated by System Enhancement Associates.
The ZModem protocol was designed by Chuck Forsberg. The SEAlink / SEAlink
Overdrive protocols are copyrighted by System Enhancment Associates. The
TeLink protocol was designed and first implemented by Tom Jennings.
The state charts in this document were done by Vince Perriello.
Rick Huebner designed and implemented the basic WaZOO file request
method. Update request functionality was added by Vince Perriello. Bob
Hartman is responsible for the addition of Domain support.
FTS-0001, describing the base FidoNet protocol, was created by Randy Bush.
FTS-0007, describing enhancement to FTS-0001 using SEAlink and/or SEAlink
Overdrive, was created by Phil Becker.
YooHoo and YooHoo/2u2 Page 2
Overview
UPFRONT
-------
YOOHOO and YOOHOO/2U2 are the initial handshakes for the WaZOO e-mail
protocol. They are designed to let two systems establish a common ground
for a netmail session while making sure that non-WaZOO software doesn't
get upset by material it can't understand.
The YOOHOO procedure begins as a single byte (0xf1). If the system on
the other end doesn't reply to that byte, no further YOOHOO or WaZOO
transmissions are attempted. To a non-WaZOO netmail system, the YOOHOO
byte will simply seem like a byte of debris.
The calling system initiates the YOOHOO by sending the attention
character. If the receiving system seems interested, the calling system
sends a 128 byte packet containing such information as system and sysop
names as well as a "capability mask." A 16-bit CRC protects the integrity
of the 128-byte packet.
In response, the receiving system prepares a 128 byte packet to send
back. This is the YOOHOO/2U2 procedure.
FEATURES
--------
The features of YOOHOO and YOOHOO/2U2 include
* non-interference with systems that don't understand the
handshake
* almost foolproof method for identifying a remote system
and establishing a common ground for transmission
* built-in room to expand the capabilities of WaZOO without
having to resort to a kludge
USAGE
-----
A calling system simply uses a routine that transmits both YooHoo and
TSYNC handshake initiating characters to the called system. If the
called system responds with an XMODEM 'NAK', an FTS-0001 session will be
initiated. If an 'ENQ' is received, the `YooHoo_Sender()' routine will
be invoked to handle the session negotiation.
A receiving system can call a routine like `YooHoo_Receiver()' if it
detects the YOOHOO character, or just drop into the FTS-0001 logic if it
sees a TSYNC.
This simple method allows a mailer to take care of both the TSYNC and the
YOOHOO handshakes.
YooHoo and YooHoo/2u2 Page 3
WaZOO Protocols
PROTOCOLS
---------
Currently there are four WaZOO methods in use:
1. ZedZap
------
a Zmodem variant. The originator does a batch send then goes into a
receive batch mode. The called system does receive then send. In
the event of a file request (see description below) made by the
called system, one more turnaround is made to service the request.
* Unlike the "True" Zmodem protocol described by Chuck Forsberg,
ZedZap routines must be able to handle a batch mode that has no
actual files. In other words, it is possible for there to be a
init sequence followed immediately by a ZFIN.
* The maximum packet size is 8192. This is usually varied based on
the baud rate. For example, at 2400 it might be 2048 bytes, then
for 9600 baud and above the maximum of 8192 could apply. Note that
THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION.
(There's another WaZOO capability bit for those systems which
can not handle this block size)
* Netmail packets are transmitted as files with names in the form
"12345678.PKT". Because of this, multiple packets may be sent in
a single session.
* If the calling system transmits a .REQ file for file requests, the
receiving system can respond to it. See "WaZOO File Requests"
(below) for information on the .REQ file.
2. ZedZip
------
This capability is identical to ZedZap, but does not use buffers
greater than 1K in size (like "True" Zmodem). It is also
permissible to send a "null" packet in a ZedZip session. This
allows a system which must use a strict Zmodem implementation to
participate in a WaZOO session using Zmodem.
3. DietIFNA
--------
The session operates like FTS-0001/FTS-0007. The notable exceptions
are as follows:
* The same packet naming convention as ZedZap applies, allowing more
than one packet to be transmitted in a single session.
YooHoo and YooHoo/2u2 Page 4
WaZOO Protocols
* Telink file transfers don't even attempt to exchange file names
using modem7. The receiving system extracts the file name from the
Telink or SEAlink header block.
* If SEAlink is used, run-ahead (the number of blocks to slide) is
based on the baud rate: BlocksToSlide = BaudRate / 400, up to a
max of 24 blocks.
* When there is nothing to send, a system should remain quiet. In
other words, the end of a session can be determined by a timeout.
* Under no circumstances should "BARK" file request logic be active
during a DietIFNA session. File requests, if any, should be
transmitted using a .REQ file.
Many implementations of DietIfna have been accomplished by the mere
exchange of packets, followed by straight FTS-0001/0007 code. This
is incorrect but probably not easily remedied at this point. We have
made an effort to document this change in "reality" in this revision
of the document.
4. Janus
-----
Janus is a full-duplex simultaneous bidirectional file transfer
protocol. In other words, it can send and receive files at the same
time. It's very loosely derived from ZModem and HDLC/X.25 protocol
technology, in that it uses variable length data-typed packets, and
that transmission of file data does not require ACKs.
The protocol is documented elsewhere; it is beyond the scope of this
document to do so.
YooHoo and YooHoo/2u2 Page 5
Choosing WaZOO Methods
How to decide which WaZOO method to use
---------------------------------------
Since the called system has all the information necessary to decide what
WaZOO method to employ, the best way to implement the process is for the
calling system to send, in its capability mask, all the bits which
correspond to methods it can use (or wants to use) in communicating with
the called system. The called system then looks at these bits and sends
back only the bit which corresponds to the method it wants to use.
If the called system sends back a mask which contains more than one
capability of the calling system, it can create a problem situation if
one system arrives at its choice of methods differently from the other.
Thus, when the called system doesn't make the choice, both systems should
choose as follows:
1. Janus
2. ZedZap
3. ZedZip
4. DietIFNA
The capability highest on the list which both systems indicate ability to
execute should be the one employed.
YooHoo and YooHoo/2u2 Page 6
WaZOO Filename conventions
WaZOO FILENAMES
---------------
1. MESSAGE PACKETS ... xxxxxxxx.PKT
Normal (unarchived) messages are sent in a file name that has a tag
of .PKT. The "x" characters should be hex digits.
2. ARCmail ... xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}#
Message packets are often shipped in an archive that has been
compressed with some LZ utility.
The file name consists of a name with hex digits. The tag is one of
seven two-character prefixes ("MO", "TU", "WE", "TH", "FR", "SA" or
"SU") and a number (0-9).
This particular naming convention was established by ARCmail version
0.60, which is a defacto standard in FidoNet.
3. FILE REQUESTS ... xxxxxxxx.REQ
This is explained below.
In a nutshell, the file name consists of the receiving system's
Fidonet address expressed as two 4-digit hex numbers. The file tag
is .REQ.
In a Janus session, the .REQ file isn't actually sent. Janus has
a transaction system which sends the .REQ file one line at a time
and then accepts the file(s) which the request generates.
YooHoo and YooHoo/2u2 Page 7
Flow of a ZedZap or ZedZip Session
FLOW OF A ZEDZAP OR ZEDZIP SESSION
----------------------------------
The calling system:
* Send YooHoo
* Receive YooHoo/2u2
* In a single batch, send bundles, files, file request (.REQ) files
(in that order)
* In a single batch, receive bundles, files, file requests, and
requested files (in that order)
* If a file request (.REQ) file came in, send all requested files
in a single batch.
Receiving system:
* Receive YooHoo
* Send YooHoo/2u2
* In a single batch, receive bundles, files, file requests
* In a single batch, send bundles, files, our file requests, and
respond to file requests that arrived from the remote system.
* If we sent a .REQ file in the preceding step, receive all files
in a single batch.
YooHoo and YooHoo/2u2 Page 8
WaZOO File Requests
WAZOO FILE REQUESTS
-------------------
Rick Huebner, who adapted the ZModem routines for Opus, and the architect of
the Janus file transfer protocol, designed the ".REQ file"-based file request
system.
REQ FILE:
A WaZOO file request is based on a request file. The name of a request file
is similar to the .OUT and .FLO files used by Opus-CBCS and similar mail
products (such as BinkleyTerm).
TEMPLATE: netnode.REQ
EXAMPLE: 00010002.REQ ... a request being sent to 1/2
The .REQ file is simply a text file that contains the files we want from the
remote system. Those file names can include wildcards, but should not contain
a path. Optionally, there can be a password if the sending system requires one.
The "netnode" part of the file name is built from the remote systems net and
node numbers. Both numbers become 4-character hex numbers in the file name.
Let's say we're requesting THIS.ARC and all node lists from 12/2. The file
name would be 000C0002.REQ. The contents would look like this:
this.arc
nodelist.*
If the sysop of 12/2 requires a password of THAT to get the file THIS.ARC, the
REQ file contents would have to change:
this.arc !that
nodelist.*
Transaction-level passwords (of 6 or fewer characters) follow the file name:
<filename><single-space-character>!<password><cr>
YooHoo and YooHoo/2u2 Page 9
WaZOO File Requests
If the request is of the "update" genre, the type of update and the time,
expressed as a UNIX-style long decimal ASCII number, follows the name, or in
the event that there is a transaction-level password, the password. For
example, an update request for file NEWOPUS.*, where you already have a file
dated 1-January 1989, 00:00 and you live on the East Coast (GMT+06) would be:
NEWOPUS.* +599634000
The sign is required, it indicates the type of update request. A '+' means
that all files matching the filespec "NEWOPUS.*" newer than the shown time
will be sent, a '-' means that all matching files with dates up to and
including the indicated time will be sent.
The complete format of an action line in an REQ file is, then:
<filename>[<space>!<password>][<space><+/-><time>]<cr>
MECHANISM:
In a ZedZap or DietIfna session, the .REQ file is simply transmitted to the
other system. It goes "as is" like any other file. In a Janus session, the
.REQ file will be sent one line at a time and individually serviced by the
other end.
The other system can ignore the request, send some of the files, or send all
of the files. There is no accounting or responsibilities on the part of the
remote system.
If your implementation is unable to process the update information for any
reason, then you should process the line as a "regular" file request.
NOTE:
In the YooHoo packet, there's a bit that lets you know if the remote system
currently accepts .REQ files. This will be a clue as to whether a .REQ file
would be a waste of time or not. Procedurally, you just should not send a .REQ
file to a system which indicates that it won't process it.
YooHoo and YooHoo/2u2 Page 10
Structures and Definitions
STRUCTURES AND DECLARATIONS
---------------------------
#define ACK 0x06
#define NAK 0x15
#define ENQ 0x05
#define YOOHOO 0xf1
#define TSYNC 0xae
struct _Hello
{
word signal; /* always 'o' (0x6f) */
word hello_version; /* currently 1 (0x01) */
word product; /* product code */
word product_maj; /* major revision of the product */
word product_min; /* minor revision of the product */
char my_name[60]; /* Other end's name, will include domain */
/* if DO_DOMAIN is set in capabilities mask*/
char sysop[20]; /* sysop's name */
word my_zone; /* 0== not supported */
word my_net; /* out primary net number */
word my_node; /* our primary node number */
word my_point; /* 0 == not supported */
byte my_password[8]; /* This is not necessarily null-terminated */
byte reserved2[8]; /* reserved by Opus */
word capabilities; /* see below */
byte reserved3[12]; /* for non-Opus systems with "approval" */
}; /* total size 128 bytes */
/*------------------------------------------------------------------------*/
/* YOOHOO<tm> CAPABILITY VALUES */
/*------------------------------------------------------------------------*/
#define Y_DIETIFNA 0x0001 /* Can do fast "FTS-0001" 0000 0000 0000 0001 */
#define FTB_USER 0x0002 /* Reserved by Opus-CBCS 0000 0000 0000 0010 */
#define ZED_ZIPPER 0x0004 /* Does ZModem, 1K blocks 0000 0000 0000 0100 */
#define ZED_ZAPPER 0x0008 /* Can do ZModem variant 0000 0000 0000 1000 */
#define DOES_IANUS 0x0010 /* Can do Janus 0000 0000 0001 0000 */
#define Bit_5 0x0020 /* reserved by FTSC 0000 0000 0010 0000 */
#define Bit_6 0x0040 /* reserved by FTSC 0000 0000 0100 0000 */
#define Bit_7 0x0080 /* reserved by FTSC 0000 0000 1000 0000 */
#define Bit_8 0x0100 /* reserved by FTSC 0000 0001 0000 0000 */
#define Bit_9 0x0200 /* reserved by FTSC 0000 0010 0000 0000 */
#define Bit_a 0x0400 /* reserved by FTSC 0000 0100 0000 0000 */
#define Bit_b 0x0800 /* reserved by FTSC 0000 1000 0000 0000 */
#define Bit_c 0x1000 /* reserved by FTSC 0001 0000 0000 0000 */
#define Bit_d 0x2000 /* reserved by FTSC 0010 0000 0000 0000 */
#define DO_DOMAIN 0x4000 /* Packet contains domain 0100 0000 0000 0000 */
#define WZ_FREQ 0x8000 /* WZ file req. ok 1000 0000 0000 0000 */
YooHoo and YooHoo/2u2 Page 11
Domain addressing in Hello Packet
Since the invention of the WaZOO handshake, nearly every change in the
FidoNet transport has been accessible by defining bits for new protocols,
using the point number field in the structure, etc.
With the advent of Domain addressing in FidoNet, this was no longer the
case. There was no place set aside in the hello packet where domain info
could be passed from one system to another.
We have addressed this requirement by using some of the space set aside
in the system name field for the domain. It is backward-compatible with
all systems which determine the end of a string by use of a null.
WaZOO systems that support domains communicate that fact by setting the
DO_DOMAIN bit (hex 2000) in the capabilities mask. This tells the other
side that they can expect to find a domain address in the packet.
The domain name is stored at the end of the 'my_name' field. It is stored
in its entirety (no abbreviations as in FSC-0045) after the system name.
If the length of the system name plus the null terminator plus the length
of the domain name plus terminator exceeds 60, the system name will be
truncated (right to left) to make it fit.
So, for a system named "FUBAR" at address 1:234/567@fidonet.org, the
address and name fields in the header would look like this:
hello.my_zone = 1
hello.my_net = 234
hello.my_node = 567
hello.my_point = 0
hello.my_name = 'F','U','B','A','R', 0, 'f','i','d','o','n','e','t',
'.','o','r','g',0
hello.capabilities will contain the usual capabilities plus DO_DOMAIN.
A remote system receiving this packet should look past the null in
my_name to get the domain name.
YooHoo and YooHoo/2u2 Page 12
Caller State Tables
Calling System:
The parts of FTS-0001 and FTS-0007 which deal with synchronization of calling
and called system must be modified to deal with the reception and processing
of the YooHoo character and exchange of Hello packets. The following state
table may be used to initiate an FTS-0001 or a WaZOO session by the calling
system. It replaces state S3 in the FTS-0001 table.
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| SS0 | SyncInit | | Prepare 3 sec Sync timer| |
| | | | Prepare .5 sec NAK tmr | |
| | | | Init NAK Count | |
| | | | Start 60 sec master tmr | SS1 |
|-----+----------+-------------------------+-------------------------+-----|
| SS1 | SendSync | 1. Over 60 seconds | | |
| | | or carrier lost | no response | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. 3 sec elapsed | Clear Inbound buffer | |
| | | or timer not started | Send YOOHOO, then TSYNC | |
| | | | Start 3 sec Sync timer | SS2 |
| | +-------------------------+-------------------------+-----|
| | | 3. not elapsed | | SS2 |
|-----+----------+-------------------------+-------------------------+-----|
| SS2 | WaitResp | 1. Nothing received | require a response | SS1 |
| | +-------------------------+-------------------------+-----|
| | | 2. ENQ received | WaZOO Protocol selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. 'C' received | probable FTS-0001 | SS3 |
| | +-------------------------+-------------------------+-----|
| | | 4. NAK received | probable FTS-0001 | SS3 |
| | +-------------------------+-------------------------+-----|
| | | 5. Debris (might include| Reset NAK timer | |
| | | (YOOHOO|TSYNC) & 127)| if started | SS1 |
|-----+----------+-------------------------+-------------------------+-----|
| SS3 | NAKTmr | 1. Timer not expired | Zero NAK count | |
| | | or timer not started | Start .5 sec NAK timer | SS1 |
| | +-------------------------+-------------------------+-----|
| | | 2. Timer expired | Bump NAK count | SS4 |
|-----+----------+-------------------------+-------------------------+-----|
| SS4 | NAKCount | 1. Count >= 2? | assume FTS-0001 | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. Count < 2 | Keep looking | SS1 |
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 13
Caller State Tables
Calling System (continued):
The FTS-0001 exits from the above table should operate using the FTS-0001
state tables, starting at state S4. The "WaZOO detected" case should proceed
using the following state table:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| YS1 | SndHello | Successful | Looks like WaZOO | YS2 |
| | (state +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | SH1) | Not successful | Repeat whole thing | exit|
|-----+----------+-------------------------+-------------------------+-----|
| YS2 | WaitResp | 30 sec timer expires | repeat whole thing | exit|
| | | or lost carrier | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received YOOHOO | Another WaZOO, go | YS3 |
| | | | process receive | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received debris | Repeat whole thing | YS2 |
|-----+----------+-------------------------+-------------------------+-----|
| YS3 | GetHello | Information | Report Success | exit|
| | (state | Successfully | | |
| | RH1) | Exchanged | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Failure | Repeat whole thing | exit|
`-----+----------+-------------------------+-------------------------+-----'
The failure cases in this table may be retried. The retry should be from
the point of synchronization. This means redoing the process in the SendSync
table on Page 11. A really smart mailer could therefore do a YooHoo, exchange
information, decide that it doesn't want to do WaZOO, fail out, and attempt
an FTS-0001 session.
If the packet exchange is successful, session method selection proceeds and
then the chosen session method should be employed to exchange mail and files.
YooHoo and YooHoo/2u2 Page 14
Called System State Tables
The following state table may be used to initiate an FTS-0001 or a WaZOO
session by the called system. It replaces states R1 and R2 in the FTS-0001
table.
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| RS0 | SyncInit | | Start 5 second idle tmr | RS1 |
|-----+----------+-------------------------+-------------------------+-----|
| RS1 | IdleWait | 1. 5 sec tmr expired | Take the initiative | RS2 |
| | +-------------------------+-------------------------+-----|
| | | 2. Carrier lost | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. Peek = YOOHOO | Looks like a live WaZOO | RS3 |
| | +-------------------------+-------------------------+-----|
| | | 4. Peek = TSYNC | Live FTS-0001, we think | RS3 |
| | +-------------------------+-------------------------+-----|
| | | 5. Peek = CR, LF, space | He looks alive | RS2 |
| | +-------------------------+-------------------------+-----|
| | | 6. Other character | Eat it | RS1 |
|-----+----------+-------------------------+-------------------------+-----|
| RS2 |SendBanner| 1. Error returned | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. Banner sent OK | | RS3 |
|-----+----------+-------------------------+-------------------------+-----|
| RS3 |RecvInit | | Start 20 sec timer | RS4 |
| | | | Init 10 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| RS4 |SendSync | 1. Error returned | Session aborted | exit|
| |(xmit sync+-------------------------+-------------------------+-----|
| |string) | 2. String sent OK | Watch for sender sync | RS5 |
|-----+----------+-------------------------+-------------------------+-----|
| RS5 | WaitSync | 1. Carrier lost | Session aborted | exit|
| | +-------------------------+-------------------------+-----|
| | | 2. YOOHOO received | WaZOO session selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 3. TSYNC received | probable FTS-0001 | RS6 |
| | +-------------------------+-------------------------+-----|
| | | 4. CR received | Still sync'ing | RS4 |
| | +-------------------------+-------------------------+-----|
| | | 5. Other character rcvd | Get next input character| RS5 |
| | +-------------------------+-------------------------+-----|
| | | 6. 10 sec timer elapsed | FTS-0001 selected | exit|
| | +-------------------------+-------------------------+-----|
| | | 7. 20 sec timer elapsed | Not a mail session | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RS6 | TsyncTmr | 1. Timer not running | Start 10 second timer | RS5 |
| | | | Reset 20 sec timer | |
| | +-------------------------+-------------------------+-----|
| | | 2. Timer running | Two TSYNCS = FTS-0001 | exit|
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 15
Called System State Tables
The FTS-0001 exits from the above table should operate using the FTS-0001
state tables, starting at state R3. The "WaZOO detected" case should proceed
using the following state table:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| YR1 | GetHello | Information | Start 20 sec timer | YR2 |
| | (state | Successfully | Initialize retry count | |
| | RH1) | Exchanged | Send YooHoo | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Failure | Repeat whole thing | exit|
|-----+----------+-------------------------+-------------------------+-----|
| YR2 | WaitResp | 20 sec timeout | try again | YR3 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Lost carrier | Failure | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received ENQ | Go send hello | YR4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received debris | Keep looking | YR2 |
|-----+----------+-------------------------+-------------------------+-----|
| YR3 | PollPeer | More than 3 retries | Give it up | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Less than 3 retries | Bump retry count | YR2 |
| | | | Clear input buffer | |
| | | | Send YOOHOO | |
| | | | Restart 20 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| YR4 | SndHello | Successful | All done, report success| exit|
| | (state +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | SH1) | Not successful | Repeat whole thing | exit|
`-----+----------+-------------------------+-------------------------+-----'
The failure cases in states YR1, YR3 and YR4 of this table may be retried.
The retry should be from the point of synchronization. This means redoing the
process in the RecvSync table on Page 13, beginning at state RS3. A really
smart mailer could therefore do a YooHoo, exchange information, decide that
it doesn't want to (or cannot) do a WaZOO session, fail out, and attempt
an FTS-0001 session.
If the packet exchange is successful, session method selection proceeds and
then the chosen session method should be employed to exchange mail and files.
YooHoo and YooHoo/2u2 Page 16
Packet Exchange State Tables
The following state table describes the transmission of the "Hello" packet
from one system to its partner:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| SH1 | InitSend | | Disable XON/XOFF | SH2 |
| | | | Set retry count to 0 | |
|-----+----------+-------------------------+-------------------------+-----|
| SH2 | SendHedr | | Send Hex 1f, then | SH3 |
| | | | Send HELLO struct | |
|-----+----------+-------------------------+-------------------------+-----|
| SH3 | SendCRC | | Clear Input Buffer | SH4 |
| | | | Send two-byte CRC of pkt| |
| | | | MSB followed by LSB | |
| | | | Start 40 second timer | |
|-----+----------+-------------------------+-------------------------+-----|
| SH4 | GetResp | 40 second timer expires | Failed to send packet | exit|
| | | or carrier lost | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | ACK received | Successful transmission | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | '?' received | Error, try retransmit | SH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | ENQ received | Out of sync? | SH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | other character recvd | Debris, keep watching | SH4 |
`-----+----------+-------------------------+-------------------------+-----'
YooHoo and YooHoo/2u2 Page 17
Packet Exchange State Tables
The following state table describes the reception of the "Hello" packet sent
to a system by its partner:
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| RH1 | SendENQ | | Start 2 minute timer | RH2 |
| | | | Send an ENQ character | |
|-----+----------+-------------------------+-------------------------+-----|
| RH2 | WaitHedr | 2 minute timer expires | Report failure | exit|
| | | or carrier lost | | |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received Hex 1f | Got header, get packet | RH5 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received other char | Debris, throw away | RH3 |
| | | | Start 10 sec timer | |
|-----+----------+-------------------------+-------------------------+-----|
| RH3 | TossJunk | 10 sec timer expires | Too much noise | RH4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Received Hex 1f | Got header, get packet | RH5 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Input buffer empty | Try to resynch | RH4 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Carrier lost | Report failure | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RH4 | ReSynch | | Clear input buffer | RH2 |
| | | | Send ENQ | |
|-----+----------+-------------------------+-------------------------+-----|
| RH5 | HdrSetup | | Initialize CRC | |
| | | | Set 30 second timer | RH6 |
|-----+----------+-------------------------+-------------------------+-----|
| RH6 | GetHChar | 30 sec timer expires or | | |
| | | carrier lost | Report failure | exit|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | Character received | Process character | RH7 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | 10 seconds with no char | Error, try resync | RH9 |
|-----+----------+-------------------------+-------------------------+-----|
| RH7 | StoHChar | Buffer and CRC filled | Compare CRC | RH8 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | More characters needed | Reset 30 sec timer | RH6 |
|-----+----------+-------------------------+-------------------------+-----|
| RH8 | CheckCRC | CRC matches | Finish Receive | RH10|
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | CRC doesn't match | Handle error | RH9 |
|-----+----------+-------------------------+-------------------------+-----|
| RH9 | CountERR | Less than 10 errors | Send '?' (0x3f) | RH2 |
| | +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
| | | 10 errors | Hang up, report failure | exit|
|-----+----------+-------------------------+-------------------------+-----|
| RH10| HelloOK | | Clear inbound buffer | exit|
| | | | Send ACK | |
`-----+----------+-------------------------+-------------------------+-----'
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

1869
html/ftsc/fts-0007.html Executable file
View File

File diff suppressed because it is too large Load Diff

485
html/ftsc/fts-0008.html Executable file
View File

@ -0,0 +1,485 @@
<HTML>
<HEAD>
<TITLE>Bark file-request protocol extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0008
Version: 003
Date: 15-Oct-1990
Updates: FTS-0001
An Enhanced FidoNet(r) Technical Standard
Extending FTS-0001 to include Bark requests
October 15, 1990
Status of this document:
This document specifies an optional standard for the FidoNet community.
Implementation of the protocols defined in this document is not mandatory,
but all implementations of these protocols are expected to adhere to this
standard. Distribution of this document is subject to the limitations of
the copyright notice displayed below.
Copyright 1989-90 by Philip L. Becker. Portions of this document are
copyright 1986-90 by Randy Bush and are incorporated with his consent.
All rights reserved. A right to distribute only without modification and
only at no charge is granted. Under no circumstances is this document to
be reproduced or distributed as part of or packaged with any product or
other sales transaction for which any fee is charged. Any and all other
reproduction or excerpting requires the explicit written consent of the
copyright holders.
A. Introduction
1. This Document
This document describes the standard for "Bark" type FidoNet file
request operation. Bark file requests are an extension to the basic
FTS-0001 mail session, and this document presents these requests as a
modification to that document.
2. What are File Requests?
File Requests are a way of requesting that a specific file be sent during
a FidoNet mail session. This has many advantages over simply logging on to
a BBS and downloading a file:
o You need not be a validated user
o You don't have to spend time searching for the file on the BBS
o You can schedule the file request to take place at any time without
your being near your computer.
There are two commonly used types of file requests on FidoNet today, WaZOO
and Bark requests. WaZOO requests are used by Opus and BinkleyTerm, and
are not documented here. See the document FTS-0006 by V. Perriello for a
description of these. Bark requests were the first file request extension
to the FTS-0001 protocol, and are supported (at least partially) by many
mailers, including SEAdog, Dutchie, BinkleyTerm, and to a certain extent
Opus. This document describes how to implement Bark-type file requests.
B. Terms Used in this Document
1. The diagrams and notations used in this document are the same as those used
in the FTS-0001 document. Please see FTS-0001 for a description of these.
This document should be considered as an extension to the FTS-0001 session
layer protocol, and you will require FTS-0001 in addition to this document
to fully understand what is presented here.
In addition to the data description language described in FTS-0001 section
A.4, one extra terminal used in this notation:
(* terminals *)
someName<max> - String of up to max chars, NOT null terminated
C. Performing File Requests
1. Introduction
A Bark request consists of transmitting a special Bark Request packet which
contains a filename, a date (used for update requests), and optionally a
password. The system receiving the request then decides if it can send the
requested file or not, and if it can does so using the same protocol used
to send attached files. Bark request handling is always controlled by the
answering system, and consists of two phases. In phase one, the receiving
system asks the calling system to honor requests it may have to ask for
files from the caller. In phase two, the receiving system allows the
calling system to request files from it.
Update file requests are the same as normal file requests, with one
exception. If the date in the Bark Request packet (described below) is
greater than or equal to the date of the actual file requested, the file
will not be sent. The requestor should set the date to the date of the
the actual file on its own end if an update request is desired.
D. The Bark Request Packet
1. Data Link Layer Data Definition.
The Bark Request packet is a variable-sized packet containing a header, a
filename, a date (which is used only for update requests - in a normal file
request it's 0) and an optional password. When receiving a Bark Request
packet, the ETX may be used to determine the end of the data portion. Note
that the CRC is sent in the reverse byte order of a normal CRC XMODEM data
block (see FTS-0001 section G.1).
Note: some systems will send a password in the data block even if none is
needed. Incoming passwords should be ignored unless the other system is
trying to request a passworded file.
Bark File Request Packet
Offset
dec hex
.-----------------------------------------------.
0 0 | ACK - Start of Bark Request - 06H |
+-----------------------------------------------+
1 1 | Filename - Packed DOS file format |
+-----------------------------------------------+
n n | SPACE - 20H |
+-----------------------------------------------+
n n | Date (0 if not Update Request) |
+-----------------------------------------------+
n n | SPACE - 20H (only if pswd follows) |
+-----------------------------------------------+
n n | Password (optional) |
+-----------------------------------------------+
n n | ETX - End of RESYNC packet - 03H |
+-----------------------------------------------+
n n | (*1) CRC low order byte |
+-----------------------------------------------+
n n | (*1) CRC high order byte |
`-----------------------------------------------'
*1 - CRC does not include the ACK or ETX and is
in the reverse byte order from the CRC in a
normal XMODEM data packet.
2. Data Description Notation of Bark Request Packet
DataBlock (no password) = ACK
Filename<12>
Space
Date<11>
ETX
CRC
DataBlock (with password) = ACK
Filename<12>
Space
Date<11>
Space
Password<6|8>
ETX
CRC
ACK = 06H (* Header for file request block *)
Space = 20H (* Space character *)
ETX = 03H (* End of block *)
Filename (* Name of file requested *)
Date (* ASCII string; the number of seconds
since midnight, January 1, 1970 *)
Password (* The password needed to request this
file, if any. Maximum length is 6 for
BinkleyTerm and Opus, 8 for SEAdog
and Dutchie. *)
CRC = crc[2] (* CCITT Cyclic Redundancy Check. The
same algorithm as used for XModem
CRCs. The CRC is calculated on
all data in the block between but
not including the ACK and the ETX *)
E. Session Layer Protocol:
This section describes the modified FTS-0001 session layer protocol. This
is the only area of FTS-0001 which is modified to implement Bark style file
requests. File Requests are performed at the end of the normal FidoNet
mail session, after any mail pickup is performed.
The diagrams below desribe the session level protocol with Bark file
requests implemented. The state tables have been broken into subroutines
but the FTS-0001 portion is not functionally changed. FTS-0001 sender
states S4 through S7 are now table "Send Mail SM0". FTS-0001 receiver
states R3 through R6 are now table "Receive Mail RM0". They are not
functionally changed in any way from FTS-0001, they are just broken out
to allow them to be used as subroutines. Finally Sender states S0 through
S3 are unchanged, as are Receiver states R0 through R2.
The remaining FTS-0001 states are enhanced to implement the Bark file
request protocol. In addition, the subroutine state tables "Send Bark SB0"
and "Receive Bark RB0" have been added to handle the actual file requests.
The following diagrams fully replace the Session Layer protocol state
tables in FTS-0001. No other changes to FTS-0001 are required to implement
the Bark File request feature.
Sender (Top level)
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| S0 | SendInit | | dial modem | S1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| S1 | WaitCxD |1| carrier detected | delay 1-5 seconds | S2 |
| | (*1) | | | Set SLO if > 2400bps, | |
| | | | | Reset SLO if <= 2400bps | |
| | +-+-----------------------+-------------------------+-----+
| | |2| busy, etc. | report no connection | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| voice | report no carrier | exit|
| | +-+-----------------------+-------------------------+-----+
| | |4| carrier not detected | report no connection | exit|
| | | | within 60 seconds | | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S2 | WhackCRs |1| over 30 seconds | report no response <cr> | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| ?? <cr>s received | delay 1 sec | S3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| <cr>s not received | send <cr> <sp> <cr> <sp>| S2 |
| | | | | delay ??? secs | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S3 | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH | S4 |
| | +-+-----------------------+-------------------------+-----+
| | |2| over 60 seconds | hang up, report garbage | exit|
| | | | and line not clear | | |
+-----+----------+-+-----------------------+-------------------------+-----+
| S4 | SendMail | | (Send Mail SM0) | S5 |
+-----+----------+-+-----------------------+-------------------------+-----+
| S5 | TryPickup|1| Rcv TSYNC | (Receive Mail RM0) | S5 |
| | (*2) +-+-----------------------+-------------------------+-----+
| | |2| Rcv SYN | (Receive Bark Req RB0) | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv ENQ | (Do Bark Requests SB0) | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |4| Rcv 'C' or NAK | Send EOT | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |5| Rcv Other Char | Send SUB | S5 |
| | +-+-----------------------+-------------------------+-----+
| | |6| No Data for 45 secs | Hang Up | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - This state is shown for the extended SEAlink protocol. Omit the
set/reset SLO actions if adding Bark to a strict FTS-0001 protocol
implementation, or if not implementing overdrive in SEAdog.
*2 - To refuse to pickup mail (S5.1) may send a CAN and stay in (S5).
Note: Although the above shows the sender emitting only one TSYNCH, it is
recommended that a timeout of 5-20 seconds should initiate another TSYNCH.
The receiver should tolerate multiple TSYNCHs.
Receiver (Top Level)
The receiving FSM is given an external timer, the expiration of which
will cause termination with a result of 'no calls' (R0.2).
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| R0 | WaitCxD |1| carrier detected | | R1 |
| | +-+-----------------------+-------------------------+-----+
| | |2| external timer expires| report no calls | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R1 | WaitBaud |1| baud rate detected | send signon with <cr>s | R2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| no detect in ?? secs | hang up, report no baud | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R2 | WaitTsync|1| TSYNCH received | ignore input not TSYNCH | R3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| 60 seconds timeout | hang up, report not Fido| exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R3 | RecMail | | (Receive Mail RM0) | R4 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R4 | AllowPkup|1| Have pickup for sender| Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |2| No pickup for sender | | R6 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R5 | WtPickup |1| Rcv NAK or 'C' | (Send Mail SM0) | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv SUB | Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv CAN | Report Mail Refused | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |4| T1 expired | Send Tsync, | R5 |
| | | | | Set T1=1 sec | |
| | +-+-----------------------+-------------------------+-----+
| | |5| 45 secs in R5 | Hang Up, report error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| R6 | AskBark |1| Wish to make requests | Send SYN | R7 |
| | (*1) +-+-----------------------+-------------------------+-----+
| | |2| No requests to make | | R8 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R7 | DoRequest|1| Rcv CAN | Report Requests Refused | R8 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv ENQ | (Send Bark SB0) | R8 |
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv SUB | Send SYN | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |4| Rcv NAK or 'C' | Send EOT | R6 |
| | +-+-----------------------+-------------------------+-----+
| | |5| Rcv Other | eat character | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |6| 5 sec, no input | Send SYN | R7 |
| | +-+-----------------------+-------------------------+-----+
| | |7| 45 secs in R7 | | R8 |
+-----+----------+-+-----------------------+-------------------------+-----+
| R8 | WtPickup |1| Allow File Request | (Receive Bark RB0), | exit|
| | | | | Hang Up | |
| | +-+-----------------------+-------------------------+-----+
| | |2| Disallow Requests | Hang Up | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - Some implementations always do (R6.1) even if they have no requests.
Sender - Send Mail
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| SM0 | SendMail | | (XMODEM send packet XS0)| SM1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SM1 | CheckMail|1| XMODEM successful | (Fido registers success)| SM2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| XMODEM fail or timeout| hang up, report mail bad| exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| SM2 | SendFiles| | (BATCH send files BS0) | SM3 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SM3 | CheckFile|1| BATCH send successful | report success | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| BATCH send failed | hang up, rept files fail| exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender - Send Bark
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB0 | SendBark |1| File to request | Build Bark Request Pkt, | SB1 |
| | | | | Set tries = 0 | |
| | +-+-----------------------+-------------------------+-----+
| | |2| No more files to req | Send ETB | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| SB1 | AskFile | | Send Bark Packet | SB2 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB2 | RcvFile |1| Rcv ACK | (Batch Receive BR0) | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Tries > 5 | Send ETB, report failed | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| Rcv Other | Purge input, Incr tries | SB1 |
| | +-+-----------------------+-------------------------+-----+
| | |4| 10 sec w/o ACK | Incr tries | SB1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| SB3 | NxtFile |1| Rcv ENQ | | SB0 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Rcv Other | Purge Input | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| 5 sec, no input | Send SUB | SB3 |
| | +-+-----------------------+-------------------------+-----+
| | |4| 45 sec in SB3 | Hang up, report error | exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender & Receiver - Receive Mail
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-------------------------+-------------------------+-----+
| RM0 | RecMail | | (XMODEM rec packet XR0) | RM1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RM1 | XRecEnd |1| XMODEM successful | delay 1 second | RM2 |
| | | | | flush input | |
| | +-+-----------------------+-------------------------+-----+
| | |2| XMODEM failed | hang up, rept mail fail | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RM2 | RecFiles | | (BATCH rec files BR0) | RM3 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RM3 | ChkFiles |1| BATCH recv successful | delay 2 secs, rprt good | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| BATCH recv failed | hang up, report bad file| exit|
`-----+----------+-+-----------------------+-------------------------+-----'
Sender & Receiver - Receive Bark
.-----+----------+-------------------------+-------------------------+-----.
|State| State | Predicate(s) | Action(s) | Next|
| # | Name | | | St |
+-----+----------+-+-----------------------+-------------------------+-----+
| RB0 | HonorReq |1| Ok to honor request | Purge Input, Send ENQ, | RB1 |
| | | | | Set T1 = 2 seconds | |
| | +-+-----------------------+-------------------------+-----+
| | |2| Don't wish to honor | Send CAN | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB1 | WaitBark |1| Got ACK | Rcv Bark Packet (*1) | RB2 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Got ETB | Report done | exit|
| | +-+-----------------------+-------------------------+-----+
| | |3| Got ENQ | Send ETB | RB0 |
| | +-+-----------------------+-------------------------+-----+
| | |4| T1 expired | Purge Input, Send ENQ, | RB1 |
| | | | | Set T1 = 2 seconds | |
| | +-+-----------------------+-------------------------+-----+
| | |5| 20 seconds in RB1 | Hang Up, Report error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB2 | AckBark |1| Bark Pkt Rcvd Good | Send ACK | RB3 |
| | +-+-----------------------+-------------------------+-----+
| | |2| Bark Pkt Rcv Error | Send NAK | RB1 |
+-----+----------+-+-----------------------+-------------------------+-----+
| RB3 | WaitStrt |1| Got 'C' or NAK | | RB4 |
| | +-+-----------------------+-------------------------+-----+
| | |2| No data for 3 seconds | Send ACK | RB3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| 15 seconds in RB3 | Hang Up, Report Error | exit|
+-----+----------+-+-----------------------+-------------------------+-----+
| RB4 | SendFile |1| Can snd requested file| (Batch Send File BS0) | RB0 |
| | (*2) +-+-----------------------+-------------------------+-----+
| | |2| Can't send file | Send EOT | RB0 |
`-----+----------+-+-----------------------+-------------------------+-----'
*1 - If SUB (16H) received before ETX go to RB0 to resync bark receive
*2 - While deciding if file exists, and if the password allows it to be
sent etc., a NUL may be sent to buy 20 seconds more on the timeout
on the other end if it is using the SEAlink extended FTS-0001
specification protocol. Sending a NUL is harmless for a strict
FTS-0001 session, but will not buy more time.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

104
html/ftsc/fts-0009.html Executable file
View File

@ -0,0 +1,104 @@
<HTML>
<HEAD>
<TITLE>Message identification and reply linkage.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: FTS-0009
Version: 001
Date: 17-Dec-91
MSGID / REPLY
A standard for unique message identifiers
and reply chain linkage
17 December, 1991
jim nutt
1:114/30@fidonet
Status of this document:
This FTS (FidoNet(r) Technical Standard) specifies an optional
standard for the FidoNet community. Implementation of the
protocols defined in this document is not mandatory, but all
implementations of these protocols are expected to adhere to this
standard. Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
MSGID
A MSGID line consists of the string "^AMSGID:" (where ^A is a
control-A (hex 01) and the double-quotes are not part of the
string), followed by a space, the address of the originating
system, and a serial number unique to that message on the
originating system, i.e.:
^AMSGID: origaddr serialno
The originating address should be specified in a form that
constitutes a valid return address for the originating network.
If the originating address is enclosed in double-quotes, the
entire string between the beginning and ending double-quotes is
considered to be the orginating address. A double-quote character
within a quoted address is represented by by two consecutive
double-quote characters. The serial number may be any eight
character hexadecimal number, as long as it is unique - no two
messages from a given system may have the same serial number
within a three years. The manner in which this serial number is
generated is left to the implementor.
REPLY
A REPLY line consists of the string "^AREPLY:" (where ^A is a
control-A (hex 01) and the double-quotes are not part of the
string), followed by a space, and the origaddr and serialno
fields of the MSGID line of the message to which this message is a
reply, i.e.:
^AREPLY: origaddr serialno
The origaddr and serialno fields must be identical to the
corresponding fields in the MSGID of the message to which this
message is a reply. A REPLY line is never generated in a
message that is a reply to a message that does not contain a
MSGID line.
GENERAL
MSGID and REPLY lines should be placed before the text body of the
message in which they appear.
Finally, a MSGID is generated only at the time of message
creation. An existing MSGID and/or REPLY should never be stripped
from a message passing through an intermediate system. No system
should ever add an MSGID and/or REPLY to, or modify an existing
MSGID / REPLY contained in, a message not originating on that
system.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

192
html/ftsc/fts-4001.html Executable file
View File

@ -0,0 +1,192 @@
<HTML>
<HEAD>
<TITLE>Addessing Control Paragraphs.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FTS-4001
Revision: 1
Title: ADDRESSING CONTROL PARAGRAPHS
Author(s): FTSC
Revision Date: 1 October 2000
Expiry Date: 1 October 2002
----------------------------------------------------------------------
Contents:
1. Credits
2. General
3. FMPT
4. TOPT
5. INTL
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standard (FTS).
This document specifies a Fidonet standard for the Fidonet
community.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
1. Credits
----------
This document is based on the work of Randy Bush and many others.
2. General
----------
The general control paragraph format is specified in separate FTSC
documents.
The addressing control paragraphs specified in this document are
normally only used in netmail messages and not in echomail messages.
While it would be technically correct to use them also in echomail,
it is known that certain programs will misbehave if they are present
there. It is therefore recommended that they should not be used in
echomail at the present time.
If a program processing messages detects these control paragraphs in
an echomail message it is recommended that they are disregarded and
deleted from any copies of that message exported to other systems.
Addressing of and address resolution for echomail messages should
instead be done with the help of packet and message header
information. See separate FTSC documents.
To determine the address of the original sender of an echomail
message, the information in the Origin line should be used. See
separate FTSC documents.
3. FMPT
-------
The FMPT control paragraph shall be used to give information about
the point number of the original sender of a message if that point
number is not 0. If the point number of the original sender of a
message is 0 that message should not contain any FMPT control
paragraph.
The format of a FMPT control paragraph shall be:
&lt;SOH&gt;"FMPT &lt;point number&gt;"&lt;CR&gt;
where &lt;point number&gt; is the ASCII representation of the point number
of the sender. The point number shall be an unsigned integer in the
range 1-65535.
E.g. a message from point number 1 of a certain node shall contain
the following FMPT control paragraph
&lt;SOH&gt;"FMPT 1"&lt;CR&gt;
Note that the format of a FMPT control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
4. TOPT
-------
The TOPT control paragraph shall be used to give information about
the point number of the ultimate addressee of a message if that
point number is not 0. If the point number of the ultimate addressee
of a message is 0 that message should not contain any TOPT control
paragraph.
The format of a TOPT control paragraph shall be:
&lt;SOH&gt;"TOPT "&lt;point number&gt;&lt;CR&gt;
where &lt;point number&gt; is the ASCII representation of the point number
of the addressee. The point number shall be an unsigned integer in
the range 1-65535.
E.g. a message to point number 1 of a certain node shall contain the
following TOPT control paragraph
&lt;SOH&gt;"TOPT 1"&lt;CR&gt;
Note that the format of a TOPT control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
5. INTL
-------
The INTL control paragraph shall be used to give information about
the zone numbers of the original sender and the ultimate addressee
of a message.
The format of an INTL control paragraph shall be:
&lt;SOH&gt;"INTL "&lt;destination address&gt;" "&lt;origin address&gt;&lt;CR&gt;
where &lt;destination address&gt; shall be the representation of the
address of ultimate destination and &lt;origin address&gt; is the
representation of the address of the original sender of the message
in question. These addresses shall be given on the form
&lt;zone&gt;:&lt;net&gt;/&lt;node&gt; where &lt;zone&gt; is the ASCII representation of the
zone number, &lt;net&gt; is the ASCII representation of the net number and
&lt;node&gt; is the ASCII representation of the node number. Any point
number information shall be given in FMPT and TOPT control
paragraphs.
E.g. a message from address 1:123/4.5 to 2:345/6.7 shall contain the
following INTL control paragraph
&lt;SOH&gt;"INTL 2:345/6 1:123/4"&lt;CR&gt;
Note that the format of an INTL control paragraph deviates from the
general format specified in separate FTSC documents in that it does
not contain any colon after the control tag.
INTL control paragraphs are also often used even when both the
originating and the destination systems are in the same zone. This
gives both the originating system and the destination system as well
as any intermediate routing systems unambiguous zone information
even in a situation where one system may be active in a number of
different (possibly non-FidoNet) zones.
Although it is known that some programs may route messages
incorrectly if the INTL control paragraph is present in messages
where both the originating and the destination systems are in the
same zone, it is recommended that the INTL control paragraph is
always inserted into netmail messages in packet files.
A. History
----------
Rev.1, 20001001: Initial Release.
Principal author Goran Eriksson.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

311
html/ftsc/ftscprod.html Executable file
View File

@ -0,0 +1,311 @@
<HTML>
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<H2><DIV align=center>FTSC Product codes 22 jan 2000</DIV></H2><P>
<PRE>
0000,Fido,MS-DOS,Packer/mailer,Tom_Jennings,1:125/111
0001,Rover,MS-DOS,Packer/mailer,Bob_Hartman,1:104/501
0002,SEAdog,MS-DOS,Packer/mailer,Thom_Henderson,1:107/542.1
0003,WinDog,MS-DOS,Mailer,Solar_Wind_Computing,1:115/333
0004,Slick-150,HP-150,Packer/mailer,Jerry_Bain,????
0005,Opus,MS-DOS,Packer/mailer,Doug_Boone,1:124/4227
0006,Dutchie,MS-DOS,Packer/mailer,Henk_Wevers,2:500/1
0007,WPL_Library,Amiga,Mailer,Russell_McOrmand,1:163/109
0008,Tabby,Macintosh,Packer/mailer,Michael_Connick,1:107/412
0009,SWMail,OS/2,Mailer,Solar_Wind_Computing,1:115/333
000A,Wolf-68k,CPM-68k,Packer/mailer,Robert_Heller,1:321/153
000B,QMM,QNX,Packer/mailer,Rick_Duff,1:167/201
000C,FrontDoor,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
000D,GOmail,MS-DOS,Packer,Scott_Green,????
000E,FFGate,MS-DOS,Packer,Ruedi_Kneubuehler,2:301/580
000F,FileMgr,MS-DOS,Packer,Erik_van_Emmerik,2:281/611
0010,FIDZERCP,MS-DOS,Packer,Thorsten_Seidel,2:242/55
0011,MailMan,MS-DOS,Packer,Ron_Bemis,1:124/1113
0012,OOPS,MS-DOS,Packer,Tom_Kashuba,1:322/379
0013,GS-Point,Atari_ST,Packer/mailer,Harry_Lee,1:124/4230
0014,BGMail,????,????,Ray_Gwinn,1:265/104
0015,ComMotion/2,OS/2,Packer/mailer,Michael_Buenter,2:301/602
0016,OurBBS_Fidomailer,MS-DOS/Unix/Coherent,Packer/mailer,Brian_Keahl,1:133/524
0017,FidoPcb,MS-DOS,Packer,Matjaz_Koce,2:380/100
0018,WimpLink,Archimedes,Packer/mailer,Remco_de_Vreugd,2:283/307
0019,BinkScan,MS-DOS,Packer,Shawn_Stoddard,1:362/101
001A,D'Bridge,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
001B,BinkleyTerm,MS-DOS,Mailer,Vince_Perriello,1:343/491
001C,Yankee,MS-DOS,Packer,Randy_Edwards,????
001D,uuGate,MS-DOS,Packer,Geoff_Watts,3:690/710
001E,Daisy,Apple_][,Packer/mailer,Raymond_&_Ken_Lo,3:700/1
001F,Polar_Bear,????,Packer/mailer,Kenneth_McLeod,1:101/190
0020,The-Box,MS-DOS/Atari_ST,Packer/mailer,Jac_Kersing/Arjen_Lentz,2:283/333
0021,STARgate/2,OS/2,Packer/mailer,Shawn_Stoddard,1:362/101
0022,TMail,MS-DOS,Packer,Larry_Lewis,3:713/600.1701
0023,TCOMMail,MS-DOS,Packer/mailer,Mike_Ratledge,1:372/888
0024,GIGO,MS-DOS,Packer,Jason_Fesler,1:203/7707,,940228
0025,RBBSMail,MS-DOS,Packer,Jan_Terpstra,2:512/10
0026,Apple-Netmail,Apple_][,Packer/mailer,Bill_Fenner,1:129/87
0027,Chameleon,Amiga,Mailer,Juergen_Hermann,2:241/2.12
0028,Majik_Board,MS-DOS,Packer/mailer,Dale_Barnes,1:3601/14.20
0029,QM,MS-DOS,Packer,George_Peace,1:270/101
002A,Point_And_Click,Amiga,Packer,Rob_Tillotson,1:201/40.302
002B,Aurora_Three_Bundler,MS-DOS,Packer,Oliver_McDonald,????
002C,FourDog,MS-DOS,Packer,Shay_Walters,1:376/12
002D,MSG-PACK,MS-DOS,Packer,Tom_Hendricks,1:261/662
002E,AMAX,MS-DOS,Packer,Alan_Applegate,1:104/36
002F,Domain_Communication_System,????,????,Hal_Duprie,1:101/106
0030,LesRobot,????,Packer,Lennart_Svensonn,2:501/2
0031,Rose,MS-DOS,Packer/mailer,Glen_Jackson,1:100/617
0032,Paragon,Amiga,Packer/mailer,Jon_Radoff,1:322/545
0033,BinkleyTerm/oMMM/ST,Atari_ST,Packer/mailer,Bill_Scull,1:363/112,,19951209
0034,StarNet,Atari_ST,Mailer,Eric_Drewry,1:322/566
0035,ZzyZx,MS-DOS,Packer,Jason_Steck,1:124/424
0036,QEcho,MS-DOS,Packer,The_QuickBBS_Group,1:363/1701
0037,BOOM,MS-DOS,Packer,Andrew_Farmer,1:243/1
0038,PBBS,Amiga,Packer/mailer,Todd_Kover,1:261/1028
0039,TrapDoor,Amiga,Mailer,Maximilian_Hantsch,2:310/6
003A,Welmat,Amiga,Mailer,Russell_McOrmand,1:163/109
003B,NetGate,Unix-386,Packer,David_Nugent,3:632/348
003C,Odie,MS-DOS,Mailer,Matt_Farrenkopf,1:105/376
003D,Quick_Gimme,CPM-80/MS-DOS,Packer/mailer,Laeeth_Isaacs,2:254/18
003E,dbLink,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
003F,TosScan,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
0040,Beagle,MS-DOS,Mailer,Alexander_Holy,2:310/90
0041,Igor,MS-DOS,Mailer,Harry_Lee,1:124/4230
0042,TIMS,MS-DOS,Packer/mailer,Bit_Bucket_Software,1:104/501
0043,Phoenix,MS-DOS,Packer/mailer,International_Telecommunications,1:296/5,,19930624
0044,FrontDoor_APX,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
0045,XRS,MS-DOS,Packer,Mike_Ratledge,1:372/888
0046,Juliet_Mail_System,Amiga,Packer,Gregory_Kritsch,1:163/109.30
0047,Jabberwocky,Macintosh,Packer,Eric_Larson,1:2605/620
0048,XST,MS-DOS,Packer,Wayne_Michaels,1:380/100
0049,MailStorm,Amiga,Packer,Russel_Miranda,1:268/106
004A,BIX-Mail,????,Mailer,Bob_Hartman,1:104/501
004B,IMAIL,MS-DOS,Packer,IMAIL_INC.,2:246/47
004C,FTNGate,MS-DOS,Packer,Jason_Steck,1:104/424
004D,RealMail,MS-DOS,Packer,Taine_Gilliam,1:372/42
004E,Lora-CBIS,MS-DOS,Mailer,Marco_Maccaferri,2:332/402
004F,TDCS,PDP-11,Packer/mailer,Terry_Ebdon,2:254/6
0050,InterMail,MS-DOS,Packer/mailer,Peter_Stewart,1:369/35
0051,RFD,MS-DOS,Packer,Doug_Belkofer,1:234/10
0052,Yuppie!,MS-DOS,Packer,Leo_Moll,2:242/2
0053,EMMA,MS-DOS,Packer,Johan_Zwiekhorst,2:292/100
0054,QBoxMail,QDOS,Packer/mailer,Jan_Bredenbeek,2:283/500
0055,Number_4,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
0056,Number_5,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
0057,GSBBS,MS-DOS,Packer,Michelangelo_Jones,1:260/244
0058,Merlin,MS-DOS,Packer/mailer,Mark_Lewis,2:258/25
0059,TPCS,MS-DOS,Packer,Mikael_Kjellstrom,2:201/211
005A,Raid,MS-DOS,Packer,George_Peace,1:270/101
005B,Outpost,MS-DOS,Packer/mailer,Mike_Dailor,????
005C,Nizze,MS-DOS,Packer,Tomas_Nielsen,2:205/202
005D,Armadillo,Macintosh,Packer,Erik_Sea,1:221/109
005E,rfmail,Unix,Packer/mailer,Per_Lindqvist,2:201/332
005F,Msgtoss,MS-DOS,Packer,Mike_Zakharoff,1:343/36
0060,InfoTex,MS-DOS,Packer/mailer,Jan_Spooren,2:292/852
0061,GEcho,MS-DOS,Packer,Gerard_van_der_Land,2:283/555,951209
0062,CDEhost,MS-DOS,Packer,Dennis_D'Annunzio,1:379/28
0063,Pktize,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
0064,PC-RAIN,MS-DOS,Packer/mailer,Ray_Hyder,1:272/40
0065,Truffle,MS-DOS/OS2,Mailer,Mike_Rissa,2:504/59
0066,Foozle,Amiga,Packer,Peer_Hasselmeyer,2:247/4
0067,White_Pointer,Macintosh,Packer/mailer,Alastair_Rakine,3:680/820
0068,GateWorks,MS-DOS,Packer,Jamie_Penner,1:153/1025
0069,Portal_of_Power,MS-DOS,Mailer,Soren_Ager,2:230/12
006A,MacWoof,Macintosh,Packer/mailer,Craig_Vaughan,1:109/342
006B,Mosaic,MS-DOS,Packer,Christopher_King,1:103/315
006C,TPBEcho,MS-DOS,Packer,Gerd_Qualmann,2:242/1
006D,HandyMail,MS-DOS,Packer/mailer,jim_nutt,1:114/30
006E,EchoSmith,MS-DOS,Packer,Noel_Crow,1:170/409
006F,FileHost,MS-DOS,Packer,Mark_Cole,2:252/186
0070,SFTS,MS-DOS,Packer,Bruce_Anderson,1:3402/6
0071,Benjamin,MS-DOS,Packer/mailer,Stefan_Graf,2:245/4.5436
0072,RiBBS,OS9_(COCO),Packer/mailer,Ron_Bihler,1:104/54
0073,MP,MS-DOS,Packer,Ivan_Leong,6:600/28
0074,Ping,MS-DOS,Packer,David_Nugent,3:632/348
0075,Door2Europe,MS-DOS,Packer/mailer,Michaela_Schoebel,2:247/14
0076,SWIFT,MS-DOS,Packer/mailer,Hanno_van_der_Maas,2:500/2
0077,WMAIL,MS-DOS,Packer,Silvan_Calarco,2:334/100.2
0078,RATS,MS-DOS,Packer,Jason_DeCaro,1:260/205
0079,Harry_the_Dirty_Dog,OS2,Mailer/packer,George_Edwards,3:632/340.7
007A,Maximus-CBCS,MS-DOS/OS2,Packer,Scott_Dudley,1:249/106
007B,SwifEcho,MS-DOS,Packer,Dana_Bell,1:3801/8
007C,GCChost,Amiga,Packer,Davide_Massarenti,2:332/505.3
007D,RPX-Mail,MS-DOS,Packer,Joerg_Wirtgen,2:241/4034
007E,Tosser,MS-DOS,Packer,Albert_Ng,6:700/185
007F,TCL,MS-DOS,Packer,Ulf_Hedlund,2:201/602
0080,MsgTrack,MS-DOS,Packer,Andrew_Farmer,1:243/1
0081,FMail,MS-DOS/DOS_DPMI/OS2/WIN32,Packer,Folkert_Wijnstra,2:283/619
0082,Scantoss,MS-DOS,Packer,Michael_Matter,2:243/44.3443
0083,Point_Manager,Amiga,Packer,Pino_Aliberti,2:335/602.2,,19931012
0084,IMBINK,MS-DOS,Packer,Mike_Hartmann,2:246/48
0085,Simplex,MS-DOS/OS2,Packer,Chris_Laforet,1:152/401
0086,UMTP,MS-DOS,Packer,Byron_Copeland,1:272/26
0087,Indaba,MS-DOS,Packer,Pieter_Muller,5:7102/11
0088,Echomail_Engine,MS-DOS,Packer,Joe_Jared,1:103/200
0089,DragonMail,OS2,Packer,Patrick_O'Riva,1:143/37
008A,Prox,MS-DOS,Packer,Gerhard_Hoogterp,2:283/1.2
008B,Tick,MS-DOS/OS2,Packer,Barry_Geller,1:266/12
008C,RA-Echo,MS-DOS,Packer,Roger_Kirchhoff,2:245/4
008D,TrapToss,Amiga,Packer,Maximilian_Hantsch,2:310/6
008E,Babel,MS-DOS/OS2,Packer,Jorgen_Abrahamsen,2:230/100.9
008F,UMS,Amiga,Packer,Martin_Horneffer,2:242/7.9
0090,RWMail,MS-DOS,Packer,Remko_Westrik,2:285/309.5
0091,WildMail,MS-DOS,Packer,Derek_Koopowitz,1:161/502
0092,AlMAIL,MS-DOS,Packer,Alan_Leung,1:348/207
0093,XCS,MS-DOS,Packer,Rudi_Kusters,2:512/34.4
0094,Fone-Link,MS-DOS,Packer/mailer,Chris_Sloyan,1:269/602
0095,Dogfight,MS-DOS,Packer,Chris_Tyson,2:256/36
0096,Ascan,MS-DOS,Packer,Arjen_van_Loon,2:281/1.397
0097,FastMail,MS-DOS,Packer,Jan_Berends,2:282/5
0098,DoorMan,MS-DOS,Mailer,Christopher_Dean,1:105/70
0099,PhaedoZap,Atari_ST,Packer,Jeff_Mitchell,1:229/422
009A,SCREAM,MS-DOS,Packer/mailer,Jem_Miller,1:147/33
009B,MoonMail,MS-DOS,Packer/mailer,Hasse_Wigdahl,2:206/101
009C,Backdoor,Sinclair_QL,Packer,Erik_Slagter,2:283/500.3
009D,MailLink,Archimedes,Packer/mailer,Jan-Jaap_v._d._Geer,2:500/133.1138
009E,Mail_Manager,MS-DOS,Packer,Andreas_Brodowski,2:241/4006
009F,Black_Star,Xenix_386,Packer/mailer,Jac_Kersing,2:283/333
00A0,Bermuda,Atari_ST/MS-DOS,Packer,Jac_Kersing,2:283/333
00A1,PT,MS-DOS,Packer/mailer,Jerry_Andrew,1:109/426
00A2,UltiMail,MS-DOS,Mailer,Brett_Floren,1:363/1000
00A3,GMD,MS-DOS,Packer,John_Souvestre,1:396/1
00A4,FreeMail,MS-DOS,Packer,Chad_Nelson,1:109/536
00A5,Meliora,MS-DOS,Packer,Erik_van_Riper,1:107/230
00A6,Foodo,CPM-80,Packer/mailer,Ron_Murray,3:690/640.7
00A7,MSBBS,CPM-80,Packer,Marc_Newman,1:106/601
00A8,Boston_BBS,MS-DOS,Packer/mailer,Tom_Bradford,1:101/625
00A9,XenoMail,MS-DOS,Packer/mailer,Noah_Wood,1:284/14
00AA,XenoLink,Amiga,Packer/mailer,Jonathan_Forbes,1:250/642
00AB,ObjectMatrix,MS-DOS,Packer,Roberto_Ceccarelli,2:332/305.1
00AC,Milquetoast,Win3/MS-DOS,Mailer,Vince_Perriello,1:343/491
00AD,PipBase,MS-DOS,Packer,Roberto_Piola,2:334/306
00AE,EzyMail,MS-DOS,Packer,Peter_Davies,3:636/204
00AF,FastEcho,MS-DOS,Packer,Tobias_Burchhardt,2:245/39
00B0,IOS,Atari_ST/TT,Packer,Rinaldo_Visscher,2:280/3.1
00B1,Communique,MS-DOS,Packer,Ian_Harris,3:620/251
00B2,PointMail,MS-DOS,Packer,Michele_Clinco,2:331/302.11
00B3,Harvey's_Robot,MS-DOS,Packer,Harvey_Parisien,1:249/114
00B4,2daPoint,MS-DOS,Packer,Ron_Pritchett,1:376/74
00B5,CommLink,MS-DOS,Mailer,Steve_Shapiro,1:382/35
00B6,fronttoss,MS-DOS,Packer,Dirk_Astrath,2:241/5603
00B7,SysopPoint,MS-DOS,Packer,Rudolf_Heeb,2:243/44
00B8,PTMAIL,MS-DOS,Packer,Arturo_Krogulski,2:341/27.7
00B9,MHS,MS-DOS/OS2/WINNT,Packer/mailer,Matthias_Hertzog,2:301/402,,19940310
00BA,DLGMail,Amiga,Packer,Steve_Lewis,1:114/52
00BB,GatePrep,MS-DOS,Packer,Andrew_Allen,1:382/92
00BC,Spoint,MS-DOS,Packer,Conrad_Thompson,1:130/29.106
00BD,TurboMail,MS-DOS,Packer,B._J._Weschke,1:2606/403
00BE,FXMAIL,MS-DOS,Packer,Kenneth_Roach,1:208/401
00BF,NextBBS,MS-DOS,Packer/mailer,Tomas_Hood,1:352/777
00C0,EchoToss,MS-DOS,Packer,Mikel_Beck,1:107/218
00C1,SilverBox,Amiga,Packer,David_Lebel,1:240/516
00C2,MBMail,MS-DOS,Packer,Ruud_Uphoff,2:500/116.1928
00C3,SkyFreq,Amiga,Packer,Luca_Spada,2:331/106
00C4,ProMailer,Amiga,Mailer,Ivan_Pintori,2:335/311.21
00C5,Mega_Mail,MS-DOS,Packer/mailer,Mirko_Mucko,2:242/94
00C6,YaBom,MS-DOS,Packer,Berin_Lautenbach,3:620/248
00C7,TachEcho,MS-DOS,Packer,Tom_Zacios,1:107/376
00C8,XAP,MS-DOS,Packer,Jeroen_Smulders,2:512/1.8
00C9,EZMAIL,MS-DOS,Packer,Torben_Paving,2:234/41
00CA,Arc-Binkley,Archimedes,Mailer,Geoff_Riley,2:250/208
00CB,Roser,MS-DOS,Packer,Chan_Kafai,6:700/158
00CC,UU2,MS-DOS,Packer,Dmitri_Zavalishin,2:5020/32
00CD,NMS,MS-DOS,Packer/mailer,Michiel_de.Bruijn,2:285/505.2
00CE,BBCSCAN,Archimedes,Packer/mailer,E._G._Snel,2:512/222.17
00CF,XBBS,MS-DOS,Packer,Mark_Kimes,1:380/16
00D0,LoTek_Vzrul,,Packer/mailer,Kevin_Gates,gates@sasknet.sk.ca,19951229,20000122
00D1,Private_Point_Project,MS-DOS,Packer,Oliver_von_Bueren,2:301/701
00D2,NoSnail,MS-DOS,Packer,Eddie_Rowe,1:19/124
00D3,SmlNet,MS-DOS,Packer,Steve_T._Gove,1:106/6
00D4,STIR,MS-DOS,Packer,Paul_Martin,2:250/107.3
00D5,RiscBBS,Archimedes,Packer,Carl_Declerck,2:292/500.10
00D6,Hercules,Amiga,Packer/mailer,Andrew_Gray,1:231/590
00D7,AMPRGATE,MS-DOS,Packer/mailer,Mike_Bilow,1:323/120.1
00D8,BinkEMSI,MS-DOS,Mailer,Tobias_Burchhardt,2:245/39
00D9,EditMsg,MS-DOS,Packer,G._K._Pace,1:374/26
00DA,Roof,Amiga,Packer,Robert_Williamson,1:167/104
00DB,QwkPkt,MS-DOS,Packer,Ross_West,1:250/412
00DC,MARISCAN,MS-DOS,Packer,Mario_Elkati,2:341/14.9
00DD,NewsFlash,MS-DOS,Packer,Chris_Lueders,2:241/5306
00DE,Paradise,MS-DOS,Packer/mailer,Kenneth_Wall,1:300/5
00DF,DogMatic-ACB,N/A,Packer/mailer,Martin_Allard,2:245/48
00E0,T-Mail,MS-DOS,Packer/mailer,Andy_Elkin,2:5030/15
00E1,JetMail,Atari_ST/STE/TT,Packer,Daniel_Roesen,2:243/93.8
00E2,MainDoor,MS-DOS,Packer/mailer,Francisco_Sedano,2:341/20
00E3,Starnet_Products,MS-DOS/OS2,Mailer/Packer,Starnet_Software_Development,1:102/925,,19951209
00E4,BMB,Amiga,Packer,Dentato_Remo,2:335/311.33
00E5,BNP,MS-DOS,Packer,Nathan_Moschkin,1:109/427
00E6,MailMaster,MS-DOS,Packer/mailer,Gary_Murphy,1:130/85
00E7,Mail_Manager_+Plus+,MS-DOS,Packer,Chip_Morrow,1:226/1240
00E8,BloufGate,Atari_ST/Unix,Packer,Vincent_Pomey,2:320/100.2
00E9,CrossPoint,MS-DOS,Packer/mailer,Peter_Mandrella,2:2454/97.80,19920713,19960601
00EA,DeltaEcho,MS-DOS,Packer,Mikael_Staldal,2:201/337
00EB,ALLFIX,MS-DOS,Packer,Harald_Harms,2:512/145
00EC,NetWay,Archimedes,Mailer,Steve_Haslam,2:250/116.3
00ED,MARSmail,Atari_ST,Packer,Folkert_val_Heusden,2:285/750.2,,19940122
00EE,ITRACK,MS-DOS/OS2,Packer,Frank_Prade,2:2480/55,,19990119
00EF,GateUtil,MS-DOS,Packer,Michael_Skurka,1:397/2.1
00F0,Bert,MS-DOS,Packer/mailer,Arnim_Wiezer,2:241/2104.9
00F1,Techno,MS-DOS,Packer,Patrik_Holmsten,2:203/133
00F2,AutoMail,MS-DOS,Packer,Mats_Wallin,2:201/239
00F3,April,Amiga,Packer,Nick_de_Jong,2:282/309.3
00F4,Amanda,MS-DOS,Packer,David_Douthitt,1:121/99.14
00F5,NmFwd,MS-DOS,Packer,Alberto_Pasquale,2:332/504
00F6,FileScan,MS-DOS,Packer,Matthias_Duesterhoeft,2:241/4512.2
00F7,FredMail,MS-DOS,Packer,Michael_Butler,3:712/515
00F8,TP_Kom,MS-DOS,Packer/mailer,Per_Sten,2:201/124
00F9,FidoZerb,MS-DOS,Packer,Ulrich_Schlechte,2:241/3410.12
00FA,!!MessageBase,MS-DOS,Packer/mailer,Holger_Lembke,2:240/500.20
00FB,EMFido,Amiga,Packer,Gary_Glendown,2:249/3.999
00FC,GS-Toss,MS-DOS,Packer,Marco_Bungalski,2:241/2021
00FD,QWKDoor,Atari_ST,Packer,Christian_Limpach,2:270/20.1
00FE,No_product_id_allocated,Any,Packer,No_Author,3:3/20
00FF,16-bit_product_id,Any,Packer/Mailer,No_Author,3:3/20
0100,Reserved,None,None,No_Author,3:3/20,19951209
0101,The_Brake!,Mailer,John_Gladkih,2:5051/16,19951209
0102,Zeus_BBS,Amiga,Mailer,Alex_May,2:441/58.0,19951209
0103,XenoPhobe-Mailer,Msdos/Windows/OS2/Linux,Mailer,Peter_Kling,1:374/969.0,19951209
0104,None,None,None,None,0:0/0,
0105,Terminate,Msdos/Os2/Windows,Mailer/Packer,SerWiz_Comm_&_Bo_Bendtsen,2:254/261,19951209
0106,TeleMail,Msdos,Mailer/Packer,Juergen_Weigelt,2:2453/900,19951209
0107,CMBBS,Msdos/Os2,Mailer/Packer,Christof_Engel,2:2490/5110,19951209
0108,Shuttle,Windows,Mailer/Packer,MCH_Development_&_Marvin_Hart,1:106/500,19951209
0109,Quater,Amiga,Mailer,Felice_Murolo,2:335/206,19951209
010A,Windo,Windows,Mailer,Alan_Chavis,1:147/55,19951209
010B,Xenia,Msdos/Os2,Mailer,Arjen_Lentz,2:283/512,19960601
010C,GMS,AmigaOS,Mailer,Mirko_Viviani,2:331/213,19960601
010D,HNET,Msdos,???,Pedro_Jaramillo,1:102/160,19960601
010E,Shotgun_Professional,Msdos,???,Brent_Shellenberg,1:140/146,19960621
010F,SLIPgate,Msdos,???,Kieran_Morrissey,3:634/376,19960723
0110,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
0111,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
01FF,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
02FF,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
03FF,Ravel,Macintosh,Mailer/Packer,Cyril_Moorzin,2:5030/700,19980310
04FF,Beemail,Windows,Mailer/Packer,Andrius_Cepaitis,2:470/1,19980310
05FF,QuickToss,DOS,Packer,Sandra_Godinez,1:387/601.3,19980310
06FF,SpaceMail,???,Mailer,Andreas_Habicht,2:244/6121,19980710
07FF,Argus,Windows/NT,Mailer,Max_Masyutin,2:469/84,19990216
08FF,Hurricane,Windows/NT/Solaris,Packer,Paul_Walker,2:254/175.44,19990216
09FF,Hub_Mailer,OS2,Mailer,Viatcheslav_Odintsov,2:5020/181,19990216
0AFF,FDInt,MSDOS,Packer,Colin_Turner,2:443/13,19990216
0BFF,GPMail,OS2,Mailer,Igor_Vanin,2:5030/448,19990216
0CFF,FTrack,NT/OS2,Tracker,Fyodor_Ustinov,2:5020/79,19990313
0DFF,Nice_Tosser,DOS/OS2/Win32,Tosser,Robert_Agababyan,2:5020/234.1,19990518
0EFF,LuckyGate,DOS/OS2/Linux,Packer,Pavel_Gulchouck,2:463/68,19990709
0FFF,McMail,DOS,Mailer,Simon_Slater,2:443/777,20000102
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

99
html/ftsc/index.htm Normal file
View File

@ -0,0 +1,99 @@
<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>Fidonet Standard Commitee documents.</TITLE>
<LINK rel=stylesheet HREF="../manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 08-Jun-2001</h5>
<P>&nbsp;<P>
<h1>Fidonet Technical Standards</h1>
<h3>Introduction</h3>
<P>
This is an overview of used documents for the development of the MBSE BBS
package. Note that there are more documents, but only the relevant and valid
documents are present here. Also note that these documents are just imported
into html documents without any changes.
<P>
Michiel Broek.
<P>
<hr>
<h3>FSC Documents</h3>
<ul>
<li><a href="fsc-0035.html">FSC-0035 Transparant Gateways to and from FidoNet, Michael Shiels</a>
<li><a href="fsc-0039.html">FSC-0039 A type-2 packet extension proposal M.Howard</a>
<li><a href="fsc-0046.html">FSC-0046 A Product Identifier for FidoNet Message Handlers, J.Homrighausen</a>
<li><a href="fsc-0048.html">FSC-0048 A Proposed type-2 packet extension, J.Vroonhof</a>
<li><a href="fsc-0049.html">FSC-0049 A proposal for passing domain information during FTS-0006 sessions, B.Hartman</a>
<li><a href="fsc-0050.html">FSC-0050 A character set identifier for FidoNet message editors, T.Sundblom</a>
<li><a href="fsc-0053.html">FSC-0053 Specifications for the ^aFLAGS field, J.Homrighausen</a>
<li><a href="fsc-0056.html">FSC-0056 EMSI/IEMSI Protocol Definition, J.Homrighausen</a>
<li><a href="fsc-0057.html">FSC-0057 Conference Managers - Specifications For Requests, F.Fabris, J.Homrighausen</a>
<li><a href="fsc-0059.html">FSC-0059 Newsgroup Interchange within FidoNet, J.Decker</a>
<li><a href="fsc-0062.html">FSC-0062 Nodelist Flag indicating Online Times, D.Thomas</a>
<li><a href="fsc-0070.html">FSC-0070 Improving FidoNet/UseNet Gating and Dupe checking, F.Arnoud</a>
<li><a href="fsc-0072.html">FSC-0072 The HYDRA file transfer protocol, J.Homrighausen, A.Lenz</a>
<li><a href="fsc-0087.html">FSC-0087 File forwarding in FidoNet technology networks, R.Williamson</a>
<li><a href="fsc-0088.html">FSC-0088 Compatibility and Link Qualifier Extensions for EMSI Sessions, R.Williamson</a>
<li><a href="fsc-0091.html">FSC-0091 ISDN nodelist flags (rev.002), A.Lenz</a>
<li><a href="fsc-0092.html">FSC-0092 New control lines for forwarded messages, M.Hohner</a>
<li><a href="fsc-0093.html">FSC-0093 Reduced seen-by lines, F.Ellermann</a>
</ul>
<P>
<h3>FSP Documents</h3>
<ul>
<li><a href="fsp-1001.html">FSP-1001 Timezone information in FTN messages, O.Sorensen</a>
<li><a href="fsp-1002.html">FSP-1002 Numeric reply indication in FTN subject lines, O.Sorensen</a>
<li><a href="fsp-1003.html">FSP-1003 Suggested use of Nodelist Fields, L.Kindness</a>
<li><a href="fsp-1004.html">FSP-1004 Standard Fidonet Addressing, L.Kindness</a>
<li><a href="fsp-1005.html">FSP-1005 Zone 2 nodelist flags, F.Ellermann</a>
<li><a href="fsp-1006.html">FSP-1006 Kludge for specifying e-mail reply addresses, R.v.d.Winkel</a>
<li><a href="fsp-1007.html">FSP-1007 Multiple recipient address specification to gateway, R.v.d.Winkel</a>
<li><a href="fsp-1008.html">FSP-1008 New control lines for forwarded messages, M.Hohner</a>
<li><a href="fsp-1009.html">FSP-1009 Year 2000 issues in FTN software, M.Hohner</a>
<li><a href="fsp-1010.html">FSP-1010 Via kludge line specification, C. Turner and J. Homrighausen</a>
<li><a href="fsp-1011.html">FSP-1011 BinkP - a protocol for transferring Fidonet mail over reliable connections, Dima Maloff</a>
</ul>
<P>
<h3>FTA Documents</h3>
<ul>
<li><a href="fta-1005.html">FTA-1005 FTSC Product ID</a>
<li><a href="ftscprod.html">FTSC Product codes list</A>
</ul>
<P>
<h3>FTS Documents</h3>
<ul>
<li><a href="fts-0001.html">FTS-0001 A basic FidoNet(r) technical standard, R.Bush</a>
<li>FTS-0002 Obsoleted by FTS-0005
<li>FTS-0003 Obsoleted by FTS-0006
<li><a href="fts-0004.html">FTS-0004 Echomail specification, B.Hartman</a>
<li><a href="fts-0005.html">FTS-0005 The distribution nodelist, B.Baker, R.Moore, D.Nugent</a>
<li><a href="fts-0006.html">FTS-0006 YOOHOO and YOOHOO/2U2, V.Perriello</a>
<li><a href="fts-0007.html">FTS-0007 SEAlink protocol extension, P.Becker</a>
<li><a href="fts-0008.html">FTS-0008 Bark file-request protocol extension, P.Becker</a>
<li><a href="fts-0009.html">FTS-0009 Message identification and reply linkage, J.Nutt</a>
<li><a href="fts-4001.html">FTS-4001 Addressing Control Paragraphs, Goran Eriksson</a>
</ul>
<HR>
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Index" Border="0" width="33" height="35">Back to Index</A>
</BLOCKQUOTE>
</BODY>
</HTML>

381
html/gwnews.html Executable file
View File

@ -0,0 +1,381 @@
<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 - Internet gateway - INN.</TITLE>
<LINK rel=stylesheet HREF="manual.css">
</HEAD>
<BODY>
<BLOCKQUOTE>
<h5>Last update 10-Apr-2001</h5>
<P>&nbsp;<P>
<H1 ALIGN="CENTER">MBSE BBS - Internet Gateway - INN.</H1>
<P>
<H3>SETUP INND</H3>
<P>
Below are the files that you need to setup for INN news. I used inn-2.2.2 on
my system. It is configured to install in /opt/news with the command
<strong>./configure --prefix=/opt/news</strong> during the installation of
inn.
<P>
<hr>
<pre>
<code>
## $Revision$
## inn.conf -- inn configuration data
## Format:
## <parameter>:<whitespace><value>
##
## See the inn.conf(5) man page for a full description of each
## of these options
##
## Blank values are allowed for certain parameters
## ---------------------------------
# All parameters must exist
#
organization: MBSE BBS Development Site
server: localhost
pathhost: news.mbse.nl
moderatormailer:
domain: mbse.nl
fromhost: news.mbse.nl
pathalias:
complaints: abuse@f2802.n280.z2.fidonet.org
mta: /usr/sbin/sendmail -oi %s
mailcmd: /opt/news/bin/innmail
checkincludedtext: false
maxforks: 10
maxartsize: 1000000
nicekids: 4
nicenewnews: 0
verifycancels: false
logcancelcomm: false
wanttrash: false
remembertrash: true
linecountfuzz: 0
peertimeout: 3600
clienttimeout: 600
allownewnews: true
localmaxartsize: 1000000
logartsize: true
logipaddr: true
logsitename: true
maxconnections: 50
artcutoff: 14
icdsynccount: 10
hiscachesize: 0
readertrack: false
strippostcc: false
status: 0
timer: 0
readerswhenstopped: false
noreader: false
extendeddbz: false
nnrpdoverstats: false
storeonxref: true
nnrpdcheckart: true
storemsgid: true
usecontrolchan: false
mergetogroups: false
backoffauth: false
backoffdb: /opt/news/db/backoff
backoffpostfast: 0L
backoffpostslow: 1L
backofftrigger: 10000L
mimeversion:
mimecontenttype:
mimeencoding:
refusecybercancels: false
activedenable: false
activedupdate: 30
activedport: 1119
nnrpperlauth: false
#
#
# These options are unlikely to need changing in most situations
#
chaninacttime: 600
chanretrytime: 300
pauseretrytime: 300
nntplinklog: false
nntpactsync: 200
badiocount: 5
blockbackoff: 120
#
# ---------------------------------
# Changing these options can have an effect on the way articles are
# stored and may require recreating the spool and/or database files
#
wireformat: false
xrefslave: false
nnrpdposthost:
nnrpdpostport: 119
spoolfirst: false
writelinks: true
storageapi: false
articlemmap: false
overviewmmap: true
bindaddress: all
sourceaddress: any
port: 119
#
## Keywords-in-overview options
## Enabling this without stopping innd and deleting the existing overview
## database and adding will probably confuse a lot of things. You must
## have compiled this support in too.
#
keywords: false
keylimit: 512
keyartlimit: 100000
keymaxwords: 250
#
# Other options
innflags:
doinnwatch: true
innwatchsleeptime: 600
pgpverify: false
controlfailnotice: false
logcycles: 3
innwatchpauseload: 1500
innwatchhiload: 2000
innwatchloload: 1000
innwatchspoolspace: 8000
innwatchbatchspace: 800
innwatchlibspace: 25000
innwatchspoolnodes: 200
docnfsstat: false
#
# ---------------------------------
# Paths to various aspects of the news system
#
pathnews: /opt/news
pathbin: /opt/news/bin
pathfilter: /opt/news/bin/filter
pathcontrol: /opt/news/bin/control
pathdb: /opt/news/db
pathetc: /opt/news/etc
pathrun: /opt/news/run
pathlog: /opt/news/log
pathhttp: /opt/news/log
pathtmp: /opt/news/tmp
pathspool: /opt/news/spool
patharticles: /opt/news/spool/articles
pathoverview: /opt/news/spool/overview
pathoutgoing: /opt/news/spool/outgoing
pathincoming: /opt/news/spool/incoming
patharchive: /opt/news/spool/archive
pathuniover: /opt/news/spool/uniover
overviewname: .overview
#
# ---------------------------------
#
</code>
</pre>
<hr>
<pre>
## $Revision$
## expire.ctl - expire control file
## Format:
## /remember/:&lt;keep&gt;
## &lt;patterns&gt;:&lt;modflag&gt;:&lt;keep&gt;:&lt;default&gt;:&lt;purge&gt;
## First line gives history retention; other lines specify expiration
## for newsgroups. Must have a "*:A:..." line which is the default.
## &lt;patterns&gt; wildmat-style patterns for the newsgroups
## &lt;modflag&gt; Pick one of M U A -- modifies pattern to be only
## moderated, unmoderated, or all groups
## &lt;keep&gt; Mininum number of days to keep article
## &lt;default&gt; Default number of days to keep the article
## &lt;purge&gt; Flush article after this many days
## &lt;keep&gt;, &lt;default&gt;, and &lt;purge&gt; can be floating-point numbers or the
## word "never." Times are based on when received unless -p is used;
## see expire.8
## If article expires before 14 days, we still remember it for 14 days in
## case we get offered it again. Depending on what you use for the innd
## -c flag and how paranoid you are about old news, you might want to
## make this 28, 30, etc.
/remember/:14
## Keep for 1-10 days, allow Expires headers to work.
*:A:1:10:never
fido.*:A:1:30:60
comp.*:A:1:30:60
local.*:A:1:30:60
nl.*:A:1:30:60
## Some particular groups stay forever.
# Keep FAQ's for a month, so they're always available
#*.answers:M:1:35:90
news.announce.*:M:1:35:90
# Some other recommendations. Uncomment if you want
# .announce groups tend to be low-traffic, high signal.
# *.announce:M:1:30:90
# Weather forecasts
# *.weather:A:1:2:7
# test posts
# *.test:A:1:1:1
## Some particular groups stay forever.
# dc.dining*:A:never:never:never
# uunet*:A:never:never:never
</pre>
<hr>
<pre>
## $Revision$
## Mailing addresses for moderators.
## Format:
## &lt;newsgroup&gt;:&lt;pathname&gt;
## First match found is used.
## &lt;newsgroup&gt; Shell-style newsgroup pattern or specific newsgroup
## &lt;pathname&gt; Mail address, "%s" becomes newgroup name with dots
## changed to dashes.
## Russian hierarchies
fido7.*:%s@fido7.ru
medlux.*:%s@news.medlux.ru
relcom.*:%s@moderators.relcom.ru
## Direct all public hierarchies to the master moderator database.
*:%s@moderators.isc.org
</pre>
<hr>
<pre>
## $Revision$
## newsfeeds - determine where Usenet articles get sent
## Format:
## site[/exclude,exclude...]\
## :pattern,pattern...[/distrib,distrib...]\
## :flag,flag...\
## :param
## Summary of flags:
## &lt;size Article must be less then size bytes.
## &gt;size Article must be more then size bytes.
## Aitems Article checks -- d (must have Distribution header)
## p (don't check for site in Path header)
## c (no control messages) C (only control messages)
## e (all groups must exist).
## Bhigh/low Internal buffer size before writing to output.
## Fname Name of the spool file.
## Gcount Crossposts limited to count groups.
## H[count] Article must have less then count hops; default is 1.
## Isize Internal buffer size (if a file feed)
## Nm Only moderated groups that match the patterns.
## Nu Only unmoderated groups that match the patterns.
## Ppriority Nice priority of channel or program feed.
## Ooriginator First field of X-Trace must match originator (wildmat).
## Ssize Start spooling if more than size bytes get queued.
## Ttype Feed types -- f (file) m (funnel; param names the
## real entry) p (pipe to program) c (send to stdin
## channel of param's sub-process) x (like c, but
## handles commands on stdin) x (log entry only).
## Witems What to write -- b (article bytesize) f (full path)
## g (first newsgroup) h (Message-ID hash)
## m (Message-ID) n (relative path) p (posted time)
## s (site that fed article) t (time received)
## * (names of funnel feed-in's or all sites that get
## the article) N (Newsgroups header) D (Distribution
## header) H (all headers) O (overview data)
## P (path header) R (replication information)
## Param field depends on T flag. For Tf, relative paths are from the
## out.going directory. For Tp and Tc, it is a shell command to execute.
## If a Tm refers to this entry (which will have its own T param) then "*"
## is expanded to all the funnel sites that triggered this one. Useful
## for spawning one mail process, e.g.
##
## This file is complicated -- see newsfeeds.5!
## This is the local site.
## The "pattern" field gives the initial subscription list for
## all other sites. You might want to put "!control,!junk,!<local>.*"
## there. The "distrib" subfield limits incoming articles.
##
## You can also have ME/bad.site: to refuse articles from a particular
## site (by matching the Path: entry). Other pseudo-sites may be put
## in here, to REFUSE certain types of 3rd-party cancel messages
## (See the "Cancel FAQ" news.admin.net-abuse.misc):
## cyberspam Spam cancels, munged articles, binary postings
## spewcancel just munged articles from runaway gateways
## bincancel just binary postings to non-binaries groups
##
## Note that refusing articles means you won't offer them to sites you feed
## Default of everything to everybody except for junk, control, anything
## with "local" as the newsgroup prefix (i.e. matches "localhost.stuff") or
## groups under foo. Articles posted to any group under alt.binaries.warez
## will not get propagated, even if they're cross posted to something that
## is.
ME\
:*,!junk,!control*,!foo.*/fido,local\
::
## news.wxs.nl via rpost (suck)
news.wxs.nl/news.wxs.nl:*,!control,!junk,!fido.*,!iba.*,!local.*/!local,!fido::
## News overview
# use this flag if storage api is used
#overview!:*:Tc,Ao,WhR,S30000:/opt/news/bin/overchan
# else
overview!:*:Tc,WO,S30000:/opt/news/bin/overchan
</pre>
<hr>
<pre>
## $Revision$
## distrib.pats -- specify default Distribution header for newsgroups
## Format:
## &lt;weight&gt;:&lt;pattern&gt;:&lt;value&gt;
## All articles are matched against all patterns, value to be used is the
## one with the highest weight.
## &lt;weight&gt; The weight assigned to this match, integer
## &lt;pattern&gt; Newsgroup name or single wildmat(3) pattern
## &lt;value&gt; Value of Distribution header.
##
##
## Uncomment to default all local.* groups to a distribution of local.
#10:local.*:local
10:local.*:local
10:fido.*:fido
</pre>
<hr>
<pre>
## $Revision$
## nnrp.access - access file for on-campus NNTP sites
## Format:
## &lt;host&gt;:&lt;perm&gt;:&lt;user&gt;:&lt;pass&gt;:&lt;groups&gt;
## &lt;host&gt;:&lt;/path/file&gt;
## Connecting host must be found in this file; the last match found is
## used, so put defaults first.
## &lt;host&gt; Wildcard name or IP address
## &lt;perm&gt; R to read; P to post
## &lt;user&gt; Username for authentication before posting
## &lt;pass&gt; Password, for same reason
## &lt;groups&gt; Newsgroup patterns that can be read or not read
## &lt;/path/file&gt; A second file to scan in the same format as this
## To disable posting put a space in the &lt;user&gt; and &lt;pass&gt; fields, since
## there is no way for client to enter one.
##
## Default is no access, no way to authentication, and no groups.
*::::!*
stdin:Read Post:::*
localhost:Read Post:::*
127.0.0.1:Read Post:::*
*.mbse.nl:Read Post:::*
</pre>
<hr>
<A HREF="./intergate.html"><IMG SRC="images/larrow.gif" ALT="Back" Border="0" width="40" height="30">Go back</A>
<A HREF="index.htm"><IMG SRC="images/b_arrow.gif" ALT="Home" Border="0" width="33" height="35">Go to main</A>
</BLOCKQUOTE>
</BODY>
</HTML>

BIN
html/images/b_arrow.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.3 KiB

BIN
html/images/connec.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

BIN
html/images/domains.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
html/images/e_menu.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
html/images/emareas.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
html/images/emgroup.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.0 KiB

BIN
html/images/fdb.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.2 KiB

BIN
html/images/fegroup.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.5 KiB

BIN
html/images/fileecho.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.3 KiB

BIN
html/images/filefind.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.0 KiB

BIN
html/images/files.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
html/images/go_to.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

BIN
html/images/hatch.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.6 KiB

BIN
html/images/language.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

BIN
html/images/larrow.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

BIN
html/images/magic.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.0 KiB

BIN
html/images/mbse.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
html/images/mbsetup0.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
html/images/mbsetup1.6.S.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.3 KiB

BIN
html/images/mbsetup1.6.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

BIN
html/images/mbsetup2.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.0 KiB

BIN
html/images/modems0.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.3 KiB

BIN
html/images/newfiles.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.6 KiB

Some files were not shown because too many files have changed in this diff Show More