Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/ISERV260.ZIP/ISERVCFG.HLP

Text File | 1996-04-03 | 27.7 KB | 699 lines

iServer 2.6 ∙ Internal Help File
──────────────────────────────────────────────────────────────────────────
This is a context sensitive help file that is intended to be used with the
ISERVCFG.EXE program, and not directly viewed with a file reader.

Please run ISERVCFG.EXE and press F1 from anywhere for detailed help.
──────────────────────────────────────────────────────────────────────────
Press Ctrl-C to abort...






[]IRS
With iServer you can make your system automatically respond to messages
addressed to certain functions.  They can be very powerful for responding
to queries or running programs much like an automated full internet server.

For example, you could have an entry setup that when someone posted a
message to "[e-mail]" that it returns a help file to the poster
of the message.

You can also setup a function to respond to a message automatically with
a text file, but then also leave the message to the receiver, rather than
delete it.  For example, you could have "[e-mail]" that would
send a "thank you for your comments" text file immediately, but then leave
the comments for you to review later.

You can also run programs on demand, for example you could setup an
entry that when someone posted to "[e-mail]", that it
would run a program that could take their original message, and add it
to another text file.

When a program is shelled from iServer, it will create a file called
"REQUEST", this file will contain all the info about who the message
was from, to, subject, etc, along with the original text of the message.
When the shelled program returns, iServer will check for the existance
of a file called "RESPONSE", if it exists it will be posted back to
the original sender of the request.

  For example:

  User posts to "[e-mail]" you could run a program,
  even a batch file, like this:

  @echo off
  type REQUEST >> \THEFAQ.TXT
  copy THANKYOU.TXT RESPONSE

  This would copy the original message into a growing text file, and
  send them back a "thank you" message.

  Another example:

  You can get iServer to run other maintenance or utility programs
  when it sees messages to another user.  For example, if you are
  using Transx, you could get iServer to watch for messages to
  "[e-mail]" and run TRANSX.EXE when it saw an incoming
  message for that program.

There is one last function type, that allows a message to trigger
another program to run after it.  For example, you could setup
iServer so if it saw a message to "AreaFix", it would run your
areafix manager after it was done.  The reason that you would want
to run it after iServer is completed rather than right away, is
to avoid any sharing problems between the two applications
scanning the same netmail message area.

With these four options of the response function, you can automate
basically any part of your system with lots of infobots and custom
run-on-demand programs.

In addition, you can govern the format of the "REQUEST" file by
editing the "RESPOND.MSG" file in your iServer directory.

Limited to 3 responds in unregistered version.
[]RPE
When people post your system at "[e-mail]", the "someone"
part is called a "Trigger", you can setup some automated features or
information packages on what are called "Infobots"  What the Infobot
does is dependant on the "Type" that you have specified.

Trigger

 ■ This is the trigger part of the name that you want to use for
   your automated feature.

Type

 ■ You have four different types of Infobots available:

   Return message     This returns a textfile as a message to the sender
                      of the infobot request then deletes the original
                      message received.

   Reply and forward  This returns a textfile as a message to the sender
                      of the infobot request and leaves the original
                      message present.

   Run program        This creates a template file called "REQUEST" in the
                      iServer directory that contains information about the
                      sender of the message, it then executes an external
                      program, and upon returning, if there is a file
                      called "RESPONSE" it will post that to the sender of
                      the original message.  The original message is
                      deleted in this process.

   Delay Run Program  This is causes the external program to be run after
                      iServer has completed scanning the netmail directory.
                      iServer does not deleate the trigger message at this
                      time, and leaves that upto the called program to do
                      after it has finished processing it.

File

 ■ This is either the textfile name to send to the requester, or if the
   Type is "Run", it is the program to execute.

Subject

 ■ Whatever is in here will replace the old subject on any returned
   messages.  If it is blank, the original subject will be used when
   creating the reply.

For example, if someone posted a message:

  To: triggername            (the @yoursite.com is removed at the gateway)
  Fm: [e-mail]  (the requester of the information)
  Sb: Info please            (the original subject)

And you had a trigger called "triggername", that returned a textfile
and replaced the subject with "Your request", you would see the headers
of the new message look something like this:

  To: [e-mail]  (the requester of the information)
  Fm: servername             (the @yoursite.com is added at the gateway)
  Sb: Your request           (the new subject replaced)

This feature is great for setting up information services, such as:

  [e-mail]
  [e-mail]
  [e-mail]
  [e-mail]

