Provided by: wu-ftpd_2.6.2-33ubuntu1_amd64 bug

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 <groupname>.  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  "guestgroup"  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  additional  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 working nameserver.
            It  may  also  be  the  name  of  a file, starting with a slash ('/'), which contains
            additional 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 directory 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 process 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 overridden 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) conversation.  Setting this to zero (0) completely disables the daemon's
            use  of this protocol.  The information 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.

       data-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.  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>, displaying <message_file> if the user is
            denied access.  Limit check is performed at login time  only.   If  multiple  "limit"
            commands can apply to the current session, 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>] ... [-] <filename> <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-gettable,
            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-directories may be retrieved.  Also,  no
            files named '.htaccess' 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 members of particular classes.  If any
            class= is specified 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 permanently 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
            necessary 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 version.
            '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 maintainer.  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 notification.

            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

             ratios:

                %xu     Uploaded bytes
                %xd     Downloaded bytes
                %xR     Upload/Download ratio (1:n)
                %xc     Credit bytes
                %xT     Time limit (minutes)
                %xE     Elapsed time since login (minutes)
                %xL     Time left
                %xU     Upload limit
                %xD     Download limit

            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 directory 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 modified  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 anonymous 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
            "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).  <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  outgoing  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.

Upload/Download ratios

       In order for any of these commands to work, you must compile WU-FTPD with --enable-ratios.

       ul-dl-rate <rate> [<class> ...]

            Specify  Upload/Download  ratio  (1:rate).  When ftp user uploaded 1 bytes, (s)he can
            take <rate> bytes.  By default, there is no ratio.

       dl-free <filename> [<class> ...]

            The file <filename> can be downloaded freely (=ignoring the ratio)

       dl-free-dir <dirname> [<class> ...]

            All files in the directory <dirname> and its subdirectories can be downloaded  freely
            (=ignoring  the  ratio)  Note  that  both dl-free and dl-free-dir are relative to the
            system's root, not the chroot environment.

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 directories. 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/ftpconversions.

       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  connections  are dropped at a specified time before shutdown.  <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  connections  will  be  denied  and  existing  connections  will  be
            disconnected.

            <text> follows the normal rules for any message (see "message"), with  the  following
            additional magic cookies 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 configuration file.

            The external program ftpshut(8) can be used to automate  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 logfile 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  feature.  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 discouraged 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.

       virtual <address> passwd <file>

            Use  a  different passwd file for the virtual domain. The daemon needs to be compiled
            with --enable-passwd (or OTHER_PASSWD) for this option to work.

       virtual <address> shadow <file>

            Use a different shadow file for this virtual domain. The daemon needs to be  compiled
            with --enable-passwd (or OTHER_PASSWD) for this option to work.

       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 listens 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 daemon to listen on.  This feature  allows
            firewalls  to  limit  the  ports  which  remote  clients  may use to connect 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 connections 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  specification  of  the  command  and
            options  used to generate directory listings.  Note the options cannot contain spaces
            and the defaults for these clauses are generally  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 anonymous 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 anonymous uploads on that host.   Otherwise,  notifications  will  be
            sent to the global addresses.

            Defaultserver  addresses  only  apply  when  the  FTP session 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  specified.   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 specified 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 regexp> ...}

            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 /incoming/gifs.  Files that were uploaded
            to /incoming would be owned by ftp/daemon and would have permissions 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 followed 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  directory.  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  complete  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 determine 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  specified  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 values 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 directory /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 example, try not to rely  solely  upon
            the  ftp  restrictions.  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 ┬┤remote'
            users, specifies there is no limit at all for 'local' users, and 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 message file), admonishing the  user.   If  the  optional  override  is
       specified, allow the connection after complaining.

       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), ftpshut(8)

                                                                                     ftpaccess(5)