Linux E-mail: Providing Webmail Access (Part 1)

Exclusive offer: get 50% off this eBook here
Linux Email

Linux Email — Save 50%

Set up, maintain, and secure a small office email server

£16.99    £8.50
by Alistair McDonald | January 2010 | Linux Servers

In this article series by Alistair McDonald, author of Linux Email, you will learn about the following:

  • The benefits and disadvantages of a webmail access solution
  • The SquirrelMail webmail package
  • Setting up and configuring SquirrelMail
  • What SquirrelMail plugins are and what they can do
  • How to make SquirrelMail more secure

The webmail solution

A webmail solution is a program or a series of scripts that is run on a server, is accessible over the web, and provides access to e-mail functions similar to a conventional mail client. It is used by Yahoo! Mail, Microsoft Hotmail, Microsoft Outlook Web Access, and Gmail as the primary interface to their e-mail solutions. You may already be familiar with various forms of webmail.

Though we will be examining the SquirrelMail webmail solution specifically, the benefits and drawbacks of SquirrelMail apply to most webmail systems in the market. From this point of view, we will approach the issue from a general perspective, and then in detail for the SquirrelMail package.

The benefits

This section will focus on the advantages offered by installing and maintaining a webmail solution. As with any list, it is not entirely comprehensive. Many benefits will be specific to a particular case; it is important to carefully examine and consider how the following qualities impact your individual situation.

The main benefits we will explore in this section are as follows:

  • Easy and quick access with little or no setup
  • Easy remote access
  • No need to maintain client software or configuration
  • Provision of a user interface to configure mail server options
  • Possible security benefits

Easy and quick access

Although well suited to certain situations, traditional mail access solutions can often be difficult to set up and maintain. Generally, this involves installing software on a client's local computer and configuring it. This can be difficult, especially in cases where users need to set up the software themselves. Configuration can often be even more problematic as some users may not be competent enough to follow even a very detailed set of instructions. These instructions also need to be provided and maintained for many different mail clients on many different platforms.

However, a webmail solution does not have most of these problems. All of the user's settings can be configured on the server as the application itself resides on the server. This translates to almost zero set up time for the user. Once they have received their login credentials, they can visit the webmail site and instantly have access to all of their mail. The user is able to access the site instantly to send and receive e-mail.

As the Internet is so common now, many users will be familiar with webmail sites such as Google Mail and Windows Live Hotmail, which offer free e-mail services. However, the user interface provided by an open source package may be more primitive and lack some visual features. Squirrelmail provides access to e-mail, including the ability to send and receive attachments, and offers a good user interface.

It is also worth mentioning that a webmail solution can offer what certain traditional mail clients call groupware features. These features let groups communicate and coordinate in ways that complement e-mail communication. Examples of groupware components are private calendars, shared calendars, meeting scheduling, To-do lists, and other similar tools.

These applications can be preconfigured so that a user can instantly begin using them without having to configure them on their own. Several SquirrelMail plugins which implement these features are available from the SquirrelMail website.

Easy remote access

Another problem with traditional mail access software is that it is not portable, as an e-mail client needs to be installed and configured on a computer. Once it has been downloaded, installed, and configured on a particular computer, it is accessible only on that computer. Without webmail, users on the road will not be able to access e-mail from friends' computers, mobile devices, or Internet booths at airports.

However, in a webmail solution, e-mail can be accessed from any location with an Internet connection. Employees can access their work e-mail from any computer with an Internet connection and a suitable browser.

As the administrator, you can choose to permit or deny users from accessing e-mail in insecure situations. By requiring the connection to be encrypted, you can ensure that when a user is in a remote location, their communication with the server is secure.

No need to maintain clients

Even if software mail clients have been installed and properly configured, they must be maintained. When a new version is released, all clients must be updated. This is not necessarily an easy task. Software that does not work as expected can result in a large number of support-desk calls.

Updating the software on each client can be a very large administrative burden. In fact, many expensive software packages are designed for the specific purpose of updating software on individual machines automatically. Despite this, problems specific to each local machine often arise and must be solved individually. It may also be difficult to convey instructions or notifications to remote branch locations or remote workers. With a webmail solution, this is not necessary.

In contrast to this, a webmail solution is centrally maintained and administered. The webmail application resides on the server. With webmail, only the web server and the webmail package need to be upgraded. Any exceptions or problems that arise can be dealt with before or during the upgrade. The software upgrade itself can be run through on a test system before it is deployed on a live system. Although changes in settings are rare with SquirrelMail, it is possible to update a user's settings to make them compatible with the changes introduced in an updated version.

