                              
                              
                              
                         FTP Serv-U
                              
                              
                FTP-Server Daemon for WinSock
                              
                              
                         Version 1.1
                              


















                    (c) 1995 Rob Beckers
                              
                          Cat Soft


                              

                         DISCLAIMER
			 ==========
                              
I  know, it's not the nicest way to start off. So let's just
get this part over with, OK?!

The  FTP  server  program Serv-U and its  documentation  are
copyright  Rob  Beckers.  It  is distributed  as  shareware,
giving  you the right to try it for a period of 30 days.  If
you  intend to use Serv-U after the initial try-out  period,
you are obliged to pay the registration fee.
The  next paragraph is a beautiful piece of prose.  In  just
two  sentences  it  says it all. Alas, unfortunately  it  is
necessary, so please bear with me.

This  software  is provided by the regents and  contributors
'as  is'  and any express or implied warranties,  including,
but   not   limited   to,   the   implied   warranties    of
merchantability  and  fitness for a particular  purpose  are
disclaimed.   In no event shall the regents or  contributors
be  liable  for  any direct, indirect, incidental,  special,
exemplary,  or  consequential damages  (including,  but  not
limited  to,  procurement of substitute goods  or  services;
loss  of  use,  data, or profits; or business  interruption)
however  caused and on any theory of liability,  whether  in
contract, strict liability, or tort (including negligence or
otherwise)  arising  in  any way out  of  the  use  of  this
software, even if advised of the possibility of such damage.
Contents


CONTENTS
========

Introduction                                               1

1. Making It Work - Installation                           3
  1.1 Installation                                         3
  1.2 De-installation                                      4
  1.3 Upgrading                                            4
  1.4 Known Bugs & Problems                                4
  1.5 Changes Since Version 1.00                           5
  1.6 A Word to the Wise (but paranoid)                    6

2. The Grand Tour - Menus                                  7
  2.1 The File Menu                                        7
  2.2 The Edit Menu                                        7
  2.3 The Setup Menu                                       7
  2.4 The Help Menu                                       14
  2.5 The Logfile and Screen                              14

3. The Inner Workings                                     15
  3.1 Serv-U Internals                                    15
  3.2 The SERV-U.INI File                                 15

4. Getting In Touch - Bugs & Registration                 21
  4.1 Reporting Bugs                                      21
  4.2 Registering Serv-U                                  21

Registration Form Serv-U                                  24


INTRODUCTION
============

Thank you for giving this program a try!

With  FTP  Serv-U your PC will be turned into a FTP  server.
This means that others on the computer network that you  are
connected  to  can access your PC to copy, move,  make,  and
delete files and directories, using the FTP protocol (FTP  =
File  Transfer  Protocol). This protocol  dictates  standard
ways  of  communicating  between  computers,  so  that  many
different  types  of  computers, using  different  operating
systems and file formats, can exchange information.
FTP  Serv-U  is a 'server' program and/or daemon.  The  term
daemon  comes from the ancient Greek mythology.  There,  the
Daemons  were  half-gods, acting as messengers  between  the
people  on  earth  and  the  gods.  This  FTP  server  acts,
likewise,  as  a  messenger for file  transfer  between  FTP
clients  and  your computer. Once started  it  sits  in  the
background  waiting  for a client to contact  it  and  after
communications  are  established, acting  out  the  client's
commands.
There  are  FTP  servers (and clients)  for  many  different
systems.  This particular program is meant for PC's  running
MS-Windows that have a WinSock version 1.1 compatible TCP/IP
stack installed.

