Integrating SquirrelMail with AXIGEN
Abstract
This document aims to explain how to install and configure SquirrelMail on a machine to act as a webmail interface for AXIGEN. It also focuses on what would be the best choice as a webmail interface in different scenarios.
In the following section the two implementations are compared to help administrators decide whether they want to keep AXIGEN WebMail or set up SquirrelMail.
AXIGEN WebMail pros: | AXIGEN WebMail cons: |
- No need to setup a web server. - Independent of IMAP and POP3. - Minimal configuration required. - Advanced skinning and layout support. |
- No support for text web browsers. - Hard to implement in an already existing site. |
SquirrelMail pros: | SquirrelMail cons: |
- Support for text web browsers. - No JavaScript support required. - Easy integration into an already existing site. - Advanced skinning support. |
- A separate web server must be set up. - Moderate configuration required. - Low error control and tracing possibilities. - IMAP must be enabled. |
As a side note, you can choose not to use only one of them. Both webmail interfaces can be run at the same time on the same machine without any interference from one another.
SquirrelMail Installation
To set up SquirrelMail the following elements are required:
- A PHP enabled web server (Apache 1.3/Apache 2.0 are commonly used).
- PHP version 4.1.2 or higher.
- Perl installed and running for the initial configuration.
First you need to download the tar-ball from the SquirrelMail website and save it on the machine that runs the web server. After this step is completed, copy the contents of the archive into a folder named "webmail" and place this folder in the site root.
It is very important to make sure that the contents of this folder are accessible by the user running the web server. The Apache software uses "www-data" by default as the user. Permissions on the contents of the "webmail" folder must give read and write access to this user. Failing to do so will generate access errors while logging into the webmail interface.
At this point, the login screen should be accessible in a web browser using the base address followed by the name of the folder, in this case "webmail" (http://www.mysite.org/webmail). If this page is not accessible at all and you get an error you probably have encountered an issue related to access rights. Go back to the previous steps and make sure that everything is configured accordingly and retry.
SquirrelMail Configuration
Before logging into the webmail interface, it needs to be set up. The setup procedure depends on the particular setup a company uses. To start this procedure run the "configure" script found in the "webmail" folder.
While configuring SquirrelMail you have to make sure you specify the correct options for the current setup on your AXIGEN Mail Server. The server address for SMTP and IMAP should be set, and port numbers should match those of the respective listeners defined in the AXIGEN configuration. The authentication type is also very important and should never be overlooked. An important note here would be SquirrelMail's inability to automatically detect the supported authentication types of the AXIGEN Mail Server. This does not however prevent SquirrelMail from correctly connecting while using any of the available authentication methods.
If you do not have Perl installed or for some reason you cannot run the configuration script, all the changes must be made by editing the configuration file, before logging in for the first time.
SquirelMail acts as an IMAP client and connects to the AXIGEN Mail Server through this protocol to access e-mail messages. For as long as the web server and AXIGEN are running and the configuration is correct you will not encounter any issues.
Different set-up configurations for AXIGEN WebMail
The main reason one would prefer to have the SquirrelMail interface is its easy integration process with an already running site. This section of the article aims to explain how the AXIGEN WebMail interface can be run along side a web server.
The simplest solution is to have AXIGEN set up on a different machine. This is the best practice recommended for general use. Having multiple business-critical elements on one machine can be unfortunate in the event of that machine becoming compromised.
In some cases however, this approach is not possible. An alternative is to run the AXIGEN WebMail interface on a different port than 80, but this is very uncomfortable at times for end-users.
Also, in case a pool of yet unassigned IP addresses is at hand, a multiple interface scenario can be used. Having the web server bind to one address on port 80 and WebMail or another interface on port 80 also solves the issue. Of course, multiple network adapters are mandatory in this case and virtual interfaces can be used.
Merging the code of the parent site into the WebMail interface is also possible, though it requires heavy modifications and can generate many issues if done incorrectly. This is actually the best method of all, but requires the most resources and can be very time consuming, depending on the complexity of the site. Some experience and a good understanding of HTML and HSP are required to succeed.
Conclusion
Choosing the right tools for a specific environment can be a challenging task. Depending on what is required and the resources assigned, the network administrator should decide the best action to take. Both webmail implementations converge to the same purpose but take different paths in achieving this. Perhaps having them both set up and running would be an "all win" scenario in this dispute.