Quality code and lots of coffee

Tag: postfix

Server Architecture

Building an application is only part of the process; a platform to run your code on is just as important to know about. Environmental differences can cause unexpected bugs in your code and having a knowledge of of server architectures can be a vital asset to your tech stack. Servers need to perform a range of tasks, including manage domains and user groups, permissions, and run your applications – ultimately to provide a service to you.  These services can include web services like IIS or Apache, Databases such as SQL Server or MySQL, email services like Exchange or Postfix/Dovecot.

As well as having an in depth knowledge of desktop operating systems Windows XP – Windows 10, and Linux environments such as Ubuntu, Fedora and OpenSuse I have an extensive knowledge in both Unix and Windows Server. Windows server as always provides the advantage of managing everything through a GUI, giving your server management a little bit of ease, and being able to run some development tools natively is always a bonus.

Running a Unix server by comparison is a lot more hands on, but provides much greater flexibility when it comes to server architecture (As well as having the bonus of being free), and with the new territory of .Net Core Unix is becoming a more viable option in businesses. I am familiar with most Debian and Redhat bases systems – in fact this website is running on a CentOS system running in the cloud.

It is one thing to know that these services are available to you, but understanding the alternatives on both platforms, as well as how to set up and use these platforms is a valuable skill.

Hosting Webmail for Multiple Domains

The hosting business I run on the side to my actual job has the odd client wanting their own mailing system. I set up a postfix/dovecot system on our VM not too long ago and it’s been slowly building up into an actual workable system. We have had some issues regarding a PHP exploit and some spam but that’s an ongoing pain in the arse and another story altogether.

One of the obvious problems with hosting your own mail server is; how do people actually see their mail? We offer IMAP and SMTP support so they can plug in their own clients but what if they want an actual interface? Well there are a number of pre-made solutions, which are just websites which hook into your internal (or remote) mailing system. We decided to go with Roundcube, comes with its own online installer, needs MySQL and some extra PHP functions but it’s well documented and the install process is fairly easy – we set up roundcube for 3 systems, including myself.

The problem came when I tried to set up roundcube for our 4th client, I realised that fundamentally there was no difference in terms of the backend, despite using their own URLs they all resolve to the same location and the site itself was identical, save for 1 or two configs. They were also all using individual databases (belonging to their sites) and it dawned on me that I had the same table setups across 4 databases for no particular reason…

I decided to downsize and force everybody to use the same client. I started with a new setup of Roundcube and made backups of the data (not the schema/table structure) from every clients individual database and compiled into one script. The user ID’s need to be manually amended (obviously each domains users started from 1) but thankfully in total we had about 11 users so it wasn’t difficult to go down the list and change the ID’s.

Since we use virtualhosts on our sites, and I wanted to enable the mail portal for every site, the easiest thing to do was create an Alias file. An Alias will redirect any traffic for a particular argument to a specified destination. For example, I wanted every site with a /Mail url to navigate to our the new Roundcube installation. So I created the following file

nano /etc/httpd/conf.d/Mail.conf
$

Alias /newmail /var/www/Mail
Alias /Mail /var/www/Mail
Alias /mail /var/www/Mail
#EOF

service httpd restart

This enabled any site we host to be redirected to the roundcube installation whenever they used any of the alias’ specified. for example http://mycustomdomain.com/Mail

Then it was just a matter of making the configs unique. The easiest way to do this that I’ve found is to use PHP’s $_SERVER attribute to detect basic information like which URL has been used to access the site, then to use this information to assign values in the config. You can set Roundcube to pass in the Username and Password from the logged in user for SMTP auth when they try to send, and by default they try to login via IMAP so users are properly authenticated. As I said before you can use PHP to detect the URL which is being used to access the page, so in the config file itself you can just set a number of parameters into an array, then load these in while the config is being read. As in the code below taken from my config.inc.php file in the Roundcube Config directory

//Now some fancy scripting to set the logo based on the domain viewing the page
$CustomerArray= array();
$CustomerArray[] = array("domain" => "vandebilt.co", "logo" => "http://vandebilt.co/Archive/images/joelogowhite.png");
$CustomerArray[] = array("domain" => "anotherdomain.co.uk", "logo" => "http://anotherdomain.co.uk/logo-250.png");

for ($i = 0; $i < COUNT($CustomerArray); $i++)
{
    //If the URL being used to view the site contains the domain name
    if (strpos($_SERVER["SERVER_NAME"],$CustomerArray[$i]["domain"]) !== false)
    {
        $config['skin_logo'] = $CustomerArray[$i]["logo"];
        $config['product_name'] = $CustomerArray[$i]["domain"] . ' Webmail';
    }
}

You can expand the array to hold as many config items as you like per domain, then during the loop load them in as the site parameters. So if I were to access the site vandebilt.co/Mail I would see my own logo, then if I were to access anotherdomain.co.uk/Mail, I would see their logo. This gives the users the impression that they have their own webmail portal, but it is in fact just the same site with some very basic config hacks to make it seem like their own. This lets us downsize on server space, share plugin configurations, only need to debug one site and ultimately support it better.

Roundcube Webmail Client

© 2025 Joe van de Bilt

Theme by Anders NorenUp ↑