Limited to 3 responds in unregistered version.
[]T
Tables are much like "Infobots" in the fact that they can return,
forward or execute programs when triggered.  The difference is that
instead of looking for a "[e-mail]", iServer can
scan "Tables" of names to search for a match.

Its main purpose is to be able to put userid names into classes of
functions.  For example, say you had a number of users that abused
your system, and you did not want to accept mail for them, you could
simply put all of their names into a table, and have any mail that
came in searched against that table.  If there was a match, you could
return the mail to the sender.

Here's the setup for the above example:

  Table : BADUSERS
  Type  : Return
  File  : \path\BADUSER.TXT

Now anytime a message came in that was addressed to a user that was
in the BADUSERS table, it would return a textfile "BADUSER.TXT" to
the sender of the message.

To put user names into a table, use the included program "TABLE.EXE"
The usage for TABLE.EXE is as follows:

  TABLE <tablename> <+|-><username>

For example to add the user "Bob User" to the BADUSERS table, you
would type: TABLE BADUSERS +Bob User

To remove Joe Smith from the same table, you would use this command
line instead: TABLE BADUSERS -Joe Smith

Another idea for a table is having a vacation notice.  You could
have "TABLE.EXE VACATION +User name" as an option from your BBS as
a "run an external program menu option".  The user could run it to
put themselves on a "vacation list", then you'd have a table entry
like this:

  Table : VACATION
  Type  : Reply and Forward
  File  : \path\VACATION.TXT

This would return a message to the sender letting them know that
the receiver might be a while before responding, and because the
Type is "Reply and Forward", the original message will be left for
them when they return.

Registered use only.
[]TE
Table

 ■ This is the name of the table file to scan.  It will be located in
   your main iServer directory with a .TBL extension.

Type

 ■ You have three different types of Infobots available:

   Return message     This returns a textfile as a message to the sender
                      of the infobot request then deletes the original
                      message received.

   Reply and forward  This returns a textfile as a message to the sender
                      of the infobot request and leaves the original
                      message present.

   Run program        This creates a template file called "REQUEST" in the
                      iServer directory that contains information about the
                      sender of the message, it then executes an external
                      program, and upon returning, if there is a file
                      called "RESPONSE" it will post that to the sender of
                      the original message.  The original message is
                      deleted in this process.

File

 ■ This is either the textfile name to send to the requester, or if the
   Type is "Run", it is the program to execute.

Registered use only.
[]RTE
Restrict

 ■ This is the site or function that you want to restrict.   It will be
   searched for in the destination address, as well as the subject.

 ■ Partial matches are also found, therefore restricting "SUBSC" also
   restricts "SUBSCRIBE", etc..

Flag override

 ■ If you wish users with a certain flag to be able to access this site
   still, you can do so by placing the flag required here.  This is great
   for allowing certain users access to certain sites while restricting
   others from posting to it.

 ■ To erase a flag that is already set, simply replace the flag with
   spaces and hit enter.

Limited to 3 restricts in unregistered version.
[]ME
Trigger

 ■ This is the name you want to trigger on.  It must be exactly the
   way the messages arrive at your system.

Trigger on

 ■ This can be "To" or "From".  For "To", it means that you want to
   look at who the message is to, and if it matches, consider the message
   to be destined for the public base.

 ■ Note that for inbound messages, your domain name is not included, for
   example if you subscribed to a mailing list from the account name
   "[e-mail]" the trigger should be "ml1" if using the "To" method.

 ■ If all the messages come "From" a specific user, you can use the second
   method, and look at who the message is from.  For example, if all the
   messages were posted from "[e-mail]", you would put
   that full name as the Trigger.

   For example:

   From : [e-mail]
   To   : fakename

Basename

 ■ This is the path of the public base that the mail should be merged
   into.  Currently only JAM is supported, and the format should follow
   the same as the main message base path.

Outbound

 ■ This parameter controls whether or not the mail base will be scanned
   for outgoing messages.  This is good for news letters and other such
   lists that you do not want users being able to reply to.  You can of
   course specify the area as Read-Only in your BBS setup (suggested) but
   by selecting this here, iServer will bypass the scanning of this area,
   thus increasing processing speed.

 ■ If you do allow replies, any found will be exported as standard
   internet email.
[]M
Another great feature of iServer, is its ability to take mailing lists
and merge them into a public reading base.  This is great if you want
to subscribe to a popular mailing list, and make it available to all
your users without them all having to subscribe to it themselves, and
receiving multiple copies of the same messages.

