WEB邮件程序

开发平台：
C/C++

INSTALL：源码内容
							
                                 Installation
                                       
     * Overview
     * Authentication modules
     * Confirming selected authentication options
     * LDAP authentication
     * VPOPMAIL authentication
     * PAM authentication
     * MySQL authentication
     * AUTHDAEMON proxy
     * Runtime configuration
     * Domain-based templates
     * Shared folders
     * LDAP address books
       
Overview
   The typical sequence of commands to compile and install SqWebMail is
   as follows:
  ./configure [options - see below]
  make configure-check
  make
  make check
  make install-strip
   Be sure to read the notes below if you intend to use LDAP or vpopmail
   authentication.
   
   NOTE: On some systems "make install-strip" fails due to a combination
   of a brain dead install program, and an automake bug. If that happens,
   enter "make install" instead. The only difference would be that
   sqwebmail installs without stripping the debug data. If you can live
   with a deceptively large binary in your cgi-bin, that's fine. If not,
   you can strip the binary manually, using the strip command. However,
   take care to preserve the ownership and the permissions of the binary,
   because the strip command may lose them.
   
   If the --with-cachedir option is used, after installing you must add a
   cron job that runs the cleancache.pl script at regular intervals.
   cleancache.pl is installed in /usr/local/share/sqwebmail, or in the
   directory specified by the --with-htmllibdir option.
   
   The options to the configure program are as follows:
     * --with-module, --without-module - explicitly specifies that
       authentication module named "module" should be included or
       excluded. See below for more details.
     * --with-cachedir - SqWebMail will create a directory that caches
       login information. This option may be useful to sites with large
       number of logins, or if authentication is comparatively expensive
       (such is the case with LDAP or vpopmail/MySQL authentication). The
       cache will remove the need to scan the passwd database for each
       http request. If this option is used, it will be necessary to also
       install a small cron job that regularly purges expired cache
       entries.
     * --with-cachedir=dir - use dir instead of /var/run/sqwebmail, or
       /var/cache/sqwebmail (one or the other is selected by default),
       for the cache directory.
     * --with-cacheowner=user - specifies who should own the cache
       directory. This is bin by default. However, if you choose to
       install vsqwebmail owned by the virtual userid, instead of root,
       you MUST use the cacheowner option to specify the virtual userid.
     * --without-gzip - do not use gzip compression. By default, some
       pages will be compressed with gzip before being sent by sqwebmail
       (to browsers that support gzip compression). Note that this may
       result in additional load on your server, so --without-gzip can be
       used to turn it off, if necessary. The gzip program must be in
       your default path at the time you run configure in order for gzip
       compression to be enabled (the absolute pathname is computed and
       used at runtime).
     * --with-db=db - SqWebMail requires that you must have either the
       GDBM or the DB library. The configuration script will check for
       either one's availability. If both are found, GDBM will be
       selected. Use this option to select the DB library instead (if you
       only have the DB library installed, this option is not required).
     * --enable-https - have SqWebMail generate https:// URLs for all
       accesses, instead of http://.
     * --enable-https=login - generate a single https:// URL for the
       login function only. The idea is to use SSL just to send the login
       and the password. In order for this option to work the URL for
       both http:// and https:// path to SqWebMail must be identical!
     * --enable-webpass=no - do not use SqWebMail-only passwords as an
       alternative authentication mechanism. This mechanism allows the
       user to specify a SqWebMail-only password to be used for logging
       in, instead of the default system password. This password will be
       stored in a protected file in the user's Maildir directory. See
       SECURITY for more information.
     * --enable-webpass=vpopmail - use the vpopmail.a library to change
       passwords (this will only work if the virtual userid used for the
       accounts also owns the vpopmail password database).
     * --enable-hardtimeout=seconds - hard session timeout interval, in
       session. After the interval expires, the user is automatically
       logged out.
     * --enable-softtimeout=seconds - soft session timeout interval, in
       session. If no account accesses come within the indicated time
       period, the user is automatically logged out.
     * --enable-autopurge=days - deleted messages are automatically
       purged after this time interval by default.
     * --enable-maxpurge=days- allow users to specify days as the maximum
       interval for preserving deleted messages.
     * --with-htmllibdir=directory - a directory where SqWebMail stores
       its HTML template files. Note - this directory SHOULD NOT be
       accessible by httpd.
     * --with-defaultlang=en - reserved for future use. Selects which set
       of HTML template files SqWebMail will serve by default. Currently
       only English HTML templates are supplied.
     * --enable-cgibindir=directory - where to install the sqwebmail
       executable program. This should be your /cgi-bin directory. The
       configure script will look for one in the usual places, this
       option can be used to tell configure where to look.
     * --enable-imagedir=directory - where to install the icons and
       images program. This should be somewhere in your web server's
       document hierarchy. The configure script will look for one in the
       usual places, this option can be used to tell configure where to
       look.
     * --enable-imageurl=URL - the URL to the directory containing images
       and icons. The given URL must contain a trailing slash.
     * --enable-mimetypes=filelist - a colon-separated list of your
       mime.types files. When an attachment is uploaded, the
       corresponding MIME type is derived by searching for the file's
       extension in the mime.types file. A mime.types file normally comes
       with Pine or Apache. If this option is not specified, configure
       will look in some places where mime.types is usually found. If a
       mime.types file is found in any directory, it is added to the
       list. This is a list of multiple files separated by a colon. If
       the MIME type is not found in the first file, SqWebMail will look
       in the next file.
     * --enable-mimecharset=charset - default charset= tag to stick into
       the Content-Type: header. the default is us-ascii.
     * --enable-lang=lang - reserved for future. Default language of web
       pages to serve.
     * --enable-bannerprog=program - full path to a banner program.
       sqwebmail replaces @B in the HTML template files with the output
       generated by this program. The first argument to the program will
       be the name of the HTML file. The banner program can use that to
       customize banner output.
       It is also possible for a site to stick multiple @B tags in the
       same HTML page. To distinguish each instance follow the @B tag
       with up to 30 letters or digits, surrounded by braces. For
       example: @B{TOP} and @B{BOTTOM}. "TOP", or "BOTTOM" (or anything
       else) will be the second argument to the banner program.
     * --with-maxargsize=n - set maximum size of an HTTP post SqWebMail
       will accept.
     * --with-maxformargsize=n - like the above, but applies to an HTTP
       multipart/formdata post. This is approximately the largest
       attachment that can be uploaded SqWebMail.
     * --with-maxmsgsize=n - maximum size of messages (including
       attachments. Defaults to 2097152 (two megabytes). Note that
       attachments are base64-encoded, which adds 25% overhead, so the
       maximum size of attachments is really about 1.5 megabytes.
     * --with-ispell=pathname - if configure finds ispell in the default
       path, or if you specify the full name to ispell using this option,
       users will be able to spell check their documents.
     * --without-ispell - disable spell checking.
       
     * --with-fcgi - enable fastcgi support (see http://www.fastcgi.com).
       Assumes libfcgi.a and headers are in search path or in main
       sqwebmail build directory. --enable-bannerprog doesn't work with
       fcgi.
       
   After running configure, run make configure-check to verify the
   directories where the CGI and the image files will be installed. make
   configure-check prints the directories that the configuration script
   thinks your web server is installed. Rerun configure and use
   --enable-cgibindir and --enable-imagedir if necessary.
   
   Run make to compile SqWebMail, and make install-strip to install the
   files. As mentioned before, use make install if make install-strip
   fails for some silly reason. To serve the initial log-on script, the
   URL is the path to the sqwebmail (or the vsqwebmail) program, with no
   additional frills. SqWebMail will take it from there.
   
   Before running make install-strip, check out the sendit.sh script, and
   make sure that your mail transfer agent is corrently invoked.
   
Authentication modules
   Authentication modules are responsible for taking the entered userid
   and password, validing them, then locating the corresponding Maildir
   for the userid. The authentication module mechanism replaces a hodge
   podge of various authentication-related options to the configure
   script that were present in earlier versions of SqWebMail.
   
   There are several authentication modules available. Each
   authentication module implements a separate way of authenticating
   logins, and not all authentication modules can be used by everyone.
   Some authentication modules can be used only on systems that have
   certain libraries or software installed separately.
   
   The --with-module and --without-module options to the configure
   specify whether a given authentication "module" should be explicitly
   included or excluded. Multiple --with and --without options are, of
   course, allowed (each one specifying a different authentication
   module). As explained later, it will not be necessary in most cases to
   explicitly specify the disposition of each one of the following
   authentication modules, and most people will find it sufficient to let
   the configure script decide which one of the following authentication
   modules will be used:
     * authpwd - this module looks up userids and passwords in your
       /etc/passwd file, or the equivalent NIS map (as supported by your
       system's getpw functions).
     * authshadow - this module is like authpwd, except that it should be
       used on systems that use shadow password files, /etc/shadow.
     * authpam - this module should be used on systems that have the PAM
       library. With this module, SqWebMail will use whatever PAM modules
       are defined for authenticating the "webmail" PAM service.
       Essentially, authpam allows any PAM module to be used for
       authenticating SqWebMail's logins. NOTE: in addition to including
       this module, you will have to take additional, site-specific,
       steps in order to configure your PAM library for the "webmail" PAM
       service. The specific details regarding your PAM configuration
       differs from system to system, and you should consult your own
       documentation. It might be tempting to throw in a towel and use
       authshadow or authpwd if you cannot figure out how to install PAM
       support, however that is not advisable. It is highly recommended
       to use authpam wherever the PAM library is available.
     * authuserdb - this module uses GDBM or DB database files, usually
       /etc/userdb.dat and /etc/userdbshadow.dat to look up userids and
       passwords. These files are GDBM or DB database files that are
       loosely equivalent in function to /etc/passwd and /etc/shadow.
       These database files are maintained indirectly by several Perl
       scripts (which are included with SqWebMail), which build these
       database files from a plain text file, usually called /etc/userdb
       that can be modified using any text editor, or via command line
       with the aid of the Perl scripts. /etc/userdb may also be a
       subdirectory containing multiple text files of the same format,
       which are concatenated. This allows creation of virtual mail
       accounts that do not have a corresponding login account -- virtual
       mail accounts that can share the same, reserved, system userid.
       /etc/userdb can also be used to complete supercede /etc/passwd.
       With many accounts it can be quite a drain to have to continuously
       linearly scan /etc/passwd in order to look up an account. Instead,
       a fast database lookup can retrieve the same information from the
       database file. Read the included manual pages, starting with
       userdb(8) for more information.
     * authvchkpw - this is another virtual mail database lookup module,
       except that it uses the vpopmail vpasswd files. This module is
       provided for a quick way to use your existing vpopmail vpasswd
       files. Where possible, you should convert over to /etc/userdb. The
       included script vchkpw2userdb(8) might be of some help in doing
       so.
     * authmysql - this is yet another virtual mail database lookup
       module, that uses the MySQL database. Note, that this is a NATIVE
       MySQL authentication module, which is different from authvchkpw.
       NOTE -- not yet functional for SqWebMail -- needs additional work.
     * authldap - authenticates against an LDAP server. This is a new
       module included with SqWebMail 0.28, and should be considered as
       unstable, untested, code. See below for more information.
     * authdaemon - daemon authentication proxy. This is not a new
       authentication method. Enabling this module installs a background
       daemon process, authdaemond that must be activated at system boot
       time. Authentication requests are then implemented by this daemon
       process. This can be very useful if expensive database authention
       back-end is used (such as an LDAP or MySQL), where connecting and
       disconnecting to the database can be very expensive. The
       background daemon process would maintain a persistent database
       connections, and process authentication requests with greater
       efficiency. See below for more information.
       
   It is possible to include more than one authentication module. For
   example, if you select both authuserdb and authpam, each login will
   first be authenticated against /etc/userdb. If SqWebMail cannot find
   the specified account in /etc/userdb, it will then attempt to
   authenticate using the PAM library.
   
   If neither --with nor --without is specified for any one of these
   modules, the configure script will try to figure out whether or not to
   the given authentication module should be used. Therefore, in most
   situations, it will not be necessary for you to explicitly specify
   what to do with each authentication module. For most people, letting
   configure figure it out will be sufficient.
   
   configure will use the following logic to determine which
   authentication modules need to be included by default:
     * authuserdb - this module is always included by default
     * authpam - configure will attempt to detect if the PAM library is
       installed, or not. In most cases, an explicit --with-authpam will
       not work if the PAM library is missing, because PAM development
       libraries, required for compilation, are probably unavailable as
       well. --without-authpam can be used to avoid installing authpam on
       systems that do have a PAM library installed. Hopefully, you will
       have a good reason to do something this silly.
     * authpwd, authshadow - whether or not these modules are installed
       by default depends upon what happened with authpam and authldap.
       If PAM or LDAP support is installed, via authpam or authldap,
       these two modules are usually not necessary, because the PAM
       library, or the LDAP server, provides this functionality. If PAM
       support is unavailable, these modules will be installed by
       default.
     * authdaemon - the authdaemon proxy (see below) is enabled by
       default if either authmysql or authldap is enabled, and disabled
       otherwise.
     * authvchkpw - this module is compiled by default only if the
       vpopmail account is defined.
       
Confirming selected authentication options
   You can find out what authentication modules were actually used, but
   after running the configure script you must also at least run make,
   and have it succesfully complete. Running make, compiles the authinfo
   program in the authlib subdirectory. Run this program to tell you what
   authentication modules got compiled in.
   
LDAP authentication
   SqWebMail 0.28 includes a new experimental authentication module,
   authldap, which should be considered as unstable, untested, code. This
   module attempts to authenticate against an LDAP server, and will
   automatically enable the --with-cachedir option to configure, because
   it is required for LDAP authentication to work.
   
   This option will install a template configuration file, which is
   /usr/local/share/sqwebmail/authldaprc by default. This configuration
   file defines the location of your LDAP server, as well as the names of
   attributes used to perform LDAP authentication. See the comments in
   the sample configuration file, and the authldap(8) manual page, for
   more information.
   
VPOPMAIL authentication
   If you use vpopmail's support for MySQL authentication, you MUST use
   the --enable-logincache option, and do everything you need to do in
   order to use this option (install the cron job, etc...), otherwise
   you're going to bring your server to its knees.
   
PAM authentication
   On systems that have the PAM library, SqWebMail will use the PAM
   library to authenticate userids and passwords. However, you must
   explicitly configure the PAM library to authenticate the webmail
   service. Different versions of the PAM authentication library use
   different configuration procedures, so you will need to consult your
   documentation. This is a separate process, and because of the
   differences amongst many PAM implementations, SqWebMail can't do that
   for you.
   
   The following instructions will work with most versions of the PAM
   library, and should be tried as a last resort:
   
   If you have the directory /etc/pam.d, you should create the file
   /etc/pam.d/webmail, containing the following text:
#%PAM-1.0
auth    required  /lib/security/pam_pwdb.so shadow nullok
account required  /lib/security/pam_pwdb.so
   Your system may use the pam_unix.so module instead of pam_pwdb.so, and
   your modules may be located in a different directory.
   
   If instead of /etc/pam.d you have a global file named /etc/pam.conf,
   try appending the following lines to the end of this file:
webmail auth    required pam_pwdb.so shadow nullok
webmail account required pam_pwdb.so shadow nullok
   Again, you may have to use pam_unix.so or specify the full pathname to
   the PAM module.
   
MySQL authentication
   This module allows authentication information to be stored in a MySQL
   database.
     * Supports both physical and virtual mail accounts.
     * Can be configured to use either crypted or cleartext passwords (or
       both).
       
   When authmysql is installed, a default configuration file, authmysqlrc
   will be installed too. You must edit this file to set up your MySQL
   authentication.
   
   NOTE: this authentication module should NOT be used if you are using
   the vpopmail virtual mailing list manager. You should select the
   authvchkpw authentication module instead (which should happen
   automatically). It may be necessary to use the --without-authmysql
   flag to the configure script, because configure by default will
   include authmysql if it finds MySQL client libraries..
     _________________________________________________________________
   
   Edit authmysqlrc, and initialize the following variables:
     * MYSQL_SERVER - MySQL server name (required).
     * MYSQL_USERNAME - MySQL username with log in with (required).
     * MYSQL_PASSWORD - MySQL password with log in with (required).
     * MYSQL_DATABASE - MySQL database to log in to (required).
     * MYSQL_USER_TABLE - name of the MySQL with the authentication
       information (see below) (required).
     * MYSQL_CRYPT_PWFIELD - name of the field containing the crypt-ed
       password (either MYSQL_CRYPT_PWFIELD or MYSQL_CLEAR_PWFIELD is
       required).
     * MYSQL_CLEAR_PWFIELD - name of the field containing the cleartext
       password (either MYSQL_CRYPT_PWFIELD or MYSQL_CLEAR_PWFIELD is
       required).
     * MYSQL_MAILDIR_FIELD - name of the field containing a non-default
       location of the account's system mailbox (optional).
     * DEFAULT_DOMAIN - if the user logs in without specifying @domain,
       use the following domain (in this case the id field must always
       contain user@host) (optional).
       
   The table specified by MYSQL_USER_TABLE should look as follows
   (recommended):
CREATE TABLE passwd (
        id                    char(128) DEFAULT '' NOT NULL,
        crypt                 char(128) DEFAULT '' NOT NULL,
        clear                 char(128) DEFAULT '' NOT NULL,
        uid                   int(10) unsigned DEFAULT '65534' NOT NULL,
        gid                   int(10) unsigned DEFAULT '65534' NOT NULL,
        home                  char(255) DEFAULT '' NOT NULL,
        maildir               char(255) DEFAULT '' NOT NULL,
        KEY id (id(128))
);
AUTHDAEMON proxy
   Selecting the authdaemon authentication module installs a binary,
   /usr/libexec/sqwebmail/authlib/authdaemond, and you must arrange to
   execute the following command at system boot time:
/usr/libexec/sqwebmail/authlib/authdaemond start
   You may also run authdaemond stop from the system shutdown script.
   
   authdaemon offers an alternative to compiling all the authentication
   methods into SqWebMail. Enabling authdaemon in addition to any other
   modules will result in authdaemon being built as the only "official"
   authentication module. However, the remaining modules are compiled
   into the separate "authdaemond" process.
   
   The authdaemon module uses a filesystem socket to forward the
   authentication request to the running authdaemond process. The
   filesystem socket is created in the directory
   /usr/local/share/sqwebmail/authdaemon, so the filesystem where this
   directory is must be able to support filesystem domain sockets. Most
   networks filesystems, like NFS or AFS, either do not support
   filesystem domain sockets, or the support is troublesome. You may
   install a soft link at that location that points to a directory on a
   local disk. Note that this directory must be owned by root, and must
   not have ANY group or world permissions.
   
   The /usr/local/share/sqwebmail/authdaemonrc configuration file sets
   several operational parameters for the authdaemond process. See the
   comments in the default file installed for more information.
   Currently, authdaemonrc sets two parameters: number of daemon
   processes, and which available authentication modules will be used.
   
   Although authdaemond might be built with several authentication
   modules, not all of them may be used. This allows for a single
   authdaemond build to be made that gets installed on multiple systems
   with different authentication needs. The default module list specified
   by authdaemonrc would be a list of all the available authentication
   modules.
   
   The number of authdaemond processes is also set in this configuration
   file. The more processes that are started, the more authentication
   requests can be handled. If authdaemon does not receive an answer
   within a moderate amount of time, it will declare an authentication
   failure, and abort. Try increasing the number of processes if you
   start seeing random authentication failures. However, that should only
   be used as a stop-gap measure. If the default number of authdaemond
   processes proves to be insufficient, it is far more likely that more
   resources are needed for the server: more RAM, a faster disk, or a
   faster CPU, at least in the humble opinion of the author. Increasing
   the number of processes should only be used as a stop-gap measure,
   until a more thorough analysis on the bottleneck can be made.
   
   After making any changes to authdaemonrc, run the following command
   for these changes to take effect:
    /usr/libexec/sqwebmail/authlib/authdaemond restart
Runtime configuration
   There's some limited amount of configuration that can be done after
   installation. The following presumes that SqWebMail's supporting files
   have been installed in /usr/local/share/sqwebmail.
   
   /usr/local/share/sqwebmail/hostname - when SqWebMail is installed with
   a basic configuration for a single domain, SqWebMail sets the domain
   in the return address for outgoing messages to the defined system
   hostname. If this file exists it will be used instead of the defined
   system hostname.
   
   /usr/local/share/sqwebmail/sendit.sh is a shell script that's called
   to actually mail a message. It can be customized to do something like
   rewriting some of the headers, or adding the client's IP address to
   the headers (sqwebmail does not do that by default).
   
   /usr/local/share/sqwebmail/nochangingfrom - if this file exists (it
   can be a 0-length dummy file), SqWebMail will not allow the From:
   header to be changed, it will always have its default value.
   
   /usr/local/share/sqwebmail/usexsender - if this file exists (it can be
   a 0-length dummy file), SqWebMail will attach an X-Sender: header to
   all outgoing messages. This can be used in the event you would like to
   be able to modify the From: header, yet also be able to track sent
   mail to the original account. Although your mail server should records
   the id of the sending user in the headers of outgoing messages, this
   is not possible when you have many virtual accounts that share the
   same system userid.
   
   /usr/local/share/sqwebmail/noimages - if this file exists then no
   images or icons will be used. The generated interface will be a
   text-only interface.
   
   /usr/local/share/sqwebmail/logindomainlist - if this file exists then
   the login screens will include a drop-down list whose contents will be
   read from this file. This file should contain a list of E-mail
   domains, one per line. It should be created if SqWebMail is used to
   provide mail access for multiple domains. Instead of typing
   "user@domain" to log in, it will only be necessary to enter "user",
   and select the domain from the drop-down list.
   
   /usr/local/share/sqwebmail/html/LANG/footer - if this file exists, the
   contents of this file will be appended to the end of every sent
   message. LANG is the language code here, there can be a separate
   footer per installed language.
   
Domain-based templates
   The default set of templates for the dynamically generated HTML is
   installed in /usr/local/share/sqwebmail/html. When the same server is
   used to provide webmail access for multiple domains it is possible to
   specify a different set of HTML templates for each domain.
   
   This functionality is not directly implemented in SqWebMail, simply
   because there is no standard way to specify this. Instead, this is
   something that will require some minor manual set up to work.
   
   Domain-based templates are implemented by making the web server set
   the environment variables SQWEBMAIL_TEMPLATEDIR prior to running the
   sqwebmail CGI. The contents of this environment variable override the
   default location of /usr/local/share/sqwebmail/html. By having the web
   server initialize this variable based on the domain name it is
   possible to present different templates, based on the domain name
   used.
   
   To do this, as many different copies of the HTML templates as are
   needed must be created, in different directories, then the web server
   must be configured to initialize SQWEBMAIL_TEMPLATEDIR appropriately.
   For example, with Apache:
  <VirtualHost a.b.c.d>
    ServerName webmail.example.com
    [...]
    SetEnv SQWEBMAIL_TEMPLATEDIR /usr/local/share/webmail/webmail.example.com
    [...]
  </VirtualHost>
   The possibilities are endless.
   
Shared folders
   SqWebMail supports shared folders. The SqWebMail distribution includes
   an enhanced maildirmake command that created shared folders.
   
   The maildirmake command will be installed in
   /usr/local/libexec/sqwebmail by default, and the manual page will be
   installed in /usr/local/share/sqwebmail/man by default.
   
   See the manual page for more information on how to set up shared
   folders.
   
LDAP address books
   SqWebMail can import E-mail addresses from public LDAP address books
   into an individual address book. A default systemwide list of
   accessible LDAP address books is defined for everyone, and individuals
   can configure additional LDAP address books for themselves.
   
   OpenLDAP runtime libraries and tools are required to be installed in
   order to search LDAP address books. It is not necessary to have
   OpenLDAP development libraries installed. SqWebMail simply runs the
   ldapsearch tool to query LDAP address books, and parses the results.
   
   The file /usr/local/share/sqwebmail/ldapaddressbook should contain a
   default systemwide list of accessible address book. A default file
   will be installed, listing some common Internet address books. Each
   line in this file contains the following information:
name<tab>host<tab>port<tab>suffix<tab>binddn<tab>bindpw
   <tab> is a single ASCII TAB character.
   
   The file /usr/local/share/sqwebmail/ldapsearch is a wrapper shell
   script that calls the ldapsearch tool. The configuration script
   attempts to find the location of where OpenLDAP tools are installed.
   The path to ldapsearch in this shells script should be verified and
   fixed, if necessary. The default shell script adds some additional
   options to ldapsearch to limit the search time to sixty seconds, and
   to return a maximum of twenty entries from the address book.

						