Additionally, while upgrading or changing a mail server platform, testing effort can be greatly reduced as only supported browser versions need to be tested. It is advisable to mandate particular browser versions for corporate computers. In contrast with e-mail clients, there is no need to test on all of the possible clients and software platforms.

Configuring mail server interface via the user interface

Many traditional desktop e-mail clients provide only e-mail functionality and nothing more. Often there is no support for other essential tasks (such as changing the access password) that are performed on behalf of a mail user. Certain configuration options that reside on the server may require additional software applications or external solutions to provide for these needs. Examples of mail server options that may need to be configured include each user's password and junk mail filtering settings.

In the case of the SquirrelMail webmail application, many plugins have been developed that provide these features. For example, a user is able to change his/her password directly from the webmail interface. Also, there are plugins and systems that allow users to easily sign up without any direct human intervention. This may be useful if you are interested in providing a service where users can sign up without needing an administrative overhead.

Possible security benefits

This issue can be seen in two different ways—it is for this reason that the title is listed as "Possible" security benefits. Nonetheless, this is still an interesting point to examine.

In the software client access model, e-mail is traditionally downloaded onto the local user's computer, being stored in one or more personal folders. From a security perspective, this may be a bad thing. Users of the system may not be as conscientious or knowledgeable about computer security as a trained computer administrator might be. It is often much easier to gain unauthorized access to an end user's computer than a properly configured and secured server. The implication is that someone who stole a company laptop might be able to access all the e-mail stored on that computer.

There is one more disadvantage associated with the client access model. Even if an employee is terminated, he/she may still have access to all of the e-mail that  resides on his/her local office computer. It may take a certain amount of time before important information may be secured. A disgruntled worker might easily connect an external storage source to their local office computer and download any data they desire.

It is also worth noting that in a webmail model, all e-mail is centrally stored. If an attacker were to gain access to the central e-mail server, he/she might access all the e-mail stored on that server. However, it is possible that an attacker will gain access to all the e-mail if the central mail server is compromised even if a webmail system is not used.

The disadvantages

This section focuses on the disadvantages resulting from providing and supporting a webmail solution. The warning given in the previous section applies: This list is not entirely comprehensive. Each situation is unique, and may bring its unique disadvantages.

We will go over the following disadvantages of a webmail solution:

  • Performance issues
  • Compatibility with large e-mail volumes
  • Compatibility with e-mail attachments
  • Security issues

Performance

The traditional e-mail client is designed in the client-server model. One mail server accepts and delivers e-mail to and from other mail servers. However, a desktop mail client can offer many additional productivity-enhancing features such as message sorting, searching, contact list management, attachment handling, along with more recent ones such as spam filtering and message encryption.

Each of these features may require a certain amount of processing power. The required level of processing power may be negligible when it comes to storing one user's e-mail on a desktop computer, but providing these features may be problematic when applied on a larger scale to a single server.

When examining the performance issue, it is important to consider the number of potential users that will access the webmail application and size a server accordingly. A single server may be able to easily handle something like 300 users, but if the number of users increases significantly, server load may become an issue.

For example, searching through several years' archived mail may take a few seconds on a client's computer. When one user performs this task using webmail, the load will be similar. However, if many clients request this operation at short intervals or concurrently, it may be difficult for the server to process all the requests in a timely manner. This may result in pages being served at a slower rate or, in extreme circumstances, the server failing to respond.

Optimally, load testing in the appropriate conditions should be performed if there is any concern that a server may not be able to handle a particular load of users.

Compatibility with large e-mail volumes

The webmail solution is not well suited to large mail volumes. This disadvantage is related to the previous one, but is more related to the amount of data sent. Even with a relatively low number of users, a large volume of e-mails may be difficult to manage in a webmail application. There are mainly the following two reasons for this:

  1. Firstly, every e-mail viewed and every folder listed must be sent from the server each time. With a traditional e-mail client, the client software can manage e-mail messages, creating lists and views to suit the user. However, with a webmail solution, this is performed on the server. So, if there are many users, this overhead may use a significant proportion of the server's resources.
  2. Secondly, each interaction with the webmail application requires a Hypertext Transfer Protocol (HTTP) request and response. These messages will typically be larger than those between an e-mail server and a desktop e-mail client. There may also be less parallelism when using a webmail client, inother words, fewer things going on at the same time. A desktop e-mail client may be able to check for new e-mails in several folders at the same time, but a webmail client will typically perform these tasks one after the other, if they occur automatically at all.
