One of the most annoying aspects of running VMs is managing email services. Issues include: Constant fight with spam (and then with angry clients) Frequent high loads Security concerns Complex configuration I do have extensive firewall rules on my VMs that mitigate a lot of unwanted traffic. But, I find that I still constantly dislike having to run email as a service. Frankly, I am now advising clients to use Microsoft Office 365 or Google Workspace or comparable services for email services, while continuing to use ISPConfig for everything else. I do have some clients that don't want to do this, so I am still offering email services, but now think that I need to host those email services on a VM that is separate from the web and database services. Given the desire to follow "Separation of Concerns" best practices, I'm wondering how this is best done with ISPConfig. For the problem at hand, I'm considering installing ISPConfig on two VMs that separate website traffic from mail traffic. For example, having the domains: sites-1.hosting.com - authoritative for DNS and everything except for email. Note the MX records for domains point externally. Postfix, dovecot, and other mail services are disabled on this VM. There can be many VMs like this that allow for either exclusive use of a VM or shared VM use by clients. [Side topic: Is there a way to migrate client accounts (sites, databases, etc.) between these VMs?] mail.hosting.com - cloned the sites.hosting.com VM, but enabled mail services. My customers that use commercial-grade mail services from Microsoft, Google, or others only need to login to the sites.hosting.com to manage their account. My customers that need me to provide email services will have to manage two separate logins for each of the above two VMs. This is not an elegant solution, but it will work and will eventually allow me to no longer offer email services. That being said, I'm hoping that there are other solutions that you can share that I haven't thought of or that ISPConfig can natively handle. All suggestions are welcomed.
For larger installations, you should always have separate servers or virtual machines for services like web, mail, and DNS. Using ISPConfig, you can have multiple systems of each type, so your installation can easily scale to hundreds of servers all managed from one central ISPConfig control panel. See ISPConfig multiserver tutorials on how to set up such systems.
Good point. I also stopped setting up and maintaining ISPConfig email servers since almost 6 years ago. I am using Google Workspace instead. About the separation, I thought that is possible, but when I read again, you have two separate ISPConfig setups that are not a multi server setup, which makes it difficult, a bit. What I would do is extend either one of the ISPConfig servers, preferably the mail server, to a bigger setup, or create a new ISPConfig multi server setup and then migrate to them.
I did not specifically mention this point, but with an ISPConfig multiserver setup, your users have a single login and a single point to log in for all services, no matter how many servers you have. So, it's the same as with any other commercial-grade setup. For a new larger setup that shall be able to grow, I recommend having a separate server (VM) for the control panel GUI and then running all other nodes like web DNS, email, and database nodes as slave nodes connected to this master GUI node. While you can have separate database nodes for website databases in ISPConfig, it's often better to have web and database on the same node as network latencies play a big role when it comes to database-backed web applications, so they will benefit from connecting to a local database speed-wise.
i can recommend @till's suggestion. been running ispconfig gui, and our own company websites on it's own vps, with separate ispconfig vps servers for dns, email, and customer webservers. i did, when first starting on ispconfig, try using a multiserver configuration with a central db server for the clients databases, was on AWS.. with nice chunky bandwidth between the webservers and the db server, but even the low latency between them made wordpress sites way slower than they should be.. keeping the client websites and databases on the same server is definitely a much faster setup. and yes.. managing email servers is a bloody pain.. but so is trying to get a website authorised to send mail through gmail these days.. if you're going to experience the pain anyway, might as well host the clients email yourself and charge them for it.