Why  use  this  program and not one of the  many  other  FTP
servers that are available? For this I have to take you back
in time a little, to about a year ago. I needed a FTP server
to  make  some  files available to others and  tried  out  a
number  of server programs. One simply didn't work.  Another
would  work,  but as soon as someone started transferring  a
file from my PC it would lock up the whole machine until the
transfer  was complete. And then there was one  that  worked
fine,  but lacked all but the most basic security. So, after
endless  frustration I decided to write my own, figuring  it
couldn't  be  that hard. As usual things got a  bit  out  of
hand,  but  a year and over 11000 lines of C++ later  you're
looking at the result!
So what has this FTP server to offer?

     * Access for multiple clients at the same time.  Access
       for  'Anonymous' users. With the possibility to limit
       the  number of clients at any given time, so  your PC
       remains workable.
     * Lots of security! On a directory and even file basis.
       Allowing  different settings for  each  user,  and by
       putting   users   into   'groups'   permitting   easy
       maintenance  for large numbers of users. There's even
       an  option  to allow or prohibit clients on the basis
       of  their IP-number. Ideal if you want to let certain
       people  roam around your computer, but you don't want
       the  whole  world knocking at your door  (that is  to
       say: they can knock, but they won't get in).
     * It  allows  transfer  to or from  ports,  like  PRN:,
       LPT1:, COM1:, and AUX:. This allows you to setup your
       PC  as a print server by simply transferring the file
       to  be  printed to the desired port! Since  the ports
       are part of the regular security system, a user needs
       permission  to transfer to/from a port, allowing  you
       to control who can use it.
     * A  quite  complete  implementation, and  very  strict
       adherence  to the FTP standard (found in document RFC
       959).  Supports the 'passive' command  PASV.  This is
       needed  by  WWW-browsers and proxy  agents (something
       required   when  there  is  a  'firewall')  for   FTP
       transfer.  Another  feature  is  that  you  can   let
       'Anonymous' users always see the root directory ('\')
       as  their  login directory. This, again, is needed by
       some WWW-browsers to make FTP transfers work.
     * Easy to setup and maintain. Everything is  accessible
       through  menus,  and  for  automated  maintenance the
       settings are stored in an .INI file of simple format.
     * There is lots of logging! You can select how much  to
       log and where (to screen and/or file). The logfile is
       of a standard format to make machine reading easy, in
       case you need to do that for accounting purposes.
     * It  is fast! The file transfer speed you'll  get will
       be  very  close  to the maximum your TCP/IP  stack is
       capable  of   (well, assuming your FTP  client  is at
       least as fast of course).
     * Life  time free updates when registered  (as long  as
       Serv-U exists).
     * A very cute icon!
     * Compared to the commercial implementations, Serv-U is
       dirt cheap!

If  you didn't register this program, then you're looking at
the  try-out version of Serv-U. When started for  the  first
time,  it'll  let  you  choose between  a  fully  functional
program  or a somewhat crippled one. The text during startup
will  explain it clearly. If you choose the fully functional
version  then  there  is absolutely no difference  with  the
registered  version. But (yes, there had  to  be  a  'but'),
after  a  little over 30 days it will stop working. Counting
starts  the  first  time you run the  program.  I  warn  you
beforehand: re-installing it will not help you!

Before  I  forget  it: Thanks, Lars, Kyle,  Arend,  Michael,
Ryan,  Yiannis, Jozsef, Rick, and Brad for beta testing  and
turning  my  attempt at English into the  real  thing.  And,
Alun,  I  hope I didn't shock you too much by bringing  this
program out. You can't say I didn't warn you though ...

OK,  enough  sales  talk.  Let's continue  with  the  actual
documentation. First thing will be how to install Serv-U  to
get you in business.


1. MAKING IT WORK - INSTALLATION
================================

You're  eager  to get things going, but a little  afraid  of
what  lies  ahead. Never fear, it couldn't  be  simpler.  So
let's get started!

1.1 Installation

Nothing is simpler than installing Serv-U: just unzip it  in
the directory of your choice and run it. There is no need to
change your 'PATH' or put anything in other directories.

Serv-U comes with the following files:
     SERV-U.EXE          - The FTP-server executable itself
     SERV-U.DOC          - The documentation  in  MS-Word
                           format
     SERV-U.TXT          - The documentation in ASCII format
     README.TXT          - Something you have to read
     BWCC.DLL            - The Borland Custom Control  
                           library that creates the 3D-look
     REGISTER.TXT        - A registration form in ASCII format
     FILE_ID.DIZ         - Short description file for use by
                           bulletin boards

When  Serv-U  is started for the first time, it creates  the
file:
      SERV-U.INI         - File containing all settings and
                           user information

The  only fine point you might want to pay attention  to  is
whether  or not you already have the file BWCC.DLL  in  your
Windows directory.If so, you can delete the one in the Serv-
U  directory, but make sure it is the same version  (compare
the sizes)!

Serv-U  offers two very distinct ways to try  it  out.  Both
with  their  own advantages and disadvantages. When  started
for the first time (or in absence of a SERV-U.INI file),  it
will  show  you a screen explaining the two try-out  options
and allowing you to choose one of them. The first choice  is
a fully functional try-out version exactly equal to the real
thing,  but it will stop working after 30 and some days.  It
does  this  by  contacting  a  permission  server  over  the
Internet every time Serv-U is started. The permission server
(my  PC in fact) keeps track of when the program was started
for the first time and uses that information to determine if
it should be allowed to run this time, or not. It then sends
this answer back to Serv-U and the program will consequently
work  or  stop. To this effect, a network packet is sent  to
the  permission  server containing a version  code,  the  IP
number  of  your PC, and a run/norun flag. It receives  back
the  same packet with the flag set to run or stop.  This  is
all  that is communicated between the systems, nothing more,
nothing less!
The  second  choice is a try-out version  that  is  somewhat
crippled. It will only allow a total of 10 file transfers (5
PUTs  and 5 GETs), it will show a message saying it  is  not
registered to anyone who logs into the server, and  finally,
it  will only stay on-line for one hour. You have to restart
it  again  after that to get another hour. The advantage  is
that it will not contact another system over the network.
Just  to  make sure this is clear: Once Serv-U is registered
it will NEVER send anything over the network other than what
is needed for regular FTP traffic!

When  you  run Serv-U for the first time there  will  be  no
users  and  access will be restricted. To  change  this,  go
through  the  'Setup'  menu items and put  in  your  heart's
desires.  I  advise you to take a look at the next  chapter,
explaining  the various menus, since the security  setup  is
simple  but not totally intuitive (sorry for that, but ...).

For network use with a single executable shared between many
users  that need their own settings, the program  looks  for
the existence of an environment variable with the name SERV-
U. If this variable exists, it should be set to the path for
SERV-U.INI.  The program will then use this  file.  If  this
environment variable does not exist, the whole DOS  path  is
searched including the Windows directories. If a file  SERV-
U.INI  is  found somewhere it will be used,  this  way  also
allowing  for a single copy of the executable on  a  network
server  while  having  individual settings  for  each  user.
Finally,  if  SERV-U.INI was still not  found,  it  will  be
searched for and created if necessary in the default program
directory.

1.2 De-installation

It  is hard to imagine why, but if for some reason some  day
you  want to get rid of Serv-U then that is just as easy  as
was installing it. Just delete the whole directory where you
put  it,  and that's it! Serv-U does not change  any  system
files and does not place any files in other directories.

1.3 Upgrading

Upgrading  from an earlier version of Serv-U is  not  a  big
deal  either: Just copy the new .EXE file over the  old  one
and you're all set. Your old SERV-U.INI file will be used by
the new program so you don't have to re-install anything.

1.4 Known Bugs & Problems

At the time this documentation is being written there are no
known bugs left in the program. Everything that was found in
the 1.0x versions has been fixed. There are however still  a
number of known 'problems', even if they are not bugs as far
as I can tell. Let's go over them:

     * If you are using FTP Software Inc.'s  TCP/IP software
       and  WinSock stack, make sure you have version 2.3 of
       their  software  and v1.15.1 of their WINSOCK.DLL (or
       anything more recent). Older versions of their socket
       stack will give you a truck load of problems, and not
       just   with   Serv-U.  Their  latest  WINSOCK.DLL  is
       available via anonymous FTP from ftp.ftp.com.
     * According  to  my information, Serv-U does  not  work
       well   with  Sun's  PC-NFS  WinSock  stack,  nor with
       Chameleon's  stack.  As  far  as  I  could  trace the
       problems it seems that in both cases the socket stack
       is  to blame, it is simply not WinSock v1.1 compliant.
       If  you do get it to work (a new version may come out
       that  solves the problems) then please let me know so
       I can pass the advice on to others.
     * Netscape  works well with Serv-U, but it seems  never
       to  close  the  connection when  getting  a directory
       listing,  i.e. the big blue 'N' keeps 'pumping'. This
       is  definitely  a  Netscape bug.  I've  contacted the
       company  about it. Just ignore this behavior, it does
       not affect the actual operations.
 
1.5 Changes Since Version 1.00

Many  little  things were changed since v1.00. Most  of  you
will not notice the majority of the changes, but some of the
them were needed to fix pretty Big Bugs. Below is a list  of
what was done:

Version 1.1, released 19 March 1995:
   * Fixed  some spelling errors in messages. Fixed  logging
     to  screen for time-out messages. Added log message  in
     case  limit  of  nr.  of users is  reached.  Added  log
     message when server is (re)started.
   * Added lots of logging.
   * The  SYST command now replies with the code for a  UNIX
     system.  This  is  because  some  clients  use  it   to
     determine the format of directory listings.
   * Time-out values for idle/hung connections are now  part
     of server setup.
   * Drastically   increased  packet   time-out   for   data
     transfer, now set at 5 minutes (was 30 seconds). Should
     be   sufficient   to  allow  transfer   even   on   bad
     connections.
   * Log  messages  for  failed data transfers  now  have  a
     specification showing why.
   * Fixed  bug  that caused path for anonymous  users  with
     root as home directory to be  reported without a '\' at
     beginning. The same bug caused absolute paths in CWD to
     be processed incorrectly.
   * Changed  the HELP response to make WS_FTP work properly
     with Serv-U.
   * Added  support  for transfer to/from ports  (PRN:  AUX:
     LPTx: and COMx:).
   * Made  a work-around for FTP Inc.'s WinSock stack.  This
     stack  does not handle SO_LINGER properly on closing  a
     socket, causing 'data channel in use' errors.
   * Fixed bug that caused random truncation of PUT files in
     combination with some clients.
   * Fixed bug that allowed users to get 'dir' listings  for
     paths with explicitly no access set to them.
   * Fixed  bug causing 'dir' with absolute path name to  go
     wrong.
   * Changed  response messages to file transfers, only  the
     filename is shown now, not the path name.
   * Added  a  retry period for the server to  come  online.
     This  should solve problems with socket stacks that  do
     not  allow  to re-use a port immediately after  closing
     it.
   * Changed  the timing of the '150-' response message  for
     PASV   transfers.  It  is  now  sent  after  the   data
     connection is established instead of at the time  of  a
     transfer command.
   * The   listening   socket  will  now  automatically   be
     restarted when killed by the socket stack. Some  stacks
     kill  listening  sockets without  reason  (Trumpet  for
     one).
   * Fixed  a bug that made RMD (=remove directory) fail  if
     the  directory  was on a drive other  than  the  active
     drive.
   * Username 'FTP' is now synonymous to 'ANONYMOUS'.
   * Fixed bug in very long directory listings (>64K data).
   * Clients  that connect but never log in are  now  kicked
     off the system after 5 minutes.
   * User   can   now  select  the  try-out  method:   Fully
     functional  with contacts to my permission server,  or,
     crippled but no permission server contacts.
   * Installed  selectable  path  mechanism  for  anonymous:
     Either  absolute paths (like a regular  user)  allowing
     for  drive  changes,  or paths  relative  to  the  home
     directory (needed for WWW browsers).
   * Changed registration key to work with user/company name
     instead  of IP number. Every time Serv-U is started  it
     tries  to  read the key from a file KEY.TXT. Registered
     version  displays  the key in the "About"  box  and  in
     reply to the FTP HELP command.
   * Changed  the  RETR and STOR replies (used for  GET  and
     PUT).  They  are now conform the average  UNIX  system.
     This  makes  WS_FTP more happy, so it shows a  progress
     bar while downloading.

Version 1.00:
   * Initial release 7 February 1995
   
1.6 A Word to the Wise (but paranoid)

Many  a word has been spent on the alt.winsock newsgroup  in
recent  weeks on the try-out enforcement practice of Serv-U,
and  in a broader sense on the security of network programs.
If  you  choose  for the 'fully functional try-out  version'
then this program will communicate with a remote system  (my
PC  in fact) to determine if it should be allowed to run  or
not. That is the way the 30 days of try-out are enforced. To
that  effect, information is exchanged between your  PC  and
mine, and as people remarked: How do I know that my password
file  is  not being sent over? Another, but similar question
is:  How  can  I  be sure there are no 'back doors'  in  the
server, allowing access to the author at any time? The short
and  hard  answer is: You don't know and you  can  never  be
sure!

I know this is not much of a deal, so I'll at least give you
one option to establish my good intentions. To anyone who is
interested,  I offer to personally go over the  source  code
with  him/her (all 11000+ lines of it) and we'll compile  it
on the spot. You will understand that I am not going to hand
out  any  source  code. If you want to take  it  home  you'd
better bring along a whole lot of $$$'s!

It  is worthwhile to realize that security is a problem with
any  type  of  network  program. It is  fairly  easy  for  a
programmer  to put code in, for example, a WWW browser  that
will  wait for 5 months, until full moon and Venus coincide,
then  monitors PC activity and if a user hasn't been present
for  a  few  hours, or if it's 4 in the morning, will  start
sending  over  the whole hard disk to unknown  destinations.
This  kind of thing is not easy to detect, don't let  anyone
tell  you  otherwise, and I still have to  meet  the  system
manager that keeps a network monitor running 24 hours a day,
year after year and actually reads the log files. The bottom
line  is that you will have to trust the author of a program
at some point, there is no other choice!


2. THE GRAND TOUR - MENUS
=========================

The menus and associated dialog boxes have been designed  to
be  as simple as I could make them while still providing the
needed  features  and flexibility. The next paragraphs  take
you  on a grand tour through all of them. I highly recommend
you to take a closer look at the part about setting up users
and  security  under  'Setup  - Users/Groups'.  The  default
settings  have been chosen to be both secure and reasonable.
Make sure you know what they are about before changing them.

2.1 The File Menu

The 'Logging' option can be checked to enable logging of FTP
events  to  a file. If unchecked, logging will be to  screen
only.  This option is only available if a logfile  has  been
specified under the 'Setup - Logging' menu choice.  Changing
logging  through the 'File - Logging' menu will only  affect
the  current session. The changes are not saved and the next
time you start Serv-U logging will again be as specified  in
'Setup  -  Logging'. This can be convenient if, for example,
you  want  to temporarily switch logging on/off for  testing
purposes.

The other option is 'Exit', guess what that does . . .

2.2 The Edit Menu

You'll  find only two options here: 'Copy' and 'Clear'.  The
first one copies selected text from the Serv-U logscreen  to
the clipboard and 'Clear' wipes the logscreen  clean.

2.3 The Setup Menu

This  is  where the fun starts. Almost everything concerning
the  functioning  of Serv-U can be set through  the  'Setup'
menu.  There  are two exceptions: First, if  you  insist  on
allowing access for a user without a password, and,  second,
if you want to make the Serv-U program invisible; meaning it
will  not show up in the list of the task manager.  In  both
cases you'll have to edit the SERV-U.INI file directly.  For
more  information on how to do this, take  a  look  at   the
'Internals' chapter.

The  dialog  boxes where you can fill in your settings  have
not  been made totally bullet proof. It is entirely possible
to  enter  nonsense in certain items and  the  program  will
accept  it  (like  path names that don't  exist,  etc.).  Of
course,  things  might not work exactly as you're  expecting
them  to, but it should not cause the program to crash.  The
bottom  line  is that it is your responsibility  to  provide
settings that make sense.

Now,  let's  continue  with  the 'Setup'  menu  choices  and
associated dialog boxes.

The 'Setup - FTP-Server' option
This  menu  choice will lead you to a dialog box  containing
matters  directly related to the workings of the FTP  server
itself.
The  first  item  is 'FTP port number'.  This  is  the  (you
guessed it!) port number that the server will listen on  for
incoming  FTP clients. The default is number 21, but  you're
free  to  fill in anything you want, provided  it  does  not
conflict with other network programs. Of course, the rest of
the  world  expects a FTP server to listen on port  21,  but
changing to another number is one great way of insuring that
only  you  and  some selected friends will know  about  your
server. One fun choice is to set this to port number 23  and
then use a telnet program  to 'telnet' to your own PC.

The  next  item is the 'Maximum number of users'. With  this
you  set  the  maximum number of simultaneous users  at  any
given  moment.  Setting it to 0 will  not  allow  anyone  to
enter, leaving it blank will allow an unlimited number,  or,
more precisely, until the PC runs out of network sockets. If
you  need  your PC for regular work as well as being  a  FTP
server,  it  is  probably wise to set a  maximum  so  normal
operations  will  not be slowed down too  much  by  clients.
Likewise, 'Maximum number of anonymous' limits the number of
'Anonymous' users at any given moment. If 'Maximum number of
users'  is specified, then this will limit the total  number
of  users,  both  regular and anonymous,  even  if  'Maximum
number of anonymous' is set to a larger number.

Some people have asked what would be reasonable settings for
the maximum number of users that would still keep the system
workable. The answer is: It depends. It depends very much on
whether these users are local and thus capable of using up a
large bandwidth in data transfer, or alternatively, if these
users  are  further  away  on the Internet  and  cannot  get
transfer  speeds  of more than about 10 Kbytes  per  second.
Another  concern  is the socket stack. Some  WinSock  stacks
start  behaving erratically when they have to service  large
numbers of sockets. Most notoriously is the Microsoft 32-bit
stack, which has the tendency to kick the system back to MS-
DOS  without  any warning when heavily loaded.  For  my  own
server I have set the limit to 10 simultaneous users.  Since
I  mostly  get  relatively slow long distance  traffic  this
means in practice that I have never noticed any slowdown  in
system response while using it for other work and the server
has  remained stable. If you use a dedicated  PC  as  a  FTP
server  it  is  probably safe to go to about 20 simultaneous
users.

To   make  sure that users cannot log onto your  server  and
keep  connections open until eternity it is possible to  set
'Time-out  users' and 'Time-out anonymous'. If a  connection
has  been  idle  for  more than the number  of  minutes  you
specify here it will be automatically closed. Filling  in  0
or  leaving it blank switches off the time-out. It is a good
idea to fill in some values here, since otherwise the system
would  slowly fill up with sockets that for some reason  got
stuck,  not  to  mention  users that  connect  and  start  a
transfer  just before they leave the office in  the  evening
and  then  go  home.  Default  values  are  15  minutes  for
anonymous  users  and  10 hours (=600 minutes)  for  regular
users.

If you would like to leave your PC wide open for the rest of
the  world  you can uncheck the 'Enable security'  checkbox.
But  beware:  DISABLING SECURITY WILL ALLOW ANYBODY  ON  THE
NETWORK  TO DELETE/CHANGE/COPY EVERYTHING ON YOUR PC!!!  The
only  reason  I put this option in is to make  it  easy  for
people  that have their own local network and don't want  to
mess with users and passwords. By default this option is, of
course, checked. DO NOT EVER LEAVE THIS OPTION UNCHECKED  IF
YOUR PC IS CONNECTED TO THE INTERNET!!!

The   last  item  is  the  'Relative  paths  for  anonymous'
checkbox. By default this is checked and it causes anonymous
users  to  see  all directories and path names  relative  to
their  home  directory.  So, if your  anonymous  users  have
'\USERS\ANONFTP' as their home directory, they will  receive
back  '\' when they inquire with the PWD command. Similarly,
every reference they make to a file or a change of directory
is  taken  relative to this path. The main reason it  is  in
there  is because WWW browsers need read access to  the  '/'
(=root)  directory to make them work. This way they  believe
they  have access to the root and are happy, while on  a  PC
you don't always want to give users access to your real root
directory. The disadvantage of having this mechanism is that
anonymous  users are restricted to their home directory  and
below,  nor  do they have access to other drives.  Sometimes
you  want  them  to be able to do this and  unchecking  this
option will allow that. Anonymous users will then be treated
like  any other user as far as path names are concerned  and
they  will  be  able to change to parallel paths  and  other
drives if their access rights permit this.

The 'Setup - IP-Access' option
This  dialog  box provides the means to restrict  access  to
your FTP server to certain IP-numbers. If  for example,  you
work  at a university and only want your faculty members  to
be able to access the server, then this is a great way to do
it.  In  the  upper left corner of the dialog  box  you  can
choose  which type of rules you want to specify:  'Deny'  or
'Allow' rules. The deny rules decide who should be kept out,
the  allow rules indicate who should be welcomed. THE  ORDER
OF  THE  RULES  IS  IMPORTANT! When a  client  contacts  the
server, the deny rules are looked at FROM TOP TO BOTTOM.  If
no  matching  rule is found, the allow rules are  evaluated,
again  from top to bottom. The first matching rule  applies,
and  evaluation is stopped. If there are no IP-access  rules
everybody can enter the FTP server. As soon as there is  one
rule,  only  those  clients that pass  the  rule  check  are
allowed to enter.

You  can type in a new rule in the 'Rule' edit and then  use
the  'Add' button to add the rule to the list. The  'Remove'
button  will  remove the currently selected  rule  from  the
list.  To  change the order of the rules you have to  select
one  by clicking the mouse on it, and then use the 'Up'  and
'Down' buttons to move it around.

Rules  are  nothing more than IP-numbers or  ranges  of  IP-
numbers. There are two special characters: the star '*'  and
the  hyphen '-'. A star functions as a wildcard for checking
the  number. Any number will match that section of the  rule
if  it  is  a star. The hyphen is used to denote a range  of
numbers. Simply separate the starting and ending values by a
hyphen. For example, say all IP-numbers in your company look
like  134.56.34.xxx with 'xxx' being any  number.  Now,  you
want  to restrict access to your FTP server to other members
of  your  company  only. The way to do it is  to  create  an
'Allow' rule that looks like this:

     134.56.34.*

That's  simple, isn't it!? Likewise, if you  know  that  the
competition has IP-numbers in the range 168.76.xxx.xxx,  you
can keep them out of your server with the 'Deny' rule:

     168.76.*.*

Now,  you  need  to  share some of your  files  with  a  few
colleagues, and management in your company is too  cheap  to
install  a local network. You find out that their PC's  have
IP-numbers  134.56.34.128, 134.56.34.129 and  134.56.34.130.
You  could of course make three 'Allow' rules, each with one
of  these  numbers. A faster way to do this  is  to  make  a
single rule like this:

     134.56.34.128-130

The  special characters '*' and '-' don't need to be at  the
end of the IP-numbers, any place will do. The rule 221.*.76-
154.89  is  perfectly OK. I wouldn't know  when  you'd  need
this,  but,  hey,  the world is a strange  place!  Remember,
order  is  important  and deny rules  are  always  evaluated
before the allow rules. Experiment a bit, and you'll get the
hang of it.

The 'Logging' option
This dialog box lets you specify what events you want to log
and  where to log them to: either to screen only or to  both
the screen and a logfile. If you are interested in the exact
format of the logfile, it is described in detail further  on
in this manual.

The  first  two  items deal with logging to a  logfile.  The
first  one, 'Enable logging to file' switches writing  to  a
logfile  on or off. The second item, 'Logfile' is meant  for
entering the path and file name of a file to write  all  the
log  messages to. Of course, logging will only work  when  a
valid logfile name is entered, it has to be a full path name
including a drive letter. Log messages will always be  shown
on screen, regardless of these settings.

The next items are a list of events for which logging can be
enabled  or disabled. The items are self descriptive  except
maybe  for  the  last  two. 'Log FTP  commands'  logs  every
command  as  it  is  received by the  server  and  'Log  FTP
replies' logs the command replies that are sent back by  the
server  to the client. These two options are mainly intended
for diagnostic purposes and are switched off by default. The
default value of the other options is 'on'.

The 'Setup - Signon/Signoff' option
Your  FTP-server can display a welcome message every time  a
user  connects  to  it. This can be very useful  to  provide
users with information about your FTP server, like where  to
find  games, or 'Serious Software'. Likewise, you might want
to  say good-bye to them when they leave, or remind them  to
send  that  check . . . The way to do this is by entering  a
text in the 'Signon/Signoff' dialog box.

There  are  a few special characters that you can  enter  in
your signon/signoff text which get expanded while being sent
to a client. These are:

     %t   - displays the current time on your PC
     %d   - displays the current date on your PC
     %u   - displays the current number of  Serv-U  users
            logged in

So, you could use the following signon text:

     Welcome, it is %t on %d, and you are user number %u

I'm  sure you'll figure out by yourself what this will  look
like  to  the user . . . If you have ideas for other  useful
special characters, let me know about it!

The 'Setup - Users' option
Unless you switched off all security, you are going to  have
to  set up users. And, you guessed it, this is the place  to
do so!

Upon  choosing this option a dialog box is presented to you.
It  contains  a  list  of all known  users.  To  change  the
settings  for  a certain user, just click on  the  name  and
click 'Edit' (or just double-click on the name). Now, if you
just started this server for the first time there will be no
names,  short  of Divine Intervention. Never mind,  just  go
ahead  and click 'Edit'. You'll be presented with  an  empty
dialog  box  containing  entries for everything  you  always
wanted to set for a user.

The  next thing is important, so pay attention: You can fill
in or change any name in the 'User name' field. If this name
does  not  exist it will be added to the list of  users.  If
this name exists, the settings for this user will be changed
to  the ones in the dialog box. So, if you double-clicked on
user  'James'  and  then  go  on  to  set  his  password  to
'lightbulb' and you change the user name to another of  your
users, 'Tanya', then Tanya is going to be mighty upset  when
she  tries  to enter your FTP server! James will  of  course
have to remember his old password, since nothing changed for
him.  This  way  of dealing with users might strike  you  as
somewhat  strange. The advantage of it is that you can  take
an  existing user and, by making only the few needed changes
turn it into a new user.

Now  let's take a closer look at the various fields  in  the
'Edit  User'  dialog box. I've dealt with  the  'User  name'
field, so this brings us to 'Group name'. Every user can  be
part  of a group. The convenience in making users part of  a
group is that you can leave common settings for all users of
a particular group blank and just fill them out in the 'Edit
Group'  dialog  box.  This goes for all settings,  including
password, home directory and path access rules. To  overrule
a certain group setting, simply provide one for the user.

For  example,  you're the Pentagon system administrator  and
want to create FTP access for everybody in case they are  on
field trips. So, you hook up this old PC to the net, install
Serv-U  and register it (hypothetical situation).  Then  you
proceed to create a group 'StarWars'. Now you go on  to  set
the  password  for  this group, 'RonaldR',  and  their  home
directory    (all   their   files   are   shared    anyway),
'y:\super\secret\starwars'. You fill  in  some  access  path
rules  as well, and you're all set: The only thing  left  is
entering the user names, you don't have to provide any other
information per user. A 10 minute job.
Now  there's this occasional guest user, 'BillyC'. You don't
want him to get into certain directories, so you make him  a
member  of  the group but specify those directories  in  his
access path rules with 'no access', and you're all done.

We  did  get  ahead  of ourselves in the discussion  of  the
various  fields,  so  let me back up a bit.  The  'Password'
field  shows stars ('*****') when entering a password. Don't
worry, this is only to protect you from prying eyes. Also if
you're  editing an existing user who has a password, nothing
will be shown here, but the password is still there. To keep
the existing password for a user: don't edit this field! The
passwords  are  stored encrypted using  UNIX  'crypt'.  This
algorithm works like a sausage machine: you put in a pig  on
one  side  and  turn the crank, out comes the sausage.  But,
pushing  in  the  sausage while turning the crank  backwards
will  not get you a pig! It is quite secure, I wouldn't know
of  a way to get the plain text password back (the NSA might
though).

The  'Home directory' field is for the user's home directory
(to kick in an open door). This is the place where he or she
is  put immediately after logging in. Each user needs a home
directory,  without one the server will not  permit  logging
in.  Of course, if a user is part of a group, and this group
has a home directory you don't have to specify one here. You
might  want to, if this user needs a different one from  the
rest  of the group. Home directories always need to be  full
path names, including a drive letter!

This  brings  us  to the last part of this dialog  box,  the
'File/Directory  access' rule list.  This  list  contains  a
number  of  paths  with access information coupled  to  each
path.  Access to the PC is only allowed according  to  these
paths  and  their  access information. No access  paths,  no
access! So, there is one path you might always want to be in
the list: The user's home directory.

When  a  user  executes a FTP command  concerning  files  or
directories, the user's path list is checked to see  if  the
command  should be allowed to proceed. The list is evaluated
FROM TOP TO BOTTOM! SO THE ORDER OF THE PATH ACCESS RULES IS
IMPORTANT!!!

There  are  five different types of access information  that
can be set for each path:
     * 'Read'  access, this allows files to be  copied  from
       the PC using the FTP 'get' command.
     * 'Write' access, allowing files to be copied to the PC
       using 'put', but not changed, deleted, or renamed.
     * 'Delete' access, allowing the user to  change  files,
       rename,   or  delete  them.  Having  'Delete'  access
       automatically includes write access.

The last two items deal with directories:
     * 'Create' access lets the user create  new directories
       at this path.
     * 'Delete' lets the user delete directories.

To  get  a  directory  listing any one of  these  rights  is
sufficient  for  a  path. If none of the  rights  have  been
granted for a certain path, then the user has no access what-
so-ever to this path.

The rights of a certain path are valid not only for the path
itself, but also for all subdirectories of it. If you  don't
want  this to happen for a certain subdirectory you have  to
specify  this directory with the desired rights  before  its
parent in the list of paths.

Since  one  example can say more than a thousand  words,  or
something  along  that line, let's work  through  a  typical
situation. Assume you want to setup an 'Anonymous' FTP site.
This  needs a directory tree with all the goodies the  users
might  want, for which they need read access. You also  need
an  upload directory where users can upload new goodies, but
you  don't  want others to be able to immediately get  their
fingers  on  it, since you want to check for viruses  first.
So, this directory needs write but no read access. We decide
to  put everything on the big network drive, 'Y:', under the
'ANONFTP'  directory. We also create the 'UPLOAD'  directory
here  for  uploads.  In  Serv-U we  would  create  the  user
'Anonymous'  with the following access path  rules  (and  in
this order):

     Y:\ANONFTP\UPLOAD   - write rights
     Y:\ANONFTP          - read rights

Reversing the rules will not work: If a user would write  to
the  upload  directory  the security  mechanism  will  check
against   Y:\ANONFTP  and  conclude   that   UPLOAD   is   a
subdirectory, so the rule applies, and the rule grants  only
read access. Please take note that write access still allows
a  user  to get a directory listing of the UPLOAD directory,
but he won't be able to download anything from there.

If  the  drive letter is left out of a path, it applies  for
all  drives. So, a fast way to get full access to all  files
on all drives is:

      \                  - read, write, delete, create dir
                           and delete dir rights

Now,   the   same  mechanism  that  determines   access   to
directories also applies to files. It is possible  to  grant
access to specific files on a per-file basis. Lets take  the
previous example about the anonymous FTP server. We want  to
put a file 'SECRET' in the ANONFTP directory, but nobody  is
allowed  to  read  it of course. So, our access  paths  list
would look like this:

     Y:\ANONFTP\SECRET   - no rights
     Y:\ANONFTP\UPLOAD   - write rights
     Y:\ANONFTP          - read rights

Again,  the  order of the paths is important! The  directory
access   rights   do  not  have  any  meaning   for   files.
Alternatively, if SECRET was a directory instead of a  file,
the  above  settings would keep users out of this directory.
In  fact,  they  would not even be able to get  a  directory
listing.

Serv-U  also  allows  access to all PC ports:  PRN:,  LPT1:,
LPT2:,  LPT3:, LPT4:, AUX:, COM1:, COM2:, COM3:, and  COM4:.
This  can  be  a  convenient way of setting up  a  'network'
printer  by  transferring files directly to PRN: using  FTP.
These  ports are treated like any regular path name, a  user
needs  access rights to use them. So, to make a  printer  on
PRN:  accessible  and a modem on COM2: the  user  needs  the
following rights:

     PRN:                - write and delete rights
     COM2:               - read,  write  and  delete
                           rights

The  buttons  speak for themselves, so I'll  not  waste  any
bytes on them.

There  are two special user names, although in setting  them
up  they are dealt with exactly the same as any other  user.
These  are  the user names 'Anonymous' and 'ALL'.  (Actually
there  are three special names: User name 'FTP' is taken  to
be synonymous to 'Anonymous'.)

We  already came across 'Anonymous', it allows users to  log
in  without a password. The FTP server asks for their E-mail
address instead and logs this. The 'Password' section in the
'Setup  Users' dialog box is ignored for this user name.  If
an  anonymous  user logs in, he will normally  not  see  the
whole  file structure. To him everything will appear  to  be
relative  to  the home directory. So, to abuse our  previous
example yet another time: After logging in he will be put in
Y:\ANONFTP, but if he asks for the current path  the  server
will answer '\'. All actions concerning files will, also, be
relative  to  his home directory. The reason for  making  it
this  way  is that certain World Wide Web browsers that  log
into   an  anonymous  FTP  server  will  execute  a  'change
directory'  to '\' immediately thereafter. They  get  mighty
confused  if  this  is  refused, so  by  making  their  home
directory appear to be '\' this is avoided.

The  other  special user name is 'ALL'. Now where does  this
tie  in?  Well,  every action requiring  security  clearance
(checking  a password during login, reading, writing,  etc.)
is  first  checked against the settings for  the  particular
user. If no appropriate setting is found there, and the user
belongs  to  some group, the group settings are checked.  If
still  no corresponding setting is found, the user 'ALL'  is
consulted  (if it exists). So 'ALL' works as a  blanket  for
all  users,  providing the most common settings. Of  course,
this  also provides a potentially big security hole,  so  be
careful!

The 'Setup - Groups'  option
Choosing this presents you with exactly the same dialog  box
as  the 'Setup - Users' section. The only difference is that
you  cannot fill in a user name. Everything works  the  same
way  too,  so I'll let you figure it out. Of course,  you're
not dealing with users here but with group names.

2.4 The Help Menu

This  menu choice is still a bit underdeveloped, it has only
the  'About' item. This does however present you with a very
beautiful 'about' box, thus more than making up for the lack
in  other  areas. This is also the place where you will  see
your name or that of your company appear once the program is
registered.

2.5 The Logfile and Screen

Although  they are strictly speaking not part of the  menus,
this  is  a  convenient place to discuss the format  of  the
logfile and screen messages.

Messages  are always logged to the Serv-U window, regardless
of  the logfile settings. There is no difference between the
messages  on  screen and the ones in the  logfile,  although
some  things are only shown on screen. The latter are server
and  program  related matters, like version  number,  server
going on/off-line etc.

Log  messages  always have the same layout. The  reason  for
using  such a strict format is to make it easier  to  search
for  specific  messages or certain types of  messages.  This
also makes it possible to do automatic accounting by machine
reading the logfile if you need it. The logfile can be  read
or copied at any moment (It is also possible to get the file
via  FTP using Serv-U itself!), even when Serv-U is running.
The format is as shown below, in stylized form:

     [n] DATE TIME - (xxxx) MESSAGE

The first number, 'n', indicates the type of message that is
being logged. Currently there are six different categories:

     1    - system messages (problems etc.)
     2    - FTP commands (from client to server)
     3    - GET file transfers
     4    - PUT file transfers
     5    - security related events (users logging in etc.)
     6    - FTP replies (from server to client)

The  second  number, 'xxxx', is a unique ID  assigned  to  a
client  the  moment  the connection  is  made.  All  further
messages  concerning that client will use the  same  number.
Again,  this  was  done  to make it  easy  to  do  automated
accounting,  or,  to  find back events  using  the  'search'
facilities of every editor.


3. THE INNER WORKINGS
=====================

Before  I  go on to describe the settings of the  SERV-U.INI
file  I want to spend a few words describing how Serv-U  was
made and how it goes about its job.

3.1 Serv-U Internals

The  program was written using Borland C++ version  3.1.  To
check  for shaky pointers and catch all those resource leaks
the  program  Bounds Checker version 2.1  from  Nu-Mega  was
used.  I  think  no  serious Windows  programmer  should  be
without the latter, very recommended!
This  whole  project  started about a year  ago  after  much
disappointment with the existing FTP servers for WinSock. In
its  current version it consists of just a little over 11000
lines  of  C++ code, divided into 16 C++ classes. The  whole
program was constructed from scratch, not using any existing
FTP server code, and is tailored to MS-Windows and WinSock.

Internally, everything is very much compartmentalized, using
a  different class for different partial tasks. There  is  a
WinSock   class  library,  providing  hi-level   access   to
WinSockets  and hiding all the nasty parts of  dealing  with
them.  It  uses  100% asynchronous WinSock  functions  (also
called 'non-blocking' functions) thus avoiding problems with
multiple active sockets for a single task and re-entry  (let
me  know  if  you're interested in this class  library,  I'm
thinking  of selling it in source code format). There  is  a
FTP-manager class, taking care of listening for clients, and
setting  up  instances of the FTP-command interpreter  class
when this happens. The latter does the actual interpretation
of  the  FTP  commands, talking to the  security  class  for
clearance  and  the  WinSock class for communications.  Then
there are some utility-like classes, like those dealing with
setup  and  logging. By having all these  compartments  that
handle  very well defined tasks, I hope to be able to easily
extend  this  FTP  server  and  fix  those  (hopefully  few)
remaining bugs quickly!

3.2 The SERV-U.INI File

All  the  settings  for the server, users,  and  groups  are
stored  in a single file in text format. This file is always
named  SERV-U.INI. When the program is started it looks  for
this  file  in  a  number  of different  places:  First,  an
environment  variable SERV-U is checked.  If  this  variable
exists  it  should  be set to the path where  SERV-U.INI  is
found. Next, if this variable does not exist, the whole  DOS
path  is  scanned,  including the Windows  directories.  The
first  SERV-U.INI file found on the way is used. This  makes
it easy to set things up for network users where there is  a
single  copy  of  the program but each user  needs  its  own
settings. If after this no .INI file has been found yet  the
directory  of  the Serv-U program is searched. If SERV-U.INI
is  found  here  it will be used, if not, the  program  will
create one, in the program directory.

We'll  now  go over all the items that can appear  in  SERV-
U.INI. I will show you an invented setup file:

     [GLOBAL]
     Security=TRUE
     PortNr=23
     MaxNrUsers=15
     MaxNrAnonymous=10
     Invisible=TRUE
     Logfile=c:\serv-u\logfile.txt
     Logging=YES
     TimeoutUser=600
     TimeoutAnonymous=15
     TryOut=Crippled
     LogGETs=ON
     LogPUTs=ON
     LogSystemMes=ON
     LogSecurityMes=ON
     LogFTPCommands=OFF
     LogFTPReplies=OFF
     RegistrationKey=S%FgdfsdEvG,Rob Beckers,Cat Soft
     AnonRelPaths=YES
     Window=100,100,400,300
     
     [SIGNONOFF]
     SignOn1="Welcome to Robby's FTP-Server!"
     SignOn2="It is %t local time on %d and you are user nr.
     %u"
     SignOff1="Thanks for logging in!"
     SignOff2="Hope to see you again soon . . ."
     
     [IP-ACCESS]
     Bounce1=132.68.175.201
     Bounce2=223.*.*.*
     Allow1=132.68.176.53
     Allow2=132.68.175.*
     Allow3=101.43.23.30-40
     
     [USER=Anonymous]
     HomeDir=d:\anonftp
     Access1=d:\anonftp\upload,W
     Access2=d:\anonftp,R
     
     [USER=Rob]
     Group=system
     Password=WdRx.Jlk0kemm%
     HomeDir=c:\
     Access1=\,RWMCD
     Access2=lpt1:,WM
     Access3=prn:,WM
     Access4=aux:,WM
     Access5=lpt2:,WM
     Access6=lpt3:,WM
     Access7=lpt4:,WM
     Access8=com1:,RWM
     Access9=com2:,RWM
     
     [USER=ALL]
     HomeDir=y:\
     Access1=y:\,R
     
     [GROUP=SYSTEM]
     Access1=c:\system,RWDCM
     Access2=d:\,RWDCM
     Access3=y:\novell,RWD
     
All  but  three  of these settings can be  changed  and  set
interactively through the 'Setup' menus. The exceptions  are
the   entries   for   'Invisible',  'RegistrationKey',   and
'Window',  and  if  you  desire a user  to  really  have  no
password  the  entry 'Password=' has to be set manually  for
that user.
The  following  paragraphs will describe  each  section  and
entry in more detail.

[GLOBAL]
All  the settings related to the Serv-U program itself, i.e.
the  functioning of the FTP server and system functions, are
found in the '[Global]' section.

If security should not be enforced, the 'Security' entry can
be  set  to  FALSE or 0. Doing so will leave the FTP  server
wide  open  to everybody!!! Default value for 'Security'  is
TRUE.

The  'PortNr' entry determines the IP port that  the  server
will listen on. Default value is 21.

To  limit  the  maximum  number of  simultaneous  users  the
'MaxNrUsers' entry should be set to the desired  number.  No
entry  or a negative number results in no maximum, only  the
number  of available sockets will limit the number of  users
in  that case. Similarly, the 'MaxNrAnonymous' entry  limits
the  maximum number of 'Anonymous' users. The value put here
is  only  meaningful  if  it is smaller  than  that  of  the
'MaxNrUsers' entry.

For  system  managers that don't want their  users  to  mess
around with the server settings, it is possible to make Serv-
U  invisible by setting the 'Invisible' entry to TRUE, 1  or
YES  and put the Serv-U program in the 'startup' group. When
this is done the server will not show up in the task manager
list.  One consequence is that there is no way to  stop  the
program  short of exiting Windows. Default is  NO  for  this
entry.

The  'LogFile' entry should specify a full path and name for
a  logfile  if  logging  is desired.  There  is  no  default
logfile. To actually switch logging on and off the 'Logging'
entry  can  be set to ON or TRUE, or OFF or FALSE. Switching
logging  ON  will  only work if a logfile is  specified.  By
default 'Logging' is set to ON.

The  entries 'TimeOutUser' and 'TimeOutAnonymous' specify  a
time-out  in  minutes  for respectively  regular  users  and
anonymous  users. If a FTP connection is left idle  for  the
indicated amount of time it is automatically closed. Filling
in  0  results in no time-out. Default values are 15 minutes
for anonymous and 10 hours for regular users.

The next one deals with the way the program can be tried out
(when  there  is  no  registration code).  'TryOut'  can  be
'Crippled'  or  'Full'. The first allows  a  user  to  do  a
maximum 5 GETs and 5 PUTs per session, puts the server  off-
line  after  1  hour,  and notifies clients  that  they  are
looking at an unregistered try-out version. However, it does
not  contact  my permission server. The 'Full' option  gives
you  no  limitations while trying the program, it is exactly
equal  to  the registered version. The downside is  that  it
does  access  my permission server to ask for permission  to
run each time Serv-U is started. This is how the 30 days  of
try-out are enforced.

All  the 'LogXXXX' entries switch logging options on or off.
Their names say it all, so I'll let you figure them out.

The   'RegistrationKey'  entry  is  used  for  entering  the
registration code. You get this code after registration.  By
default it has no value and for evaluation of the program it
should be left blank or out of the .INI file.

'AnonRelPath'  determines  if  anonymous  users  should   be
treated   with  all  path  names  relative  to  their   home
directory. This is desirable for use with WWW browsers  that
insist  on  having  access  to  the  root  directory  ('/').
Switching  this on limits anonymous users to the subtree  of
their home directory, they cannot switch to other drives. If
you  switch it off then anonymous users will be treated like
all others. Default it is switched on.

The  last entry is 'Window' and this is set by Serv-U  every
time  the  program is stopped. It contains the last position
and   size   of   the   program  window,   in   the   format
'top,left,width,height'

[SIGNONOFF]
This  section contains the messages that are displayed after
a   user  contacts  the  FTP  server  and  just  before   he
disconnects. Every line has a separate entry with  a  number
at the end, denoting the order. The signon message is put in
'SignOnxx'  entries  (with  xx the  line  number),  and  the
signoff message is put in 'SignOffxx'.

There are three special character combinations recognized by
Serv-U  and they are expanded to their actual values when  a
user logs on or off. These are:

     %t   = current time
     %d   = current date
     %u   = current number of users that are logged in

A  tip:  Keep  the  number of lines  and  the  their  length
limited.  Most  FTP  clients will  mess  up  lines  over  80
characters,  and  since a FTP reply code is  tagged  to  the
beginning of these lines before they are sent, it is wise to
keep them to less then 75 characters.

[IP-ACCESS]
This  section  determines which client  IP-numbers  will  be
allowed  access  to Serv-U. There are two  kinds  of  rules:
Those  that  refuse access in the form of 'Bounce'  entries,
and  those that grant access using 'Allow' entries. If  this
section  doesn't  exist, or no entries are found,  then  all
clients  are allowed to contact the server. The  reverse  is
also  true,  if  there is even a single entry  ('Bounce'  or
'Allow') then only those clients will be allowed to  contact
the  server  that  pass the rule. All entries  are  numbered
('Allow1',  'Allow2' etc.) and they are evaluated  according
to  their  number  from  first to last.  Numbers  should  be
consecutive.  The  'Bounce' rules are evaluated  before  the
'Allow' rules.

The IP-number of the client is matched section by section to
each  rule until a match is found. If the matching  rule  is
one of the 'Bounce' ones, the client is disconnected. If the
IP  number matches an 'Allow' rule then he can proceed.  The
rules   can   be   exact  IP-numbers,  or  contain   special
characters. There are two of those:

     *    = wildcard, match any number
     -    = denotes a range

A  quick example: The rule '132.*.76.48-89' will allow entry
to  clients with an IP-address starting with 132, the second
section can be anything (0..255), the third must be  76  and
the  last  section  should  be between  48  and  89  (limits
included).

[USER='Name']
The  information  about a user is stored  in  this  section,
'Name'  stands for the user's name. Each user has a separate
section.  It  contains information needed to authenticate  a
user  during login, and rules determining what this user  is
allowed to access. The Serv-U program will first check  this
section for a regular user. If no applicable information  is
found  and  the user is a member of a group,  the  group  is
addressed for the same information. If the result of this is
still undetermined, the special user name 'ALL' is searched.

Now  to  the entries that can be found in this section.  The
identity  of  a user is verified by comparing his  password,
after encryption, with the one in the 'Password' entry.  The
UNIX 'crypt()' command is used to encode the passwords. This
makes it possible to extract users with their password  from
the  PASSWD file of a UNIX system, the same passwords should
work  on both systems. Unfortunately, there is not a  single
standard for password encryption on UNIX systems these days.
Serv-U uses the most common scheme, but this might not  work
for your system.

If  the password matches, the home directory of the user  is
taken from the 'HomeDir' entry. This should always be a full
path name, including drive letter!

To  make  a  user a member of a certain group,  the  'Group'
entry  can be used. All information needed and not found  in
the  user's  section; password, home dir and  file/directory
access, are then  looked for in the group's section.

Information about file and directory access for  a  user  is
stored  in  the 'Access' entries. Each of these is numbered,
and  access information is checked in order: first comparing
it  to  the  first rule, then the second, etc. The numbering
must  be consecutive. Access rules start with a path or file
name.  These  paths are usually full names, including  drive
letter.  If the drive letter is missing, they apply  to  all
drives. Also, access rules apply not only to the exact path,
but to all subdirectories as well. If different settings are
needed  for a subdirectory, than a rule with that  directory
should  appear before its parent, i.e. with a lesser number.
The  path in an access rule is followed by a comma  and  the
access information itself. This can be a combination  of  up
to five different characters:

     R    = read access to files
     W    = write access to files
     M    = modify access to files (implies write access)
     C    = right to create subdirectories
     D    = right to delete subdirectories

It is entirely possible to have no access information at all
(only  a  path). This means that the user will not have  any
access to that path. For a user to be able to list the files
in  a  directory he needs at least one of these five rights,
any  will do. Another thing to realize is that write  access
to  a file does not imply read access! As you can see it  is
also possible to specify access rights for the parallel  and
serial  ports. They are part of the regular security  scheme
and  to  transfer  to  or from a port a  user  needs  access
rights.  Then finally, the path in an access rule  does  not
have to point to a directory. It is also possible to specify
a  filename. Of course, the 'C' and 'D' rights will not have
any meaning then.

There are two special user names: 'Anonymous' and 'ALL'.  If
there  is  an user 'Anonymous', it will be possible  to  log
into the server without a password. Instead, Serv-U will ask
for  the  user's E-mail address and log this.  Most  of  the
regular  entries  apply  for  'Anonymous'  as  well,  except
'Password'  and  'Group', these are ignored.  In  fact,  for
anonymous users the sections for groups and 'ALL' are  never
searched.

The  user 'ALL' is searched if no appropriate rule is  found
in  a user's or his group's entry. It can contain any of the
regular entries.

[GROUP='Name']
These sections contain the group info. The entries here  are
exactly  the  same  as  those for a user,  except  that  the
'Group' entry has no meaning of course.


4. GETTING IN TOUCH - BUGS & REGISTRATION
=========================================

I'd  love to hear from you! Not only for bugs, but  also  if
you  have  ideas, questions, or remarks. Please  drop  me  a
line! The fastest and easiest way to do so is by E-mail.  My
address is:

     RJB@eel-mail.mc.Duke.edu

Regular  mail  should work as well, but  might  take  a  bit
longer. My address for this is:

     Rob Beckers
     1911 Erwin Road, Apt. I
     Durham, NC 27705
     U.S.A.


4.1 Reporting Bugs

Nothing  in  this world is perfect, least of all  me!  Alas,
chances are that despite careful testing you'll still find a
bug.  Please don't think others will report it, let me know!
There  are  a few things I need to know in order to  improve
chances of fixing the beasty, so take note of the following:

   * Most  important: Can you get the same bug to appear  by
     repeating  certain actions! Please try hard, without  a
     recipe  for repeating a bug it's going to be very  hard
     to track it down.
   * What TCP/IP and WinSock stack are you using? Brand/type
     and  version number please. Also, what operating system
     (DOS  version  and  Windows  or  Windows-For-Workgroups
     version  x.xx)?  Any memory manager (QEMM  etc.),  what
     version?
   * Please indicate also if this bug is merely cosmetic  or
     of  vital  importance  for using Serv-U.  Somewhere  in
     between  is possible as well of course. By the  way,  I
     consider security related bugs very important!
   * Finally,  please give me a chance to fix a bug,  before
     you  start to shout all over the Internet how bad  this
     program is . . .
     

4.2 Registering Serv-U

If  you're happy with the performance of Serv-U, then please
make  me  happy and register this program! Just a few  words
for  those  who  are in doubt: Making this program  took  me
(very  literally) months of work, spread out over  the  last
year.  Your  registration fee is going  to  motivate  me  to
continue  improving  Serv-U.  In  general,  registration  is
important  for shareware programs: It makes it possible  for
you  to  use  professional  quality  software  for  peanuts.
Lastly, being a biomedical engineering graduate student, I'm
not  exactly  making lots of $$'s (to put  it  mildly).  So,
those 20 bucks for registration mean a lot to me!

To  register,  please fill out the registration  form  below
(There  is  a  separate  one in ASCII  format  in  the  file
REGISTER.TXT.)  and  send  it  to  me.  Payment  should   in
principle  be included with the registration form,  although
there   are   exceptions  possible  for  foreign   (non-USA)
customers, to which I'll get in a moment. If you are  inside
the  US a personal check will do fine. The registration  fee
is  $20  for each copy. If you want to make me even  happier
and need several copies, the following license prices apply:

     The FTP Serv-U license prices:
     
     1-9  $20 each
     
     License for:
     20   $200
     50   $400
     100  $600
     100+ $500 per block of 100 users
     
     Licenses for more than 500 users are negotiable.
     
     Educational discount: For licenses of 50 or more users:
     30% discount.
     
Payment  from outside the USA is a problem. Despite all  the
international networks the easy solutions are costly and the
cheap  solutions risky. The exceptions are if you are inside
the  Netherlands, then payment is easy (see further on),  or
if you're in a European country and can use Euro-checks, see
below  for details. For non-US customers the following forms
of payment are accepted, in order of preference:

     * By Euro-Cheque, for Europeans only. The check must be
       made out in NLG (=NederLandse Guldens), and the price
       per copy  is NLG 35. Please don't forget to sign  the
       check both on the front and the back and to  fill  in
       the  4 digit  security number on the  back.  Make  it
       payable to R. Beckers - Bunde. Mail the check to: Rob
       Beckers;  St.  Agnesstraat  16;  6241CB  Bunde;   The
       Netherlands.  Please mail the filled out registration
       form to the US address mentioned on the form.
     * By check, drawn at an American bank. The check should
       be  made  out  to  Rob Beckers (Alas,  Cat  Soft only
       exists in the mind for now).
     * By American Express Travelers Checks for the  correct
       amount  in  US dollars. These are cheap and safe, but
       there  might be a minimum commission charged  by your
       bank.  The  checks should be made out to  Rob Beckers
       and don't forget to sign them twice!
     * By  Postal Money Order.  As I understand it, you  can
       buy   these   international  money  orders   in  most
       countries for very little money ($3 here in  the US).
       Payment  is in your own currency, but the money order
       should be made out for USD $20 and to Rob Beckers.
     * By  cash,  but  only  in US dollars  and  I  give  no
       guaranties about safe arrival! Please DO NOT  send me
       other currencies, it would probably cost me much more
       to  convert them to $$'s than it costs you. A trick I
       found  useful for sending cash in envelopes:  put the
       money  in a folded sheet of paper so it doesn't shine
       through   the  envelope.  This  improves  chances  of
       arrival considerably.
     
For  companies buying a site license there are a  number  of
less  cheap  but  more secure options,  again  in  order  of
preference:

     * By direct money transfer in US dollars to my American
       bank account. This costs you $35 extra, since that is
       the  atrocious  rate  my bank charges  me  to receive
       money  this  way. If you are interested,  ask  me for
       details.
     * By  sending me a (foreign) check from your own  bank.
       The  check  should be made out in USD and  payable to
       Rob  Beckers. Using this option costs you  $18  extra,
       which is how much my bank charges me for cashing such
       a check.
     * By  direct money transfer to my  Dutch bank  account.
       Only $9 extra for this one, which is what they charge
       in  the  Netherlands.  Ask me for  details if  you're
       interested.

Now for the Dutch:
Daar  ik nog steeds een Nederlandse girorekening heb is  het
mogelijk op die wijze te betalen. De prijs bedraagt f. 35,--
per  kopie.  Dit dient overgemaakt te worden op girorekening
53.95.461 ten name van Rob Beckers, te Bunde. Vermeld s.v.p.
"Registratie  Serv-U" zodat duidelijk  is  waarvoor  betaald
wordt. A.u.b. geen geld vanuit het buitenland overmaken! Van
die   35   piek   zou  dan  heel  weinig  overblijven.   Het
registratieformulier gewoon naar de VS sturen  (post  of  E-
mail).

Next, what do you get if you register? As soon as I get your
registration  I'll  send  you  a  registration   code   plus
instructions  on  how to add it to the  program.  This  will
enable you to use the program, even after the 30 day try-out
period.  Please let me know your E-mail address,  so  I  can
notify  you fast. In case I have your E-mail address  you'll
also  get  notified when there are updates. Once  registered
you'll get those updates for free. That is, you can use  the
same  registration code on the updates, but you'll  have  to
get  them yourself. Apart from all this you'll also get  the
nice,  warm  feeling of having contributed to  improving  my
financial status!

The  registration code is tied to the user/company name  you
specify on the registration form. You can see if your server
is  registered  by  looking  at the  'About'  dialogbox:  If
registered it will tell you to whom. Another thing  to  keep
in mind is that the registration information is sent back to
any  FTP client who uses the FTP command 'HELP'. This is not
a  much  used command but in principle it allows  the  whole
world  to  find  out who paid for your copy  of  Serv-U.  If
you're  the lawful owner of the server this shouldn't bother
you, if not...

The next page is the registration form. Please use this form
for all registrations! That way I can keep my administration
manageable.

------------------------------------------------------------

ROB BECKERS
1911 Erwin Road, Apt I
Durham, NC 27705
U.S.A.

                              
                              
                  REGISTRATION FORM SERV-U
                  ========================
                              


           Name: ...........................................

   Company Name: ...........................................

        Address: ...........................................





   Phone Number: ...........................................

 E-Mail Address: ...........................................
                          (Internet only please)

Additional comments, suggestions, complaints, praise, etc:

............................................................

............................................................

............................................................


Registration fee is $20 per copy. Send this order form along
with  your  payment to: Rob Beckers, 1911 Erwin Road Apt. I,
Durham NC 27705, USA.

If   you  have any questions, comments or suggestions please
contact  Rob Beckers at the above address or via  e-mail  to
RJB@eel-mail.mc.duke.edu. Check out the site license  prices
if you need multiple copies.

As  this software is shareware it comes 'as is', there is no
warranty  implied  or  otherwise, nor is  support  provided.
However, if you discover any bugs or problems please contact
the developer at the above e-mail address.

