I Wasted 5 Days of my Life [VestaCP Problems]

So below is a word-for word report I did over on the VestaCP (a web control panel alternative to Plesk or cPanel) forums, enjoy!

TL;DR (in four paragraphs):

I actually just moved my emails to Yandex because, while shady, they are more reliable and hosted so I don’t have to worry about DKIM and all that BS. I never solved my issue (detailed within) however, I mostly gave up having less than 30 days to re-activate both mine, and my clients services.

I don’t get paid or anything and if you want to stray away from them, but still have a top-level domain (.com, co, .co.uk, etc.) you can try Zoho mail, which offers 25 free mail accounts per domain (one domain per account). The former, Yandex, offers nearly unlimited mailboxes (1k before needing to message support) per domain and I have all my domains over there right now with no issues.

Both have CNAME DNS verification so you don’t need to worry about “handing over your keys” to your domain. Just point it to their MX servers and have a CNAME for verification and you are golden.

Again: I do not get paid or benefit in any way by you using these services, I am simply offering an alternative which may solve your problem!


Users on servers are unable to receive email from outside sources (this includes forwarded mail), however users are able to send mail using the built-in Roundcube Installation. A clean installation did NOT fix this issue, however instead it made the issue more intermittent.

Steps Taken to Solve Problem (Summary of entire post)

  • Check for Hostname Resolution = Works Perfect (even though at the time the rDNS wasn’t set up, with the rDNS enabled properly it doesn’t help)
  • Check spam setting for Spamassassin = VESTA defaults to 50 (fifty) instead of the recommended 5.0 (five-point-zero) [Recommend Fix], changed to 5.0 with no change, commented out the lines with no change, stopped the Spamassassin services (crashed the system), and disabled the email spam check (created a very unstable environment, however some emails would be able to get through).
  • Check mxToolBox for any issues = Found blacklisted on two minor lists, messaged, however doubt they will be removed or are effecting email delivery to the server.
  • Tried to create new run directory for clamav and then chown clam to directory = “mkdir: cannot create directory ‘/var/run/clamav/’: File exists”; “chown: invalid user: ‘clam:clam'”
  • Checked if Exim was listening on proper ports = Yes it was, only IPv4 (25 and 2525)
  • Checked if Postfix was installed, causing a conflict = It was, but was removed prior to installation of VestaCP
  • Checked if Exim was resolving hostnames = It resolves to gmail.com with no issues
  • Changed the Exim DNSLookup section to be “domains = *” = No change
  • Checked, triple checked, and then checked again my DNS = All set properly
  • Checked with my host about rDNS and Ports = rDNS now set; ports managed solely by user
  • Clean installation with below process does nothing different, minus the unreliable results of sometimes receiving and sometimes not

Installation Settings and Steps

NOTE: All tests were done on live servers with real user data and files, for this reason domain names have been simplified, hidden, or otherwise changed for protection of the users. This is also the same for the passwords.

NOTE 2: All tests were done on similar Ubuntu x64 (16.04LTS) machines with the latest kernels and updates (as shown below). The installs were custom-made (host-made) templates running on a OpenVZ platform with a SolusVM management software hosted by QuadraNet in Miami, FL, USA.

NOTE 3: All code is FOLLOWED (underneath it) by a description!


update && sed -i '$a ClientAliveInterval 120'
/etc/ssh/sshd_config && sed -i '$a ClientAliveCountMax 720'
/etc/ssh/sshd_config && systemctl restart ssh && apt
remove mysql-server apache2 postfix clamav dovecot exim postfix -y
&& apt autoremove -y && apt clean && apt
dist-upgrade -y

These lines of commands updates the Aptitude using the shorter command “apt”; removes timeout from SSH, then restarts the SSH services; removes pre-installed mysql-server, apache2, postfix, clamav, dovecot, exim, postfix and forces yes on all questions and then it removes all leftover dependencies left from the cluttered install and cleans the aptitude database; finally we do a force-yes update to the entire system.


install nano curl git wget zip gzip -y && apt clean &&
apt autoremove -y && apt clean && curl -O

These next lines of commands install various programs I find useful in my work and gets the latest VestaCP installation as per the instructions.


clean && bash vst-install.sh --nginx yes --apache yes --phpfpm
no --named yes --remi yes --vsftpd yes --proftpd no --iptables yes
--fail2ban yes --quota no --exim yes --dovecot yes --spamassassin yes
--clamav yes --mysql yes --postgresql no --hostname subdomain.domain.com
--email user@domain.com --password password --force

This line of code cleans Aptitude, again, and starts the Vesta installer, forcing the installation to overwrite any and all files/programs after saving them to the ~/vst-backup/ directory. Again, domains, emails, and passwords are changed for security.


-O /usr/local/bin/gdrive
&& apt autoremove && apt clean && chmod +x
/usr/local/bin/gdrive && gdrive list

This second-to-last line of code then downloads the gdrive program, cleans Aptitude, autoremoves, chmods the downloaded program, and then activates the aforementioned gdrive.


reboot now

Finally (in the installation portion) I reboot the system for good measure (I know, smack my hand, servers should never be rebooted, but sometimes it’s the easiest way to trigger the on-boot enable functions.

Post-Installation Steps

NOTE: Same notes from above will apply here

After installation, I go into the panel and select, enable, and generate the Let’s Encrypt for the panel domain, then I head back into the terminal:


nano /etc/cron.daily/vesta_ssl





if ! cmp -s $cert_dst $cert_src
# Copy Certificate
cp $cert_src $cert_dst

# Copy Keyfile
cp $key_src $key_dst

# Change Permission
chown root:mail $cert_dst
chown root:mail $key_dst

# Restart Services
service vesta restart &> /dev/null
service exim4 restart &> /dev/null

Save and exit the file (CTRL+O & CTRL+X) then,


chmod +x /etc/cron.daily/vesta_ssl


run-parts /etc/cron.daily

Then I refresh the panel with the whole system secured with the Let’s Encrypt SSL Cert and begin to create/modify users and their websites.

In Summary

In short and long: I have no idea what went wrong, but as I mentioned above I have simply went with Yandex to get my emails settled. I don’t know the cause of the problem and users in GitHub insist that this is either a system-based issue (and therefore not Vesta’s problem) or an EXIM problem (again, not Vesta’s Problem).

To save yourself some.. No.. A LOT of headaches, use a hosted mail solution. There’s hundreds out there for free and you can easily hand the keys over to any user you are working for with little problems. Both services mentioned at the start of this report require a phone number for verification (new legal policies, and yes, you have to – although VOIP is sometimes an option).

I seem to have grown about 50 years older in just the five days since this all started, however I hope this (hopefully) detailed report can help mods and admins better the program if it is a program fault, or help users stray from the headache that is self-hosted emails.

Signing off,
Joseph Stacklin


Disclaimers: I do not get paid for by VestaCP; Yandex, International; Zoho Corporation; Canonical; Ubuntu; Let’s Encrypt; Domain.COM; EXIM; or any other listed product(s) in this report. All names are copyright protected by their various owners and I claim no rights over them. Any tests done were done with the knowledge that the software is provided “AS-IS” with no warranty under pursuant with Open-Sourced License titled “GNU General Public License v3.0” (more commonly referred to as “GPLv3”). Should you wish to try to replicate these tests, I claim no responsibility and will not be held liable for (but not exclusive to): loss of data, damaged hardware, or hair falling out (or if you you ripped it out). YOU DO THESE THINGS AT YOUR OWN RISK AND BY DOING THEM ACCEPT THE RISKS THAT MAY OCCUR.

Leave a Reply

Your email address will not be published. Required fields are marked *