You could subscribe to the mailing list with a psuedo-name, and use
this merge function to detect mail to this psuedo-name and import
it into the public base.

For example:  1) Subscribe to a list using a fake user name
                 "[e-mail]"

              2) Mail comes into "ml1" and merge sees it and
                 imports it into a public base you define.

More information regarding the field setup in merge is available
by pressing "Insert" to insert a new merge, and then pressing "F1"
for help on the field options.
[]RS
This is one of the most powerful features of iServer that will allow
you to setup subscription levels, or simply restrict access to certain
functions if your gateway is long distance, or does not accept certain
types of functions or requests.

Any outgoing messages that have any of the names listed in the restrict
section or any partial matches thereof in "to" address or the first word
in the subject line, will be considered to be restricted.  You may
override certain restricts with a user flag if you wish.

Example: SUBSC      A2  (Restricts "SUBSC" unless user has flag A2)
         LISTSERV   A2  (Restricts "LISTSERV" unless user has flag A2)
         FTP            (Restricts "FTP" always)

Since you can use a flag to override certain sites, it is excellent as
a tool to help promote finacial support of your internet email services.

Limited to 3 restricts in unregistered version.
[]I
Messages addressed to "ignored" names will remain in the netmail folder
as if iServer had never seen them.  It is good for leaving requests
upto other programs, or if you wish your personal mail to be leave in
your netmail folder, you can place your name in an "ignore".

Example: ALLFIX
         AREAFIX
         PETE ROCCA
[]A
By default, encodeded files (such as UUENCODE, BASE64, MIME, etc) are
bounced when attempting to be exported, however you can override this
for certain users or users with certain flags, or disable the
restrictions for all users, using any of the following 3 methods.

     Example: PETE ROCCA
              A2
              ALL

This would allow "PETE ROCCA", users with flag "A2", or "ALL" users,
respectively, to post encoded files.  You can use a combination of
these settings to tailor the restrictions to exactly your requirements.
[]UE
One of the nice features of iServer, is that it allows your users to
change their handle on the BBS to something that is more appropriate
for internet email addresses.  For example, the user "Pete Rocca" might
change his handle to "rocca"

What is special about allowing iServer to do it, instead of your BBS
is that it allows you to restrict certain handles from being used, as
well as giving you the option to only allow users to change it once,
since if the user is constantly changing their address, all the mail
to their old address will be returned to sender since the old name no
longer exists on your system.

Userid selected flag

 ■ This is the flag that you wish to have turned on once the user has
   selected an alias.

Min userid length

 ■ This is the minimum number of characters allowed in the userid.

Max userid length

 ■ This is the maximum number of characters allowed in the userid.

Bad handles

 ■ This is a list of names or partial names that you do not want users
   to be able to select.  The list is partially matched, so an entry
   of "ROOT" would also restrict "ROOTED", "DEROOT", etc..

   Some good defaults include:

     ROOT       POSTMASTER      WWW
     ADMIN      SYSOP           FTP

Once you have these options set, and you wish to allow your users
to use the handle option, you should present them with an option
to run ISERVER with the parameters "/USERID c:\path_to_dropfiles"
For example you would make menu option to shell:

  C:\ISERVER\ISERVER.EXE /USERID C:\RA

If you do use this option, don't forget to set the Internet email
area on your BBS to use "Handles" instead of "Real names"...

Also, a good way to run it so that it gets run only once, is to make
a menu option that is "Autoexecute=Yes" with the "Not flag" of whatever
flag you are to have set, that way if a user does not have the flag
set, it will run the "ISERVER.EXE /USERID" program automatically.
[]SA
Normally you would only process messages to your site address you are
using for your email, however if you wish to utilize some of the other
features in iServer, such as InfoBots and message bouncing for your
other addresses, you can list those akas that you wish iServer to process.
[]PL
If you are using the USERS.BBS type of userbase, then you can restrict
the number of messages a user below a certain security level can post
in a give period.  iServer will keep a record of these posts in the
LIMIT.DAT file which is located in the iServer directory, once a user
exceeds the number of messages in this database, their messages are
bounced back with the LIMIT.BAD template file.

When you wish to reset the counters, simply delete the LIMIT.DAT file.
For example, if you wanted to restrict users to a single message a day
you would specify "1" for the number of posts to restrict, and then
delete this file in your midnight maintenance. Likewise, if you wanted
to restrict to 100 messages a month, you would specify "100" and delete
the LIMIT.DAT file in your monthly maintenance.

