I have a single instance of Squirrelmail installed on the server, which is being run via fcgi from Apache using suexec, and mostly working except for finding a solution for ssl access to it. First, let me explain how I have it setup...
Squirrelmail is not installed under one of the domains, but rather setup as a single instance on the server. The Squirelmail <Directory> directives are in the httpd.conf file, independent of any particular <VirtualHost>. At first, this seemed to work and I initially attempted to use an Alias directive to get this to work for all virtual domains...
Alias /webmail /usr/local/www/squirrelmail
Unfortunately, when a url such as www.example.com/webmail was used, since it was running as the user for example.com via suexec, there were rights issues. It's too bad the SuExecUserGroup directive in Apache can only be used in a <VirtualHost> section, not a <Directory> section. If it could, a special user/group could have been created to run Squirrelmail under with the correct file permissions.
The simplest solution I've come up with was to create a subdomain specifically for Squirrelmail. The webmail.mydomain.com subdomain uses /usr/local/www/squirrelmail as it's document root, and seems to work well. Privilege problems seem to be resolved.
My questions...
I'm open to suggestions, and would like to know if anyone sees any potential problems with such a configuration? Does anyone have a better approach they'd recommend?
To get access to Squirrelmail under SSL, I cannot use the certificate issued for my main server, as the domains don't match (webmail.mydomain.com vs. secure.mydomain.com). I could get a dedicated certificate just for Squirrelmail, but that seems like overkill. Perhaps using a proxypass/proxyreverse might work here, but I'm not so sure. Again, I'm open to suggestions.
What I did was:
Setup Squirrelmail under secure.example.com/squirrelmail/
Setup webmail.ALL_DOMAINS.com to redirect to https://secure.example.com/squirrelmail/
At that point, it's a pretty simple setup, all your users can use it, and no one gets the SSL warnings.
Also, if you're using Virtualmin Pro, you can use the Install Scripts provided to manage the Squirrelmail install. But even if you have the GPL version, the above is a simple setup.
-Eric
That is a possible solution, but it still presents 2 problems:
(1) It eliminates non-SSL access to squirrelmail. In theory, it would be better for all squirrelmail access to be via SSL, but I'm not so sure that there wouldn't be times when non-SSL access is needed.
(2) It will result in suexec privilege issues. I'd either have to configure the secure.mydomain.com virtualhost to not use suexec (i.e. no SuexecUserGroup directive), which I'd have to carefully think about any security implications this brings up, or all Squirremail files/dirs would have to be owned by the user/group for secure.mydomain.com, which again might result in non-SSL access issues.
As far as using a redirect such as webmail.domain.com, my clients are all used to my old system where domain.com/webmail was used, so I'd should just as easily be able to do such a redirect instead. And, yes, it would be fairly straight forward to do with the GPL version of Virtualmin and a bit easier with Pro (which I'm running), but just as easy (IMHO) to install out of the FreeBSD ports collection.
Well, let's add another layer to my suggestion :-)
What if you:
Added example.com as a Virtual Server
Added secure.example.com as an Alias to the above
(so, these both share the same DocumentRoot now)
Install Squirrelmail into $HOME/public_html/squirrelmail/
Install an SSL cert into secure.example.com
Now, you could use either http://example.com/squirrelmail/, or https://secure.example.com/squirrelmail/, to access your webmail client.
The suexec bit should be fairly sane for you, as whether they're using http or https, it's all done under the same Virtual Server owner's ID.
That does sound like it could do the trick for you?
-Eric
Yeah, that's basically what I wound up doing...
What if you: 1. Added example.com as a Virtual Server 2. Added secure.example.com as an Alias to the above (so, these both share the same DocumentRoot now)
That's how my main domain is already setup, and is already working well.
3. Install Squirrelmail into $HOME/public_html/squirrelmail/
Well, I'm using "webmail" as the directory and it's a symbolic link to the actual squirrelmail directory, but it's the same general idea.
4. Install an SSL cert into secure.example.com
Was already done when secure.example.com was setup; it's also working well.
A few other steps are necessary...
5. change owner/group of the squirrelmail files to the owner/group for example.com (because I installed squirrelmail from the FreeBSD ports collection and had set the owner/group to www:www, which suexec wouldn't really like all that much)
6. Made sure the default redirect was from /mail to http://www.example.com/webmail (can't use /webmail as it would put us in an endless loop!)
Seems to work okay. Shouldn't be creating any security problems, and allows both SSL and non-SSL access. If my clients can't remember to use /mail instead of /webmail, I can always change the actual path to something like www.example.com/wm and add /webmail as an additional alias, but I'll wait on that.
The only downside is that all access to webmail is through my site and that means the logs, error logs, statistics, etc will be filled with all webmail activity as well as site activity. Not a really big deal, but it would be nicer to keep it separate. I don't see any means of doing that in Apache anyway, not without using a separate <virtualhost> section. Too bad the ErrorLog and CustomLog directives can't be used in a <directory> section.