Linux Email Set up, maintain, and secure a small office email server
Published: November 2009
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

Compatibility with e-mail attachments

The webmail solution is not well suited to e-mail attachments. By virtue of the fact that a webmail application resides on a remote server, any and all e-mail attachments must first be uploaded onto that server. For a couple of reasons, it may be difficult or impossible to accomplish this operation with too many attachments or with attachments that are large in size.

Difficulties uploading large attachments may arise due to limited storage space on the webmail server. Large attachments may take a long time to upload over the HTTP protocol and even longer over HTTPS. Additionally, many file size limits may be imposed on uploaded files. PHP, the programming language used with SquirrelMail, imposes a 2MB limit on uploaded fi les in its default configuration.

The solution to the above problem may lie in the nature of the webmail access solution—e-mail and the mail access software reside on the server. In a traditional mail client, e-mail is often downloaded before the user is aware of the contents or size of the particular e-mail message. As opposed to this, in the case of webmail, the user is able to view e-mail with large attachments without downloading the attachments—a particular benefit to those without high-speed internet connections.

Finally, downloading and uploading large e-mail attachments from the server may cause a performance issue with the user interface. Many users are frustrated by an attachment's upload time in the webmail application, especially as the message cannot be sent until the attachment is uploaded. In a traditional mail client, the attachment is attached instantly, while the message takes time to send.

Security issues

The last issue we will examine is the potential for security shortcomings. One important feature of a webmail access solution also creates a potential problem. The benefit of remote access gives way to the potential insecurity of the local machines upon which the user accesses his/her mail.

A computer that is not directly under your control may be controlled by a third-party intent on accessing your information. Normally, a computer does not record a user's individual keystrokes. Internet cafes and kiosks, and even the home computers of employee's could be running malicious software. This malicious software may monitor keystrokes and websites visited. A user must type in his/her password or login credentials to gain access to the system. When these credentials are captured and stored on the computer with malicious software, they can be intercepted and used by third parties for unauthorized access.

Even if we take malicious intent out of the picture, there are still certain situations that may prove to pose security risks. For example, many modern web browsers offer the option of saving a password whenever it is entered. This password is stored on the local computer where the website is visited. If a user logs in to the webmail application and accidentally saves their password on the local computer, this password may be accessible to any user with access to that local computer.

Finally, users may inadvertently leave themselves logged in to the webmail application. Without logging out, any user with access to that specific computer might be able to gain access to the user's mail account.

The SquirrelMail webmail package

The following screenshot shows the SquirrelMail login screen:

Linux E-mail: Providing Webmail Access (Part 1)

SquirrelMail was chosen based on the combination of the following features it provides:

  • It is a proven, stable, and mature webmail platform.
  • It has been downloaded over two million times.
  • It is standards-based and renders pages in pure HTML 4.0 without requiring the use of JavaScript.

SquirrelMail also includes the following features (and many more, via the flexible plugin system):

  • Strong MIME support
  • Address book functionality
  • A spell checker
  • Support for sending and receiving HTML e-mail
  • Template and theme support
  • Virtual host support

The following screenshot shows an inbox where you can see some of these features:

Linux E-mail: Providing Webmail Access

Linux Email Set up, maintain, and secure a small office email server
Published: November 2009
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

SquirrelMail installation and configuration

SquirrelMail installation and configuration may seem daunting if you are not familiar with installing web applications. But by following the instructions to be discussed next, SquirrelMail can be installed without difficulty.

Prerequisites to installation

SquirrelMail requires both PHP and a web server that supports PHP scripts to be installed before proceeding. In our case, we will be using the Apache2 web server, although others will work as well.

First, we will go over the basic requirements, and what to do if you do not meet them. Then, we will go over some more advanced requirements that may impact on certain features within SquirrelMail.

Basic requirements

At the time of writing, the most current stable version of SquirrelMail available is 1.4.19. The following instructions apply to this version. There are two basic requirements for a SquirrelMail installation.

Installing Apache2

Any modern version of Apache that supports PHP, either the 1.x or 2.x series, will do the trick. Here we provide instructions for using Apache2. To query for an Apache installation on an RPM package management-based system, issue the following command at the prompt:

$ rpm -q apache
apache-1.3.20-16

If, as in the example just seen, a version of Apache is returned, then the Apache web server is installed on your system.

To query for an Apache installation on a Debian package management-based system, issue the following command at the prompt:

$ apt-cache search --installed apache2 | grep HTTP
libapache2-mod-evasive - evasive module to minimize HTTP DoS or brute
force attacks
libpoe-component-server-http-perl - foundation of a POE HTTP Daemon
libserf-0-0 - high-performance asynchronous HTTP client library
libserf-0-0-dbg - high-performance asynchronous HTTP client library
debugging symbols
libserf-0-0-dev - high-performance asynchronous HTTP client library
headers
nanoweb - HTTP server written in PHP
php-auth-http - HTTP authentication
apache2 - Apache HTTP Server metapackage
apache2-doc - Apache HTTP Server documentation
apache2-mpm-event - Apache HTTP Server - event driven model
apache2-mpm-prefork - Apache HTTP Server - traditional non-threaded
model
apache2-mpm-worker - Apache HTTP Server - high speed threaded model
apache2.2-common - Apache HTTP Server common files

Similar commands are available for other distributions using other package management systems.

If you do not have an Apache installation present, it is best to first look into your distribution for a copy of Apache—such as on your operating system installation CDs or using an online package repository. Alternatively, you may visit the home page for the Apache foundation at http://www.apache.org

PHP

The PHP programming language (version 4.1.0 or greater, including all PHP 5 versions) is required in order to install SquirrelMail. To check if your system has PHP installed, simply attempt to run it with the following command:

$ php -v

If the command succeeds, you will see a message describing the version of PHP that is installed. If PHP version 4.1.0 or higher is present, then your system has the required software. Otherwise, you will need to install or upgrade your current installation. As with Apache, it is best to look to your distribution for a copy to install. Alternatively, you may also visit http://www.php.net

Perl

The Perl programming environment is not required for SquirrelMail, but having it available makes configuration of SquirrelMail much simpler. In this article, we assume that you will have Perl accessible to enable easy configuration of SquirrelMail.

To query for a Perl installation on an RPM-based system, simply attempt to run it with the following command:

$ perl -v

If the command succeeds, you will see a message describing the version of Perl that is installed.

If any version of Perl is present, your system has the required software. Otherwise, you will need to install or upgrade your current installation. As with Apache, it is best to look into your distribution for a copy to install. Alternatively, you may also visit http:www.perl.com/get.html

Review configuration

You will need to review the PHP configuration file php.ini to ensure that settings are correct. On most Linux systems, this file may be found at /etc/php.ini.

php.ini is a text file and can be edited with a text editor such as Emacs or vi. Firstly, if you want users to be able to upload attachments, make sure that the option file_uploads is set to On:

; Whether to allow HTTP file uploads.
file_uploads = On

The next option within the php.ini file you may want to change is  upload_max_filesize. This setting applies to uploaded attachments and determines the maximum file size of an uploaded file. It may be helpful to change this to something reasonable, such as 10M.

; Maximum allowed size for uploaded files.
upload_max_filesize = 10M

>> Continue Reading Linux E-mail: Providing Webmail Access (Part 2)

If you have read this article you may be interested to view :

About the Author :


Alistair McDonald

Alistair McDonald is a freelance IT consultant based in the UK. He has worked in IT for over 15 years and specializes in C++ and Perl development and IT infrastructure management. He is a strong advocate of open source, and has strong cross-platform skills. He prefers vim over vi, emacs over Xemacs or vim, and bash over ksh or csh.

He is very much a family man and spends as much time as possible with his family enjoying life.

Books From Packt

ModSecurity 2.5
ModSecurity 2.5

FreePBX 2.5 Powerful Telephony Solutions
FreePBX 2.5 Powerful Telephony Solutions

Asterisk 1.4 – the Professional’s Guide
Asterisk 1.4 – the Professional’s Guide

trixbox CE 2.6
trixbox CE 2.6

Cacti 0.8 Network Monitoring
Cacti 0.8 Network Monitoring

Tomcat 6 Developer's Guide
Tomcat 6 Developer's Guide

Apache Maven 2 Effective Implementation
Apache Maven 2 Effective Implementation

Drools JBoss Rules 5.0 Developer's Guide
Drools JBoss Rules 5.0 Developer's Guide

Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software