In my attempt to fix the same problem, I have come across the following that might be of help to someone that knows more...

1. If I select "none" under ISPConfig => Sites => Auto-Subdomain then I can access the webmail under www.mydomain.com/webmail but it asks to either save or download the login.php under mydomain.com/webmail

2. Any other setting under Auto-Subdomain will result in not being able to use the webmail, UNLESS I try mydomain.com:8080/webmail or www.mydomain.com:8080/webmail

I guess an easy "fix" would be to go with Auto-Subdomain=none and redirect traffic from the non www to the www domain...

b.) The tutorial is inaccurate if ISPConfig's default PHP mode, Fast-CGI, is selected.

c.) The fact that PHP configuration directives (open_basedir, where this tutorial is concerned) must be placed in different locations depending on the selected PHP mode.

d.) It is unnecessary to add the SquirrelMail directories to the open_basedir directives when using ISPConfig's default PHP mode, Fast-CGI, so that step of the tutorial is superfluous unless using CGI mode.

e.) In ISPConfig, the "PHP open_basedir" field length is limited, although there is no mention of this fact. As such, some portion of the value in that field may be truncated without warning. One way around this bug is to use Mod-PHP, in which case the open_basedir directive is specified in the Apache Directives box, which does not suffer from the same length limit.

f.) The tutorial fails to mention two additional directories that should be added to the open_basedir directive's value. The full list should be:

Code:

/usr/share/squirrelmail:/etc/squirrelmail:/etc/mailname:/etc/hostname

The problem with Apache sending the actual binary file "index.php" to the browser has to do with an incompatibility with the default SquirrelMail configuration and Apache's SuPHP module, which as mentes already suggested, can be disabled:

With suPHP disabled, the SquirrelMail index page (index.php) is parsed properly and the login screen is accessible.

Basically, SquirrelMail should work if:

a.) PHP mode is CGI and the necessary directories are added to "PHP open_basedir" field in Sites -> Website -> example.com -> Options [tab], as described in the tutorial. (Even if suphp module is enabled, it is ignored in CGI mode.)

b.) PHP mode is Fast-CGI and the suphp Apache module is disabled. (Disabling this module prevents "index.php" from being sent to the browser as a file download. It should be noted that Apache can be configured to enable SquirrelMail to function with SuPHP enabled, if desired.)

c.) PHP mode is Mod-PHP and the necessary open_basedir directories are added to the "Apache Directives" field in Sites -> Website -> example.com -> Options [tab]. How this directive is defined depends on the Apache configuration. An example might be:

If the appropriate directories are not added to PHP's open_basedir configuration directive, the SquirrelMail index page will state:

Code:

ERROR: Config file "config/config.php" not found. You need to configure SquirrelMail before you can use it.

The Apache logs will state (among other open_basedir errors):

Code:

PHP Warning: file_exists(): open_basedir restriction in effect. File(config/config.php) is not within the allowed path(s): (/current/open_basedir/path) in /usr/share/squirrelmail/index.php on line 15

The bottom line is that to configure SquirrelMail properly, it is important to understand that ISPConfig offers several different modes of operation for Apache: FastCGI, CGI, Mod-PHP, and suPHP. Each mode has different configuration requirements.

At this point, it seems prudent to address the root cause of the problem with the SquirrelMail index.php file being presented to the user-agent as a download.

From what I gather, somewhere in the Apache configuration files, suphp is being disabled for the SquirrelMail directory, which is fine. The problem is that a PHP handler is not registered subsequently, so Apache makes no attempt to parse PHP files and instead presents them to the browser as binary attachments.

I should add that this same issue likely affects phpMyAdmin installations, because a) its files are stored outside of Apache's Document Root in some Linux distributions (e.g., in /usr/share/phpmyadmin), and b) PMA is presumably exempted from suphp restrictions (but, again, no PHP handler is registered subsequently).

There are two solutions to this problem.

First, the "quick-and-dirty" solution: disable the suphp module for the SquirrelMail directory (even if it's already disabled) and add a proper PHP handler:

The second solution is to configure suphp "properly". The first step is to re-enable suphp for the SquirrelMail directory, since it's being disabled somewhere (which could be in SquirrelMail's .conf file, an ISPConfig file... I haven't looked):

Which tutorial did you use to install your server? If you follow the perfects etup to the letter, squirrelmail will work out of the box. The most likely reason for your problem is that you missed to install the apache mod_php package as described in the ispconfig perfect server guides.