If you do not wish to restrict any users, simply leave the values at
zero, and iServer will not use the limiting features.
[]MRM
Sometimes it is desired to remap one address to another, such as mapping
a fake account "[e-mail]" to "[e-mail]", this
way you can provide a generic userid and have it mapped into another
account, without having to create and maintain a special account on the
BBS for the original name.

You might also use this function to remap commonly misspelled versions
of your own name, or multiple accounts you might want to have presented
as valid.

     Some examples...

     Remap mailbox: POSTMASTER        -> SYSOP
     Remap mailbox: PETER ROCCA       -> PETE ROCCA
     Remap mailbox: ROCCAP            -> PETE ROCCA
[]GI
Domain

 ■ This is your domain name.  If you are feeding from a private gateway,
   your gateway will assign you a name. If you are feeding from your zone
   fidonet gateway then your domain is as such:

     f<node>.n<net>.z<zone>.fidonet.org

   For example, if your Site Address was 1:2401/305, your domain would be
   f305.n2401.z1.fidonet.org

   If your address has a point, simply preceed the address with p<point>
   for example 1:2401/305.10 would be p10.f305.n2401.z1.fidonet.org

Server Name

 ■ This option allows you to specify what name the server will use to
   bounce messages, and for response functions.

 ■ It is only cosmetic, so what you choose is not extreamly important,
   however some good suggestions are:

     mail-daemon
     mail-server
     server

Site Address

 ■ This is the fidonet address that you will be receiving the internet
   email to.  For basic setups, this will be your main fidonet address,
   however see the documentation on how to setup an optimal system that
   will not conflict with your regular netmail.

Uucp Address

 ■ This is the fidonet address of your gateway that will handle the
   email for you.  If you are using the free zone 1 gateway then the
   address should be 1:1/31, however if you are using a private gateway,
   you should ask your gateway what address to put in here.

Uucp Secondary

 ■ Most people will not need this function.  What it does is allow you
   to have to inbound UUCP feeds merged into the same email stream.  For
   example if you had two feeds you could place the fidonet address of
   the secondary feed here and have both of them converge in the same email
   base.

 ■ It should be noted that all outbound mail will be destined to the
   main Uucp Address.

Serial & Registration

 ■ This is where you place the serial and registration codes once you have
   registered iServer.
[]ARM
Sometimes it is desirable to remap mail going from one address to another.
This is good if you have users manually posting netmail to an incorrect
gateway that you would like redirected.

  Some examples...

  Remap address: 1:1/31            -> 1:2401/305.1000
  Remap mailbox: 1:2235/10.999     -> 1:2401/305.1000

You can also use it to redirect other kinds of mail, perhaps you have
two fidonet addresses, but would like them to converge into one area.
[]SO
Import mail to [e-mail]

 ■ If you wish to have mail that is addressed to [e-mail] imported
   into the internet email base with the public flag, rather than have the
   mail returned to sender then set this option to "Yes"

Convert "site!user" to "user@site"

 ■ Some UUCP providers will send you mail that looks like it's
   backwards.  If it looks like "site.com!user" instead of "[e-mail]",
   you may switch it around to the more preferred addressing method.

Delete fidonet information

 ■ If your email messages contain information in the fidonet control
   lines, and you do not wish them to be imported into the BBS, you
   can disable it with this function.

 ■ Some have reported that ProBoard locks up when importing large
   JAM kludges into the board, if this happens to you, you should
   consider deleting the fidonet information.

Retry underbars with periods

 ■ Some gateways incorrectly remap email -> user names by inserting
   underbars in names rather than periods.  If your gateway does this
   and you want to increase the chance of mail being imported to the
   user correctly, select "Yes".

   For example the gateway might map:

   [e-mail] instead of
   [e-mail]

   With this option on, iServer will try both variations to see if the
   user exists.

Cache tables at startup

 ■ If you are using "Tables" that you have setup in the Advanced Setup
   section, you can have the option to cache them at startup.

 ■ If you do not have very many table hits, it is a good idea to leave
   this off, however if you use the tables a lot, caching at startup
   will make iServer run much quicker.

Convert outbound addresses to lowercase

 ■ If you wish, you can convert all outbound addresses to be converted
   to lowercase.  For example "[e-mail]" would be coverted to
   "[e-mail]" This is usually a cosmetic preference option.

Set the "Keep/Sent" flag on netmail

 ■ When posting the outbound netmail, you can have the option to set
   the "Keep/Sent" flag.  Usually most will have this option turned off.

