ftpaccess(5)                                         ftpaccess(5)

Name
       ftpaccess - ftpd configuration file

Description
       The  ftpaccess  file is used to configure the operation of
       ftpd(8).

Access Capabilities
       autogroup <groupname> <class> [<class> ...]

            If an ANONYMOUS user is a member of any  of  <class>,
            the  ftp  server  will perform a setegid() to <group-
            name>.  This allows access  to  group-and-owner-read-
            only  files  and directories to a particular class of
            anonymous users. <groupname> is a  valid  group  from
            /etc/group  (or  wherever  mechanism your getgrent(2)
            library routine uses).

       class <class> <typelist> <addrglob> [<addrglob> ...]

            Define <class> of users, with source addresses of the
            form  <addrglob>.  Multiple members of <class> may be
            defined.  There  may  be  multiple  "class"  commands
            listing additional members of the class.  If multiple
            "class" commands can apply to  the  current  session,
            the  first  one  listed  in  the access file is used.
            Failing to define a valid class for a host will cause
            access to be denied.  <typelist> is a comma-separated
            list of any of the keywords "anonymous", "guest"  and
            "real".  If the "real" keyword is included, the class
            can match users using FTP to  access  real  accounts,
            and  if the "anonymous" keyword is included the class
            can match users using  anonymous  FTP.   The  "guest"
            keyword  matches  guest  access accounts (see "guest-
            group" for more information)

            <addrglob> may be a globbed domain name or a  globbed
            numeric  address.  It may also be the name of a file,
            starting with a slash  ('/'),  which  contains  addi-
            tional   address  globs,  as  well  as  in  the  form
            address:netmask or address/cidr.

            Placing  an  exclamation  (!)  before  an  <addrglob>
            negates the test.  For example:
                class rmtuser real !*.example.com
            will classify real users from outside the example.com
            domain as the class  rmtuser.   Use  care  with  this
            option.   Remember,  the result of each test is OR'ed
            with other tests on the line.

       deny <addrglob> <message_file>

            Always deny access to  host(s)  matching  <addrglob>.
            <message_file>   is  displayed.   <addrglob>  may  be
            "!nameserved" to deny access to sites without a work-
            ing  nameserver.   It may also be the name of a file,
            starting with a slash  ('/'),  which  contains  addi-
            tional   address  globs,  as  well  as  in  the  form
            address:netmask or address/cidr.

       guestgroup <groupname> [<groupname> ...]

       guestuser <username> [<username> ...]

       realgroup <groupname> [<groupname> ...]

       realuser <username> [<username> ...]

            For guestgroup, if a REAL user is a member of any  of
            <groupname>,  the  session  is set up exactly as with
            anonymous FTP.  In other words, a chroot()  is  done,
            and the user is no longer permitted to issue the USER
            and PASS commands.  <groupname> is a valid group from
            /etc/group  (or  whatever  mechanism your getgrent(3)
            library routine uses).

            The user's home directory must be  properly  set  up,
            exactly  as  anonymous FTP would be.  The home direc-
            tory field of the passwd entry is  divided  into  two
            directories.   The  first field is the root directory
            which will be the argument  to  the  chroot(2)  call.
            The second half is the user's home directory relative
            to the root directory.  The two halves are  separated
            by a "/./".

            For example, in /etc/passwd, the real entry:
                guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
            When guest1 successfully logs in, the ftp server will
            chroot("/ftp")  and  then  chdir("/incoming").    The
            guest  user will only be able to access the directory
            structure under /ftp (which will look and act as / to
            guest1), just as an anonymous FTP user would.

            The  group  name  may  be specified by either name or
            numeric ID.  To use a numeric group ID, place  a  '%'
            before  the  number.   Ranges  may  be given.  Use an
            asterisk to mean all groups.

            guestuser works like guestgroup, except uses the user
            name (or numeric ID).

            realuser  and  realgroup  have  the  same syntax, but
            reverse the effect of guestuser and guestgroup.  They
            allow  real  user  access  when the remote user would
            otherwise be determined a guest.

            For example:
                guestuser *
                realgroup admin
            causes all  non-anonymous  users  to  be  treated  as
            guest,  with the sole exception of users in the admin
            group who are granted real user access.

       nice <nice-delta> [<class>]

            Adjust the process nice value of the ftpd server pro-
            cess  by  the  indicated  <nice-delta>  value  if the
            remote user is a member of  the  named  <class>.   If
            <class>  is  not  specified, then use <nice-delta> as
            the default adjustment to  the  ftpd  server  process
            nice  value.   This  default nice value adjustment is
            used to adjust the nice value of the  server  process
            only  for  those users who do not belong to any class
            for which a class-specific `nice' directive exists in
            the ftpaccess file.

       defumask <umask> [<class>]

            Set  the  umask applied to files created by daemon if
            the remote use is a member of the  named  class.   If
            <class>  is  not specified, then use the umask as the
            default for classes which do not have one  specified.

       tcpwindow <size> [<class>]

            Set  the  TCP  window  size  for the data connection.
            This can be used to  control  network  traffic.   For
            instance,  slow PPP dialin links may need smaller TCP
            windows to speed up throughput.  If  you  don't  know
            what this does, don't play with it.

       keepalive <yes|no>

            Set  the  TCP  SO_KEEPALIVE  option for data sockets.
            This can be used to control network disconnect.  Yes:
            set  it.   No: use system default (usually off).  You
            probably want to set this.

       timeout accept <seconds>

       timeout connect <seconds>

       timeout data <seconds>

       timeout idle <seconds>

       timeout maxidle <seconds>

       timeout RFC931 <seconds>

            Set various timeouts.

            Accept (default 120 seconds):  how  long  the  daemon
            will wait for an incoming (PASV) data connection.

            Connect  (default  120  seconds): how long the daemon
            will wait attempting to establish an outgoing  (PORT)
            data  connection.   This effects the actual connetion
            attempt.  The daemon makes several attempts, sleeping
            a while between each, before completely giving up.

            Data (default 1200 seconds): how long the daemon will
            wait for some activity on the data  connection.   You
            should  keep  this long because the remote client may
            have a slow link and there can be quite a bit of data
            queued for the client.

            Idle  (default 900 seconds): how long the daemon will
            wait for the next command.  The default can  also  be
            overridden  by  the  command  line  -a  option.  This
            access clause overrides both.

            MaxIdle (default 1200 seconds): the SITE IDLE command
            allows  the remote client to establish a higher value
            for the idle timeout.  This sets the upper limit  the
            client may request.  The default can also be overrid-
            den by the  command  line  -A  option.   This  access
            clause overrides both.

            RFC931  (default  10  seconds):  the maximum time the
            daemon allows for the entire RFC931 (AUTH/ident) con-
            versation.   Setting this to zero (0) completely dis-
            ables the daemon's use of this protocol.  The  infor-
            mation  obtained via RFC931 is recorded in the system
            logs and not actually used in any authentication.

       file-limit [<raw>] <in|out|total> <count> [<class>]

            Limit the number of data files a user  in  the  given
            class may transfer.  The limit may be placed on files
            in, out or total.  If  no  class  is  specified,  the
            limit  is the default for classes which do not have a
            limit specified.  The optional raw parameter  applies
            the  limit to the total traffic rather than just data
            files.

       byte-limit [<raw>] <in|out|total> <count> [<class>]

            Limit the number of data bytes a user  in  the  given
            class  may transfer.  The limit may be place on bytes
            in, out or total.  If  no  class  is  specified,  the
            limit  is the default for classes which do not have a
            limit specified.  Note that this limit will  prevent-
            transfers  once  it  has  been exceeded, but will not
            terminate a transfer in progress.  The  optional  raw
            parameter  applies  the limit to total traffic rather
            than just data files.

       limit-time {*|anonymous|guest} <minutes>

            Limit the total time a session can take.  By default,
            there is no limit.  Real users are never limited.

       guestserver [<hostname>]

            Controls  which  hosts  may  be used for anonymous or
            guest access.  If used without <hostname>, denies all
            guest  or  anonymous  access to this site.  More than
            one <hostname> may be specified.  Guest and anonymous
            access  will  only  be allowed on the named machines.
            If access is denied, the user will be  asked  to  use
            the first <hostname> listed.

       limit <class> <n> <times> <message_file>

            Limit <class> to <n> users at times <times>, display-
            ing <message_file> if  the  user  is  denied  access.
            Limit check is performed at login time only.  If mul-
            tiple "limit" commands can apply to the current  ses-
            sion,  the  first applicable one is used.  Failing to
            define a valid limit, or a limit of -1, is equivalent
            to  unlimited. <times> is in same format as the times
            in the UUCP L.sys file.

       noretrieve [absolute|relative] [class=<classname>] ... [-]
            <file- name> <filename> ...

            Always deny retrieve-ability of these files.  If  the
            files  are a path specification (i.e. begins with '/'
            character) then only those files are  marked  un-get-
            table, otherwise all files with matching the filename
            are refused transfer.  For example:
                noretrieve /etc/passwd core
            specifies no  one  will  be  able  to  get  the  file
            /etc/passwd  whereas they will be allowed to transfer
            a file `passwd' if it is not in /etc.  On  the  other
            hand  no  one  will be able to get files named `core'
            wherever they are.

            Directory specifications  mark  all  files  and  sub-
            directories  in the named directory un-gettable.  The
            <filename> may be specified  as  a  file  glob.   For
            example:
                noretrieve /etc /home/*/.htaccess
            specified no files in /etc or any of its sub-directo-
            ries may be retrieved.  Also, no files named  '.htac-
            cess'  anywhere  under  the  /home  directory  may be
            retrieved.

            The optional first parameter  selects  whether  names
            are intepreted as absolute or relative to the current
            chroot'd environment.  The  default  is  to  intepret
            names beginning with a slash as absolute.

            The  noretrieve  restrictions may be placed upon mem-
            bers of particular classes.  If any class= is  speci-
            fied  the named files are only non-retrievable if the
            current user is a member of any of the given classes.

       allow-retrieve   [absolute|relative]
            [class=<classname>]...  [-] <filename> ...

            Allows  retrieval  of  files which would otherwise be
            denied by noretrieve.

       loginfails <number>

            After <number> login failures, log a "repeated  login
            failures"  message  and terminate the FTP connection.
            Default value is 5.

       private <yes|no>

            After user logs in, the SITE  GROUP  and  SITE  GPASS
            commands  may  be  used to specify an enhanced access
            group and associated password.  If the group name and
            password  are valid, the user becomes (via setegid())
            a member of the group specified in the  group  access
            file /etc/ftpgroups.

            The format of the group access file is:
                access_group_name:encrypted_password:real_group_name
            where access_group_name is an arbitrary (alphanumeric
            + punctuation)  string.   encrypted_password  is  the
            password  encrypted  via  crypt(3),  exactly  like in
            /etc/passwd.  real_group_name is the name of a  valid
            group listed in /etc/group.

            NOTE:  For  this  option  to  work  for anonymous FTP
            users, the ftp server  must  keep  /etc/group  perma-
            nently  open and the group access file is loaded into
            memory.  This means that (1) the ftp server  now  has
            an  additional file descriptor open, and (2) the nec-
            essary passwords and  access  privileges  granted  to
            users  via SITE GROUP will be static for the duration
            of an FTP session.  If you have  an  urgent  need  to
            change  the access groups and/or passwords *NOW*, you
            just kill all of the running FTP servers.

Informational Capabilities
       greeting full|brief|terse

       greeting text <message>

            Allows you to control how much information  is  given
            out  before the remote user logs in.  'greeting full'
            is the default and shows the hostname and daemon ver-
            sion.   'greeting  brief'  whose  shows the hostname.
            'greeting terse'  simply  says  "FTP  server  ready."
            Although full is the default, brief is recommended.

            The  'text'  form  allows you to specify any greeting
            message you desire.  <message>  can  be  any  string;
            whitespace (spaces and tabs) is converted to a single
            space.

       banner <path>

            Works similarly to the message command,  except  that
            the  banner  is  displayed before the user enters the
            username/password.  The <path>  is  relative  to  the
            real  system  root, not the base of the anonymous FTP
            directory.

            WARNING: use of this command can  completely  prevent
            non-compliant  FTP clients from making use of the FTP
            server.   Not  all  clients  can  handle   multi-line
            responses (which is how the banner is displayed).

       hostname <some.host.name>

            Defines  the  default  host  name  of the ftp server.
            This string will be printed on the  greeting  message
            and every time the %L magic cookie is used.  The host
            name for virtual servers overrides  this  value.   If
            not  specified,  the  default host name for the local
            machine is used.

       email <name>

            Defines the email address of the  ftp  archive  main-
            tainer.   This  string will be printed every time the
            %E magic cookie is used.

       message <path> {<when> {<class> ...}}

            Define a file with <path> such that ftpd will display
            the  contents  of  the file to the user login time or
            upon using the change working directory command.  The
            <when>  parameter  may be "LOGIN" or "CWD=<dir>".  If
            <when>  is  "CWD=<dir>",  <dir>  specifies  the   new
            default  directory  which  will trigger the notifica-
            tion.

            The optional <class> specification allows the message
            to  be  displayed  only  to  members  of a particular
            class.  More than one class may be specified.

            There can be "magic cookies" in the readme file which
            cause  the  ftp  server  to replace the cookie with a
            specified text string:
                %T      local time (form Thu Nov 15 17:12:42 1990)
                %F      free space in partition of CWD (kbytes)
                          [not supported on all systems]
                %C      current working directory
                %E      the maintainer's email address as defined in ftpaccess
                %R      remote host name
                %L      local host name
                %u      username as determined via RFC931 authentication
                %U      username given at login time
                %M      maximum allowed number of users in this class
                %N      current number of users in this class
                %B      absolute limit on disk blocks allocated
                %b      preferred limit on disk blocks
                %Q      current block count
                %I      maximum number of allocated inodes (+1)
                %i      preferred inode limit
                %q      current number of allocated inodes
                %H      time limit for excessive disk use
                %h      time limit for excessive files

            The message will only  be  displayed  once  to  avoid
            annoying  the  user.  Remember that when MESSAGEs are
            triggered by an anonymous FTP user, the  <path>  must
            be  relative  to the base of the anonymous FTP direc-
            tory tree.

       readme <path> {<when> {<class>}}

            Define a file with <path> such that ftpd will  notify
            user  at  login time or upon using the change working
            directory command that the file exists and was  modi-
            fied on such-and-such date.  The <when> parameter may
            be "LOGIN" or "CWD=<dir>".  If <when> is "CWD=<dir>",
            <dir>  specifies the new default directory which will
            trigger the notification.  The message will  only  be
            displayed  once,  to avoid bothering users.  Remember
            that when README messages are triggered by an  anony-
            mous  FTP  user,  the  <path> must be relative to the
            base of the anonymous FTP directory tree.

            The optional <class> specification allows the message
            to  be  displayed  only  to  members  of a particular
            class.  More than one class may be specified.

Logging Capabilities
       log commands <typelist>

            Enables logging  of  individual  commands  by  users.
            <typelist>  is  a  comma-separated list of any of the
            keywords "anonymous", "guest"  and  "real".   If  the
            "real"  keyword is included, logging will be done for
            users using FTP to access real accounts, and  if  the
            "anonymous" keyword is included logging will done for
            users  using  anonymous  FTP.   The  "guest"  keyword
            matches  guest  access accounts (see "guestgroup" for
            more information).

       log transfers <typelist> <directions>

            Enables logging of file transfers for either real  or
            anonymous  FTP  users.   Logging  of transfers TO the
            server (incoming)  can  be  enabled  separately  from
            transfers  FROM the server (outbound).  <typelist> is
            a comma-separated list of any of the keywords "anony-
            mous",  "guest" and "real".  If the "real" keyword is
            included, logging will be done for users using FTP to
            access  real accounts, and if the "anonymous" keyword
            is included logging will done for users using  anony-
            mous  FTP.  The  "guest" keyword matches guest access
            accounts (see  "guestgroup"  for  more  information).
            <directions>  is a comma-separated list of any of the
            two  keywords  "inbound"  and  "outbound",  and  will
            respectively  cause  transfers to be logged for files
            sent to the server and sent from the server.

       log security <typelist>

            Enables  logging  of  violations  of  security  rules
            (noretrieve,  .notar,  ...)   for  real, guest and/or
            anonymous users.   <typelist>  is  a  comma-separated
            list  of any of the keywords "anonymous", "guest" and
            "real".  If the "real" keyword is  included,  logging
            will  be  done  for  users  using  FTP to access real
            accounts, and if the "anonymous" keyword is  included
            logging  will done for users using anonymous FTP. The
            "guest" keyword matches guest  access  accounts  (see
            "guestgroup" for more information).

       log syslog

       log syslog+xferlog

            Redirects  the logging messages for incoming and out-
            going transfers to syslog.  Without this  option  the
            messages are written to xferlog.

            syslog+xferlog  sends  the  transfer  log messages to
            both the system log and the xferlog.

Miscellaneous Capabilities
       alias <string> <dir>

            Defines an alias, <string>, for a directory.  Can  be
            used to add the concept of logical directories.

            For example:
                alias rfc: /pub/doc/rfc
            would  allow the user to access /pub/doc/rfc from any
            directory by the command  "cd  rfc:".   Aliases  only
            apply to the cd command.

       cdpath <dir>

            Defines an entry in the cdpath. This defines a search
            path that is used when changing directories.

            For example:
                cdpath /pub/packages
                cdpath /.aliases
            would  allow  the  user  to  cd  into  any  directory
            directly  under  /pub/packages  or /.aliases directo-
            ries. The search path is defined  by  the  order  the
            lines appear in the ftpaccess file.

            If the user were to give the command:
                cd foo
            the  directory  will be searched for in the following
            order:
                ./foo
                an alias called "foo"
                /pub/packages/foo
                /.aliases/foo

            The cd path is only available with the cd command. If
            you  have a large number of aliases you might want to
            set up an aliases directory with links to all of  the
            areas you wish to make available to users.

       compress <yes|no> <classglob> [<classglob> ...]

       tar <yes|no> <classglob> [<classglob> ...]

            Enables  compress  or  tar capabilities for any class
            matching any of <classglob>.  The actual  conversions
            are  defined  in  the external file FTPLIB/ftpconver-
            sions.

       shutdown <path>

            If the file pointed to by <path> exists,  the  server
            will check the file regularly to see if the server is
            going to be shut down.  If a shutdown is planned, the
            user  is notified, new connections are denied after a
            specified time before shutdown  and  current  connec-
            tions  are  dropped  at a specified time before shut-
            down.  <path> points to a file structured as follows:
                <year> <month> <day> <hour> <minute> <deny_offset> <disc_offset>
                <text>
            where
                <year> is any year > 1970
                <month> 0-11 <---- LOOK!
                <hour> 0-23
                <minute> 0-59

            <deny_offset>  and  <disc_offset>  are the offsets in
            HHMM format before the shutdown time that new connec-
            tions will be denied and existing connections will be
            disconnected.

            <text> follows the normal rules for any message  (see
            "message"), with the following additional magic cook-
            ies available:
                %s      time system is going to shut down
                %r      time new connections will be denied
                %d      time current connections will be dropped
            all times are in the form: ddd MMM DD hh:mm:ss  YYYY.
            There  can be only one "shutdown" command in the con-
            figuration file.

            The external program ftpshut(8) can be used to  auto-
            mate the process of generating this file.

       daemonaddress <address>

            If  the value is not set, then the server will listen
            for connections on every IP addresses,  otherwise  it
            will only listen on the IP address specified.

            Use  of  this clause is discouraged.  It was added to
            support a single site's needs.   It  will  completely
            break  virtual  hosting  and  the syntax is likely to
            change in a future version of the daemon.

       virtual <address> <root|banner|logfile> <path>

            Enables the  virtual  ftp  server  capabilities.  The
            <address>  is  the  ip address of the virtual server.
            The second argument  specifies  that  the  <path>  is
            either  the  path  to  the root of the filesystem for
            this virtual server, the banner presented to the user
            when  connecting  to this virtual server, or the log-
            file where transfers are recorded  for  this  virtual
            server.  If  the logfile is not specified the default
            logfile will be used.  All other  message  files  and
            permissions  as  well  as  any other settings in this
            file apply to all virtual servers.

            NOTE: Your operating system may not support this fea-
            ture.  It  has been tested on BSD/OS, Solaris 2.X and
            Linux.

            The <address> may also be specified as  the  hostname
            rather than the IP number.  This is strongly discour-
            aged since, if DNS is not available at the  time  the
            FTP session begins, the hostname will not be matched.

       virtual <address> <hostname|email> <string>

            Sets the hostname shown in the greeting  message  and
            STATus  command, or the email address used in message
            files and on the HELP command, to the given <string>.

       virtual <address> allow <username> [<username> ...]

       virtual <address> deny <username> [<username> ...]

            Normally, real and guest users are not allowed to log
            in on the vitual server unless they  are  guests  and
            chroot'd  to  the  virtual root.  The users listed on
            the virtual allow line(s)  will  be  granted  access.
            All  users can be granted access by giving '*' as the
            username.  The virtual  deny  clauses  are  processed
            after  the virtual allow clauses and are used to deny
            access to specific users when all users were allowed.

       virtual <address> private

            Normally,  anonymous  users  are allowed to log in on
            the virtual server.  This option denies them  access.

       defaultserver deny <username> [<username> ...]

       defaultserver allow <username> [<username> ...]

            Normally, all users are allowed access to the default
            (non-virtual) FTP server.  Use defaultserver deny  to
            revoke access for specific users; specify '*' to deny
            access to all users.   Specific  users  can  then  be
            allowed using defaultserver allow.

       defaultserver private

            Normally,  anonymous users are allowed on the default
            (non-virtual) FTP server.  This  statement  disallows
            anonymous access.

            The virtual and defaultserver allow, deny and private
            clauses provide a means to control  which  users  are
            allowed access on which FTP servers.

       passive address <externalip> <cidr>

            Allows control of the address reported in response to
            a PASV command.  When any control connection matching
            the <cidr> requests a passive data connection (PASV),
            the <externalip> address  is  reported.   NOTE:  this
            does not change the address the daemone actually lis-
            tens on, only the address  reported  to  the  client.
            This  feature  allows the daemon to operate correctly
            behind IP-renumbering firewalls.

            For example:
                passive address 10.0.1.15   10.0.0.0/8
                passive address 192.168.1.5 0.0.0.0/0
            Clients connecting from the class-A network  10  will
            be  told  the  passive connection is listening on IP-
            address 10.0.1.15 while all others will be  told  the
            connection is listening on 192.168.1.5

            Multiple passive addresses may be specified to handle
            complex, or multi-gatewayed, networks.

       passive ports <cidr> <min> <max>

            Allows control of the TCP port numbers which  may  be
            used  for  a passive data connection.  If the control
            connection matches the <cidr> a  port  in  the  range
            <min> to <max> will be randomly selected for the dae-
            mon to listen on.  This feature allows  firewalls  to
            limit  the ports which remote clients may use to con-
            nect into the protected network.

            <cidr> is shorthand for an IP address in  dotted-quad
            notation  followed by a slash and the number of left-
            most bits which represent  the  network  address  (as
            opposed  to  the  machine  address).  For example, if
            you're using the reserved class-A network 10, instead
            of  a  netmask  of  255.0.0.0  use a CIDR of /8 as in
            10.0.0.0/8 to represent your network.

       pasv-allow <class> [<addrglob> ...]

       port-allow <class> [<addrglob> ...]

            Normally, the daemon does not allow a PORT command to
            specify an address different than that of the control
            connection.  And it does not allow a PASV  connection
            from another address.

            The  port-allow  clause  provides a list of addresses
            which the specified class of user may give on a  PORT
            command.   These  addresses  will  be allowed even if
            they do not match the IP-address of  the  client-side
            of the control connection.

            The  pasv-allow  clause  provides a list of addresses
            which the specified class of user may make data  con-
            nections  from.  These addresses will be allowed even
            if they do not match the IP-address  of  the  client-
            side of the control connection.

       lslong <command> [<options> ...]

       lsshort <command> [<options> ...]

       lsplain <command> [<options> ...]

            The  lslong, lsshort and lsplain clauses allow speci-
            fication of the command and options used to  generate
            directory  listings.  Note the options cannot contain
            spaces and the defaults for these clauses are  gener-
            ally  correct; use lslong, lsshort or lsplain only if
            absolutely necessary.

       mailserver <hostname>

            Specify the name of a mail server which  will  accept
            upload  notifications  for  the FTP daemon.  Multiple
            mail servers may be listed; the daemon  will  attempt
            to deliver the upload notification to each, in order,
            until one accepts the message.  If  no  mail  servers
            are  specified,  localhost  is  used.  This option is
            only meaningful if anyone is to be notified of anony-
            mous uploads (see incmail).

       incmail <emailaddress>

       virtual <address> incmail <emailaddress>

       defaultserver incmail <emailaddress>

            Specify  email  addresses to be notified of anonymous
            uploads.  Mutltiple addresses can be specified;  each
            will  receive a notification.  If none are specified,
            no notifications are sent.

            If addresses are specified for a virtual  host,  only
            those  addresses  will receive notification up anony-
            mous uploads on that host.  Otherwise,  notifications
            will be sent to the global addresses.

            Defaultserver  addresses only apply when the FTP ses-
            sion is not using one of the virtual hosts.  In  this
            way,  you  can receive notifications for your default
            anonymous area, but not see notifications to  virtual
            hosts which do not have their own notifications.

       mailfrom <emailaddress>

       virtual <address> mailfrom <emailaddress>

       defaultserver mailfrom <emailaddress>

            Specify  the  sender's  email  address  for anonymous
            upload notifications.  One one address may be  speci-
            fied.  If no mailfrom applies, email is sent from the
            default mailbox name 'wu-ftpd'.  To avoid problems if
            the recipient attempts to reply to a notification, or
            if downstream mail  problems  generate  bounces,  you
            should ensure the mailfrom address is deliverable.

Permission Capabilities
       chmod <yes|no> <typelist>

       delete <yes|no> <typelist>

       overwrite <yes|no> <typelist>

       rename <yes|no> <typelist>

       umask <yes|no> <typelist>

            Allows or disallows the ability to perform the speci-
            fied function.  By default, all users are allowed.

            <typelist> is a comma-separated list of  any  of  the
            keywords  "anonymous",  "guest", "real" and "class=".
            When "class=" appears,  it  must  be  followed  by  a
            classname.   If  any  class=  appears, the <typelist>
            restriction applies only to users in that class.

       passwd-check <none|trivial|rfc822> (<enforce|warn>)

            Define the level and enforcement of password checking
            done by the server for anonymous ftp.
                none      no password checking performed.
                trivial   password must contain an '@'.
                rfc822    password must be an rfc822 compliant address.

                warn      warn the user, but allow them to log in.
                enforce   warn the user, and then log them out.

       deny-email <case-insensitive-email-address>

            Consider  the  e-mail address given as an argument as
            invalid. If passwd-check is set to enforce, anonymous
            users  giving this address as password cannot log in.
            That way, you can stop users from having  stupid  WWW
            browsers   use   fake  addresses  like  IE?0User@  or
            mozilla@. (by using this, you are  not  shutting  out
            users  using  a  WWW  browser for ftp - you just make
            them configure their  browser  correctly.)  Only  one
            address per line, but you can have as many deny-email
            addresses as you like.

       path-filter <typelist> <mesg> <allowed_charset>
            {<disallowed reg- exp> ...}

            For users in <typelist>, path-filter defines  regular
            expressions  that  control what a filename can or can
            not be.  There may be  multiple  disallowed  regexps.
            If  a filename is invalid due to failure to match the
            regexp criteria, <mesg>  will  be  displayed  to  the
            user.  For example:
                path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9._]*$ ^\. ^-
            specifies  that  all  upload  filenames for anonymous
            users must be made of only the characters  A-Z,  a-z,
            0-9,  and  "._-"  and  may not begin with a "."  or a
            "-".  If the filename is invalid,  /etc/pathmsg  will
            be displayed to the user.

       upload  [absolute|relative] [class=<classname>]... [-]
            <root-dir>      <dirglob>  <yes|no>  <owner>  <group>
            <mode>   ["dirs"|"nodirs"] [<d_mode>]

            Define  a  directory  with  <dirglob> that permits or
            denies uploads.

            If it does permit uploads, all  newly  created  files
            will  be  owned  by <owner> and <group> and will have
            their permissions set according to  <mode>,  existing
            files  which are overwritten will keep their original
            ownership and permissions.

            Directories are matched on a best-match basis.

            For example:
                upload /var/ftp *              no
                upload /var/ftp /incoming      yes ftp daemon 0666
                upload /var/ftp /incoming/gifs yes jlc guest  0600 nodirs
            would only allow uploads into /incoming  and  /incom-
            ing/gifs.   Files  that  were  uploaded  to /incoming
            would be owned by ftp/daemon and would  have  permis-
            sions of 0666.  File uploaded to /incoming/gifs would
            be owned by jlc/guest and have permissions  of  0600.
            Note  that  the  <root-dir>  here must match the home
            directory specified in the password database for  the
            "ftp" user.

            The  optional  "dirs"  and  "nodirs"  keywords can be
            specified to allow or disallow the  creation  of  new
            subdirectories using the mkdir command.

            Note  that  if  the upload command is used, directory
            creation is allowed by default. To  turn  it  off  by
            default, you must specify a user, group and mode fol-
            lowed by the "nodirs" keyword as the first line where
            the upload command is used in this file.

            If  directories  are permitted, the optional <d_mode>
            determines the permissions for a newly created direc-
            tory.   If  <d_mode>  is omitted, the permissions are
            inferred from <mode> or are 0777 if  <mode>  is  also
            omitted.

            The  upload  keyword only applies to users who have a
            home directory (the argument to  the  chroot()  )  of
            <root-dir>.   <root-dir>  may  be specified as "*" to
            match any home directory.

            The <owner> and/or <group> may each be  specified  as
            "*",  in which case any uploaded files or directories
            will be created with the ownership of  the  directory
            in which they are created.

            The  optional  first parameter selects whether <root-
            dir> names are intepreted as absolute or relative  to
            the  current chroot'd environment.  The default is to
            intepret <root-dir> names as absolute.

            You can specify  any  number  of  'class=<classname>'
            restrictions.   If  any  are  specified,  this upload
            clause only takes effect if the  current  user  is  a
            member of one of the classes.

            Please read the upload.configuration.HOWTO for a com-
            plete discussion of how to configure your  server  to
            allow uploading files.

       throughput  <root-dir> <subdir-glob> <file-glob-list>
            <bytes-per-       second> <bytes-per-second-multiply>
            <remote-glob-list>

            Define files via comma-seperated <file-glob-list>  in
            subdir matched by <subdir-glob> under <root-dir> that
            have restricted transfer  throughput  of  <bytes-per-
            second>  on  download  when  the  remote  hostname or
            remote  IP  address   matches   the   comma-seperated
            <remote-glob-list>.

            Entries are matched on a best-match basis.

            For example:
                throughput /e/ftp *    *      oo   -   *
                throughput /e/ftp /sw* *      1024 0.5 *
                throughput /e/ftp /sw* README oo   -   *
                throughput /e/ftp /sw* *      oo   -   *.foo.com
            would   set   maximum  throughput  per  default,  but
            restrict download to 1024 bytes/s for any files under
            /e/ftp/sw/  which  are  not  named  README.  The only
            exceptions are remote hosts from  within  the  domain
            foo.com  which  always get maximum throughput.  Every
            time a remote  client  has  retrieved  a  file  under
            /e/ftp/sw/ the bytes per seconds of the matched entry
            line are internally multiplied by a factor, here 0.5.
            So  when  the remote client retrieves its second file
            it is served with 512 bytes/s, the  third  time  with
            only  254  bytes/s,  the  fourth  time  with only 128
            bytes/s and so on.

            The string "oo" for the bytes per second field  means
            no  throughput restriction.  A multiply factor of 1.0
            or "-" means no change of the throughput after  every
            successful transfer.

            Note  that  the  <root-dir>  here must match the home
            directory specified in the password database for  the
            "ftp"  user.   The throughput keyword only applies to
            users who have a home directory (the argument to  the
            chroot() ) of <root-dir>.

       anonymous-root <root-dir> [<class>]

            <root-dir>  specifies the chroot() path for anonymous
            users.  If no  anonymous-root  is  matched,  the  old
            method  of  parsing  the home directory for the 'ftp'
            user is used.  If no <class> is  specified,  this  is
            the root directory for anonymous users who do not any
            other anonymous-root specification.  Multiple classes
            may  be  given  on the line.  If an anonymous-root is
            chosen for the user, the 'ftp' user's home  directory
            in  the  <root-dir>/etc/passwd file is used to deter-
            mine the initial directory and the 'ftp' user's  home
            directory in the system-wide /etc/passwd is not used.

            For example:
                anonymous-root /home/ftp
                anonymous-root /home/localftp localnet
            causes all anonymous users to be  chroot()'d  to  the
            directory /home/ftp then, if the 'ftp' user exists in
            /home/ftp/etc/passwd, their initial CWD is that  home
            directory.   Anonymous  users  in the class localnet,
            however,   are   chroot()'d    to    the    directory
            /home/localftp  and  their  initial CWD is taken from
            the    'ftp'     user's     home     directory     in
            /home/localftp/etc/passwd.

       guest-root <root-dir> [<uid-range>]

            <root-dir>  specified  the  chroot()  path  for guest
            users.  If no  guest-root  is  is  matched,  the  old
            method  of parsing the user's home directory is used.
            If no <uid-range> is  specified,  this  is  the  root
            directory  for guest users who do not match any other
            guest-root specification.  Multiple uid ranges may be
            given on the line.  If a guest-root is chosen for the
            user,  the  user's  home  directory  in  the   <root-
            dir>/etc/passwd file is used to determine the initial
            directory and their home directory in the system-wide
            /etc/passwd is not used.

            <uid-range> specifies numeric UID values.  Ranges are
            specified  by  giving  the  lower  and  upper  bounds
            (inclusive), separated by a dash.  Omitting the lower
            bound means "all up to", and omitted the upper  bound
            means "all starting from".

            For example:
                guest-root /home/users
                guest-root /home/staff %100-999 sally
                guest-root /home/users/frank/ftp frank
            causes  all  guest  users  to chroot() to /home/users
            then starts each user in their home directory  speci-
            fied  in  /home/users/etc/passwd.  Users in the range
            100 through 999, inclusive, and user sally,  will  be
            chroot()'d  to  /home/staff and the CWD will be taken
            from their entries  in  /home/staff/etc/passwd.   The
            single    user    frank   will   be   chroot()'d   to
            /home/users/owner/ftp and the CWD will  be  from  his
            entry in /home/users/owner/ftp/etc/passwd.

            Note  that order is important for both anonymous-root
            and guest-root.   If  a  user  would  match  multiple
            clauses,  only  the first applies; with the exception
            of the clause which has no  <class>  or  <uid-range>,
            which applies only if no other clause matches.

       deny-uid <uid-range> [...]

       deny-gid <gid-range> [...]

       allow-uid <uid-range> [...]

       allow-gid <gid-range> [...]

            These clauses allow specification of UID and GID val-
            ues which will be denied access to  the  ftp  server.
            The  allow-uid  and  allow-gid clauses may be used to
            allow access for uid/gid  which  would  otherwise  be
            denied.   These checks occur before all others.  Deny
            is checked before allow.  The  default  is  to  allow
            access.  Note that in most cases, this can remove the
            need for an /etc/ftpusers files.  For example:
                deny-gid %-99 %65535
                deny-uid %-99 %65535
                allow-gid ftp
                allow-uid ftp
            denies ftp access to all privileged or special  users
            and  groups on a Linux box except the anonymous 'ftp'
            user/group.  In many cases, this  can  eliminate  the
            need  for  the  /etc/ftpusers file.  Support for that
            file still exists so it may  be  used  when  changing
            /etc/ftpaccess is not desired.

            Throughout the ftpaccess file, any place a single UID
            or GID is allowed, either names  or  numbers  may  be
            used.   To  use  numbers,  put  a  '%' before it.  In
            places where a range is allowed, put the  '%'  before
            the range.

       restricted-uid <uid-range> [...]

       restricted-gid <gid-range> [...]

       unrestricted-uid <uid-range> [...]

       unrestricted-gid <gid-range> [...]

            These  clauses  control  whether or not real or guest
            users will be allowed access to areas on the FTP site
            outside  their  home directories.  They are not meant
            to replace  the  use  of  guestgroup  and  guestuser.
            Instead,  use  these  to  supplement the operation of
            guests.  The  unrestricted-uid  and  unrestricted-gid
            clauses may be used to allow users outside their home
            directories who would otherwise be restricted.

            An example of the use of these  clauses  shows  their
            intended  use.   Assume user 'dick' has a home direc-
            tory /home/dick and 'jane' /home/jane:
                guest-root /home dick jane
                restricted-uid dick jane
            While both dick and jane are chroot'd to /home,  they
            cannot  access  each  other's  files because they are
            restricted to their home directories.

            Whereever possible, in situations such as this  exam-
            ple,  try  not  to  rely solely upon the ftp restric-
            tions.  As with all other ftp access  rules,  try  to
            use  directory  and  file permissions to backstop the
            operation of the ftpaccess configuration.

       site-exec-max-lines <number> [<class> ...]

            The SITE EXEC feature traditionally limits the number
            of  lines  of  output which may be sent to the remote
            client.  This clause allows you to  set  this  limit.
            If  omitted,  the  limit  is  20 lines.  A limit of 0
            (zero) implies no  limit;  be  very  careful  if  you
            choose  to  remove  the  limit.  If a clause is found
            matching the remote user's class, that limit is used.
            Otherwise,  the  clause  with  class '*', or no class
            given, is used.  For example:
                site-exec-max-lines 200 remote
                site-exec-max-lines 0 local
                site-exec-max-lines 25
            limits output from  SITE  EXEC  (and  therefore  SITE
            INDEX)  to 200 lines for sets a limit of 25 lines for
            all other users.

       dns refuse_mismatch <filename> [override]

            Refuse FTP sessions  when  the  forward  and  reverse
            lookups  for  the  remote site do not match.  Display
            the named file (like a message file), admonishing the
            user.   If  the optional override is specified, allow
            the connection after complaining.

        dns refuse_no_reverse <filename> [override]

        Refuse FTP sessions when there is no  reverse  DNS  entry
        for the remote site.  Display the named file (like a mes-
        sage file), admonishing the user.  If the optional  over-
        ride  is  specified, allow the connection after complain-
        ing.

       dns resolveroptions [options]

            The resolveroptions option allows you to  tweak  name
            server  options.  The line takes a series of flags as
            documented in  resolver(3)  (with  the  leading  RES_
            removed).   Each  can be preceded by an optional + or
            -.  For example,
                dns resolveroptions +aaonly -dnsrch
            turns on the aaonly option (only accept authoritative
            answers)  and turns off the dnsrch option (search the
            domain path).

Files
       FTPLIB/ftpaccess

See Also
       ftpd(8),  umask(2),  ftplog(5),  ftpconversions(5),   ftp-
       shut(8)

                                                                1