Securing Your NaSMail Setup
---------------------------

We try to make NaSMail as secure as possible, but the security of an install 
depends on a lot of factors. This file lists some tips to further improve the 
security of your webmail system.

- PHP configuration. It's strongly recommended to turn register_globals OFF. 
  NaSMail sets very strict coding requirements for register_globals = on 
  setups. If libraries are not loaded in correct order, scripts will break.

- HTTPS/SSL Logins. NaSMail runs fine over an https / SSL connection, and it's 
  not that hard to set one up.

- Data dir / attachment dir. Make sure that you've set these up with the
  right permissions (only for the webserver user) and that they're outside
  of your webserver's document root.

  There are a few security considerations regarding attachment directory.
  1. It should have the permission 733 (rwx-wx-wx) to make it impossible for
     a random person with access to the webserver to list files in this 
     directory.  Confidential data might be laying around in there.

     Depending on your user:group assignments, 730 (rwx-wx---) may be possible,
     and more secure (e.g. root:apache)

  2. Since the webserver is not able to list the files in the content is also 
     impossible for the webserver to delete files lying around there for too 
     long. Administrator can setup scripts that clean outdated information from
     attachment directory.

  3. Default configuration uses same directory to store data and attachments. 
     Such setup simplifies NaSMail installation. It is strongly recommended to 
     make sure that attachment directory differs from the data directory 
     specified in $data_dir setting.

- IMAPS / TLS. If your IMAP server is not on the same host as NaSMail,  you can
  configure NaSMail to use an encrypted connection to your IMAP server. Note 
  that this makes no sense if both are on the same machine.

  See doc/authentication.txt for info.

- Remote script access restrictions. Webserver configuration can allow remote 
  access only to src/, plugins/, css/ and images/ subdirectories. config/ 
  directory needs access rights only for initial web based setup. doc/ 
  directory contains only administrative information about NaSMail. All other 
  subdirectories store libraries and are never accessed by NaSMail scripts 
  remotely. In top NaSMail directory, remote users need access rights only for 
  index.php script.

- config.php. Some options in conf.pl / config.php allow for passwords to
  be set in that file, e.g. the address book/preferences DSN, and LDAP
  addressbooks. When setting a sensitive password, check that config.php
  is not readable for untrusted system users, and consider the possibility
  of it being read by other users of the same webserver.

  Database address books and preferences don't need administrative privileges
  on database server. Login information stored in config.php can give only 
  SELECT, INSERT, UPDATE and DELETE rights on address book and preference 
  tables. If address book is read-only, only SELECT right is needed.

- Session information security. NaSMail can store one time passwords, user 
  preferences, message cache and other private information in session. In some
  setups session stores all password information and not only one time pad. 
  Session data should be unreadable by third party.

- If you use SELinux, NaSMail will not work unless you create a policy for it. 
  In the SELinux Policy Editor, under HTTPD Service, enable "allow HTTPD 
  scripts and modules to connect to the network".

These are only some tips to get you started. A truly secure system needs
careful tweaking of all components, including PHP, Apache, mail server,
the underlying OS, which users can login, etc. Searching the web will turn
up lots of information.