Set the "Direct" flag on netmail

 ■ When posting the outbound netmail, you can have the option to set
   the "Direct" flag, this is usually best left on unless you are
   routing your mail to your provider (ie 1:1/31)

Check for dumb outbound messages

 ■ iServer can check for outbound messages that are not addressed to
   a valid name, even before they leave your site.  Addresses that do not
   have the "@" or "!" symbol cannot be processed by most gateways, so
   rather than sending this mail to the gateway, iServer can bounce it
   back to the user immediately.

Always export "UUCP" in header

 ■ By default iServer attempts to put the destination address into
   the netmail "To" header.  If it cannot fit, it addresses the message
   "To: UUCP" and puts the address on the first line.

 ■ If you wish to always use the "To: UUCP" method, you can do so by
   selecting this option.

Delete mail from base once exported

 ■ Once iServer exports the message, it marks it as "sent" so it will not
   need to be processed again, however it leaves the message in the
   message base as many people like to be able to see what messages they
   have sent.  If you wish to remove the message from the BBS immediately
   after processing it, select "Yes"
[]FPC
Netmail path

 ■ This is the path to the netmail folder that your mailer uses for
   its *.MSG files.

User base

 ■ This is the filename of the file that stores all of the user
   information.  There are two Types available; RA and Text.  For RA
   it is the full path and filename of your USERS.BBS file.   For text,
   it is the path and filename of an ASCII text file containing valid
   user names.

Message base

 ■ This is the full path and filename of the path of the message base
   on the BBS.  Right now only JAM is supported, other formats will soon
   follow, including PCBoard.

   Example:  C:\MAIL\JAM\EMAIL  Type:JAM

   Would use the JAM base that created:

     C:\MAIL\JAM\EMAIL.JDT
     C:\MAIL\JAM\EMAIL.JDX
     C:\MAIL\JAM\EMAIL.JHR
     C:\MAIL\JAM\EMAIL.JLR

Log file

 ■ This is the name of the logfile that iServer will use to log mail
   traffic and events.  If you do not wish to use a log file, put NUL
   for the filename.

Update semaphore

 ■ When iServer modifies the netmail folder, it can notify other tasks
   to rescan the folder to see the changes.  Depending on what mailer
   you are using these file names will change.

 ■ For FrontDoor the names of the files are FDRESCAN.NOW and FMRESCAN.NOW
   and are located in your FD semaphore directory.

   Example:  C:\FD\FDRESCAN.NOW
             C:\FD\FMRESCAN.NOW

   Consult your mailer documentation for the correct semaphore file names
   for you to use.
[]EXIT
This allows you to exit the configuration program.  If you have made any
changes, it will prompt you to save any changes before exiting back to
the system prompt.
[]MAIN
┌──iServer───────────────────────────────────────────────────────────────┐
└────────────────────────────────────────────────────────────────────────┘

   What does it do?

   ■ iServer will import email from a fidonet netmail format directly
     into your RemoteAccess system as internet email.  No longer will
     your users have to know anything about addressing to "UUCP" at some
     obscure netmail address.

   ■ Of course, it will also export outbound mail from your BBS and
     prepare then in a netmail fashion, ready to be gated out.

   A complete solution!

   ■ iServer is not only a tosser for your mail, but a powerful server
     engine as well.  iServer can automatically bounce mail addressed
     to unknown users on your system, or respond to inbound messages
     automatically.  With iServer and its request/respond system, you
     can build powerful applications to interface with your basic email
     system, such as info-bots, listserv and ftpmail.

   ■ Outbound messages can be restricted on site, or user security
     settings and the number of messages posted per user.  You also
     have the option to restrict file transfers via email, such as
     UUENCODED, BASE64 or MIME formatted messages.  iServer integrates
     completely and seemlessly with your BBS system, using it's data
     files for user verification, as well as obtaining user security
     information for its message restricting features.

   Overview...

   ■ Seamless integration with RemoteAccess
   ■ Direct import/export of email
   ■ Powerful server response engine
   ■ Bounce messages to unknown users
   ■ Merge mailing lists as usegroups
   ■ Restrict certain sites, functions or encoded files
   ■ Custom templates for bounce messages
   ■ Dumb address checking
   ■ Disclaimer message support
   ■ Excellent author support

┌────────────────────────────────────────────────────────────────────────┐
└────────────────────────────────────────────────────────────────────────┘
[]