We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
Cannot Receive Emails and Can Only Sometimes Send Emails
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
Don't know how I completely missed this post of yours. I'm curious to know if you resolved your Mail problem yet or not ?
-
- Posts: 43
- Joined: Tue Apr 18, 2017 10:54 pm
- Os: Ubuntu 15x
- Web: apache + nginx
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
I was actually on my way back to mark it solved. While my issue wasn't solved, I will still detail out what I have done for documentation purposes in the case that this is a Bug or issue within EXIM or VestaCP. These are by no means a "scientific" way of replicating the results, however I will attempt to walk through everything I have done thusfar, as well as for my conclusion.mehargags wrote:Don't know how I completely missed this post of yours. I'm curious to know if you resolved your Mail problem yet or not ?
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!
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
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!
Code: Select all
apt 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
Code: Select all
apt install nano curl git wget zip gzip -y && apt clean && apt autoremove -y && apt clean && curl -O http://vestacp.com/pub/vst-install.sh
Code: Select all
apt 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 [email protected] --password password --force
Code: Select all
wget -O /usr/local/bin/gdrive https://docs.google.com/uc?id=0B3X9GlR6EmbnQ0FtZmJJUXEyRTA&export=download && apt autoremove && apt clean && chmod +x /usr/local/bin/gdrive && gdrive list
Code: Select all
reboot now
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:
Code: Select all
nano /etc/cron.daily/vesta_ssl
Code: Select all
#!/bin/bash
cert_src="/home/admin/conf/web/ssl.subdomain.domain.com.pem"
key_src="/home/admin/conf/web/ssl.subdomain.domain.com.key"
cert_dst="/usr/local/vesta/ssl/certificate.crt"
key_dst="/usr/local/vesta/ssl/certificate.key"
if ! cmp -s $cert_dst $cert_src
then
# 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
fi
Code: Select all
chmod +x /etc/cron.daily/vesta_ssl
Code: Select all
run-parts /etc/cron.daily
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.
-
- Support team
- Posts: 1096
- Joined: Sat Sep 06, 2014 9:58 pm
- Contact:
- Os: Debian 8x
- Web: apache + nginx
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
It is not a bad decision to move mail to an Email service provider, many of us seasoned sysadmins know how painfully mysterious and time consuming it can be to maintain mail server. The stricter and tighter SPAM policies based on domain and IP reputation make it harder to make through the inbox today!! So Many sysadmins would move mailing to email specific service.
Yandex is not grey or shady as such, it works well for many of my customers... yes being Russian it may be held sceptical by American customers yet I don't find it a problem in general operation. Zoho is also a good free service though they now tie your account with a mobile phone number to counter unsolicited abuse of their free domain signups.
Good luck...!
Yandex is not grey or shady as such, it works well for many of my customers... yes being Russian it may be held sceptical by American customers yet I don't find it a problem in general operation. Zoho is also a good free service though they now tie your account with a mobile phone number to counter unsolicited abuse of their free domain signups.
Good luck...!
-
- Posts: 43
- Joined: Tue Apr 18, 2017 10:54 pm
- Os: Ubuntu 15x
- Web: apache + nginx
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
Yeah, I wish I would have realized how hard it was from the start. I have heard that Yandex was shady because of what they do with the data they get. While being Russian to many of us Americans will raise red flags, I have had no issues and as far as I know, isn't Vesta Russian-made? Unsolicitation is always good in my books.mehargags wrote:It is not a bad decision to move mail to an Email service provider, many of us seasoned sysadmins know how painfully mysterious and time consuming it can be to maintain mail server. The stricter and tighter SPAM policies based on domain and IP reputation make it harder to make through the inbox today!! So Many sysadmins would move mailing to email specific service.
Yandex is not grey or shady as such, it works well for many of my customers... yes being Russian it may be held sceptical by American customers yet I don't find it a problem in general operation. Zoho is also a good free service though they now tie your account with a mobile phone number to counter unsolicited abuse of their free domain signups.
Good luck...!
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
BTW did you double check if the ports for SMTP (25,465,587,2525), IMAP (143,993) and POP3 (110,995) are open in the firewall?
I remember when first time setting up Vesta I had a problem with this.
I remember when first time setting up Vesta I had a problem with this.
Re: Cannot Receive Emails and Can Only Sometimes Send Emails
This problem has been solved. Just replace the file
https://www.handbook.ltd/en/bbs/vestacp ... estacp/466
https://www.handbook.ltd/en/bbs/vestacp ... estacp/466