I switched my server from Debian 8 to CentOS 7 and reinstalled Virtualmin.
I successfully created a top-level virtual server and can see the web page for it. At this time I’m only using this server as a nameserver, so I didn’t set up any e-mail for it.
I successfully created another virtual server which is a sub-server of the first server. I intend to use this server for a website and tried to set up an e-mail address for it. I created a user. When creating this user I only entered information in the Email address, Real name and Password fields. I didn’t enter anything else or alter any settings.
I tried sending e-mail to this address but never received it in Usermin. Also in Usermin, I tried sending e-mail from this user, but got an error: “Failed to send mail : SMTP command failed : ”.
I then created a user in the top-level virtual server to see if e-mail worked in it, but I got the same result.
What should I do?
Make sure you're entering the actual user name, and not just the prefix; look at the Edit Users page for the domain in question, and make sure you're using the login name found in the IMAP/POP3/FTP Login field. It'll usually be "name.domain", but that is configurable...Virtualmin supports a variety of name formats, but that's the default. (Usermin will accept either name...the prefix or the prefix.domain, because it knows the domain based on what is in the URL bar, but SMTP doesn't know anything about what domain it has been contacted on).
That said, something else seems to be wrong in the Usermin send mail test. That's a weird one.
--
Check out the forum guidelines!
I am having this same issue. I've logged in using just the username and user.domain. Getting same error as OP...
Failed to send mail : SMTP command failed :
Another issue is I disabled SSL at Webmin Configuration and I can access non-SSL VirtualMin but when I logged into Usermin, it's prompting me to access via SSL? Not sure what's going here, figured making that change would effect all globally....
Hi Folks,
I believe the issue is with the "new" installer. Something is definitely not working with it.
After over 6 hours of attempting to resolve issues with email after installing with the latest Virtualmin GPL installer, I was about to throw in the towel.
So, I dug up a copy of the 1.1.5 installer I had previously used successfully, and fired it up as a last resort. After completing the same post-install steps used with the "new" installer, everything worked PERFECTLY!
I have filed an issue with the team to have this matter investigated further. If you require a copy of the older installer, please ask Joe, Jamie or even I am happy to make it available once again until this matter is resolved.
Cheers!
Best Regards,Peter Knowles | TPN Solutions
Email: pknowles@tpnsolutions.com | Skype: tpnassist
Run the following:
# yum install cyrus-sasl-plainTest again. Give me some maillog output if there are still problems. I'm testing on my own VM at the moment, and this resolved the most immediate problem. Log data will help solve any other problems.
--
Check out the forum guidelines!
This is fixed in the latest yum groups lists in the repos...I believe it'll automatically install one your next yum update.
--
Check out the forum guidelines!
Oh, you'll have to do that yum update from the command line; Virtualmin runs check-update and the individually installs the packages, which will skip dependency changing actions. But a yum update from the command line will definitely pick up the new package. You probably want to do one of those to upgrade to CentOS 7.4 anyway.
--
Check out the forum guidelines!
I have been having this problem with the VM v6.x installer on a fresh Centos 7.4 VPS server. The installation appeared to go without any errors except that the VPS provider does not have the Quotas function enabled for VPS users. There were some other minor bugs but it looks like these have been or are soon to be addressed. The Postfix and Dovecot servers were installed and running. Evaluation of those looked like there were no configuration problems. However, when a Virtual Server was installed and users added, those accounts could not send or receive email. A check of DNSStuff and other DNS-network tests showed that SMTP port 25 was not responding. I spent hours trying to figure out what was causing what appeared to be blocking the port starting with contacting the VPS provider who responded that port 25 and other SMTP ports were open. And I checked the firewall/iptables to make sure it was not blocking. All of that checked out but the DNSStuff continued to show it was not getting through to port 25.
For the new install: A check of Virtualmin>Logs and Reports>Check Connectivity throws this error report: External Connectivity Check In domain your.com
Testing external connectivity .. .. the following problems were found : Problem type Error message Possible solution SMTP connection timed out Failed to connect in 60 seconds Check if your system's firewall is blocking port 25. ~~~ However, this server does not have iptables/firewalld or any other firewall running. VM was installed last Friday, Sept 15 using the latest VM 6.x pro with the LEMP stack option.
This is puzzling because, knock on wood, I am able to send to and from the email accounts and the DNSStuff and other tests show that SMTP is setup and responding to queries.
It looks like the latest Virtualmin install of the NGINX LEMP stack is working but I keep a concern that the underlying issue(s) have not been fully resolved and might crop up again. I will install/activate iptables with Configserver firewall (CSF). I will use a configuration file for CSF that has is working on previous V5 installs of Virtualmin/Webmin. If that causes a problem, I will post it here.
I hope this is fixed because the new install script otherwise appears to be heading toward being very solid, removing some of the nuisance issues of VM5.
After additional installs of VM v6.07 on clean/fresh install of Centos 7.4, the underlying problem remains:
The installation script is enabling IPv6 addresses for SMTP even though the standard installation shows that IPv6 is not used by default.
This shows up in the connectivity check: Virtualmin>Logs and Reports>check connectivity .. the following problems were found : Problem type Error message Possible solution SMTP connection timed out Failed to connect in 60 seconds Check if your system's firewall is blocking port 25. And it shows up when trying to send an email from a fresh install virtual server using Usermin or Roundcube (and probably any other email client app): Sending emails to fail. Sending to Google Gmails shows why: The standard setup of SMTP ignores its own rules and sets up to use IPv6. I have tried to change that to just use IPv4 by removing IPv6 from the Postfix and Dovecot and server and virtual server DNS settings but have not gotten it to work.
This is the mail system at host yournetshare.com.
I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
(Note: notice the IPv6 addresses that smtp is trying to use) wimaxpro@gmail.com: host gmail-smtp-in.l.google.com[2607:f8b0:400e:c05::1b] said: 550-5.7.1 [2604:6600:0:1b:f05c:cbff:fef8:8d6a] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550 5.7.1 . m8si4135575pll.647 - gsmtp (in reply to end of DATA command)
I can't wait for the VM install script to get fixed - this is a big waste of time. How do I fix this manually?
"The installation script is enabling IPv6 addresses for SMTP even though the standard installation shows that IPv6 is not used by default."
What makes you think we're changing this or that IPv6 is not enabled by default? The default CentOS package has
inet_protocols = all, which enables the protocol for every interface you have on the system for making and receiving connections. We do not change this option. This is not a Virtualmin installer issue, per se...though I guess we could force mail to only work on ipv4, by default, but you're the first person to ever report this specific problem, as far as I know.You have a few choices for how to solve it in your specific case:
inet_protocols = ipv4in/etc/postfix/main.cfand restarting postfix withsystemctl restart postfix.Option 2 is probably would I would do.
I'm somewhat hesitant to make this the default, as we do have some users using IPv6 on their intranet servers and the like, and this would break things for them.
"I can't wait for the VM install script to get fixed - this is a big waste of time."
Assuming everything is our fault as the starting point of every conversation is probably counter-productive for all of us.
--
Check out the forum guidelines!
Centos core installation has become absurdly outdated: It still uses PHP 5.4 even though that is no longer supported. That runs against the understanding of the server/netowrking community that Centos is the defacto Long-term supported environment. That throws support behind Centos to support outside repos. I think the majority of admins agree: the industry has moved to support of more efficient server environments that include PHP7 which has long term support and the option of using either the old standby, Apache, or the more innovative but also highly supported NGINX. That defines the 'new gold standard' as the defacto standard. Centos has not kept up. Virtualmin has not kept up and still sruggles to support the most demanded server stack for web and mobile applications.
Folks, this is not acceptable.
What are you talking about? Please start a new thread if you want to change the subject of conversation. What does this have to do with email?
Also, a VM6 installation on CentOS has PHP7, can support nginx if you want it using the
--bundle LEMPflag.--
Check out the forum guidelines!
That comment was out of place - frustrated rant.
I thought that I had changed postfix main.cf to ipv4 only but apparently not or failed to save it. That worked.
Joe, If the inet_protocols = all by default, wouldn't that require that DNS be set up at the domain registrar to point to the ipv6 address or it would fail? If so, it should not be the default or, at least, clearly noted. I have several ipv6 IPs, probably because there are so many available for hosts to give out. Those show on the network interface but that was not set up by VM in DNS settings. I have set that up for other servers after the initial install of VM without ipv6 with no problems.
I may try installing VM after first setting up ipv6 at the registrar to see if that works as a default install.
Reverse DNS is what the error you posted above was about, and that's usually up to your colo/hosting provider (some will delegate to you if you request it).
I would think they would all have default PTR records for every IP they host. Every colo I've used does (though I usually request they delegate to my DNS servers).
To be clear: Reverse DNS is not handled at your registrar, and it's usually not even handled by Virtualmin (though you can create/manage reverse zones in Webmin, and updating records that have correlated reverse records could be automatically updated by Virtualmin if configured to do so). Reverse DNS is the responsibility of whoever owns the network block your system resides on, though they may delegate it to you.
I'm not convinced we should disable it, but I'm not wholly decided on that. We do have users who use IPv6. And, this doesn't cause problems for most people...this is the first time it's come up. I'm not sure why your server, in particular, decided to go out IPv6 when contacting GMail, while none of my test servers, even ones with IPv6 interfaces, didn't run into problems (it may be that the IPv6 addresses I have already have functional rDNS...it's not a problem I was looking for).
I'm kinda in a "keep an eye out for similar troubles" mode. I want to see if changing this and inconveniencing users who have/want IPv6 is worth the change. I don't know where we'd warn about this in the UI...we could maybe add a test to the configuration check, just to see if there are PTR records.
--
Check out the forum guidelines!
The VPS host provides DNS/rPTR and other DNS entry in their panel. I guess that would need to be set up for each ipv6 address that is used for email servers. If VM is set up to dynamically select IPs from an available group, I guess it makes sense to first set up an rPTR record for each IP address. I don't see any harm from having a rPTR record when the IP is not used for email functions, right?
I found that the VPS provider only supports ipv4 DNS records at the host and ipv6 cannot be put in manually by the user. However, I wonder if VM DNS records have sufficient delegation to do rPTR DNS or if a secondary DNS, such as Hurricane Electric can be used. He.net free DNS supports ipv6 and ipv6 to ipv4 tunnel broker capabilities. He.net describes how to set up rPTR DNS records and how to use an ipv6 to ipv4 tunnel broker for rDNS. I guess that negates the redundancy of having multiple IP addresses and adds an additional setup and maintenance hassle, but may work.
I've also considered using Amazon smtp services which provides some additional recognition to help prevent email blocking and is at a reasonable cost.
FYI, sofar i know every used IP in Public better need a reverse.
We use IPV6 on more Servers, there it is very important to have a reverse PTR for them to while Gmail otherwise Spam or worse, they are looking for the IPV6 in most cases if there is IPv6, there it doesn't help you IPv4 has a reverse PTR Gmail isn't using the IPv4 if a IPv6 excist!
One of the first things we do is and checking nameservers, DNS and reverse IP's for all! That is the probably the most important mainbasis for everything running well on your BOX.
The moment we had problems on new box a longer time ago our hostingprovider and we almost at the same time detecting problems with GMAIL mainly because of this. (and if you use a new IP or badly used IP before for mailserver it takes a little time to trust)
You can check some of your server and also mail for IPV6 and so on on https://internet.nl for free.
IN Netherlands IPv6 is longer used and working / up, In Germany started the last years more and more to so more common to use. In my opinion it makes no sense to not use IPv6 these days. ;)
Thanks. I have set up reverse PTR for all ipv4 but will have to request this to be set up by the VPS provider for ipv6 addresses. One of the first things I check is that the IPs provided by the ISP/VPS are clear on spam blocking lists. Online tools make checking the multiple lists easy. I've only had a problem with blocked IPs two times. It took weeks for the removal to work as it must proliferate out to subscribed servers that periodically download the lists. That is not an issue with the current IPs.
@cloud4G you are not the first to get this error. I also landed with this error. I got similar error of 550 stating- 550-No Such User Here 550 Sender verify failed (in reply to RCPT TO command). I am using Virtualmin Ubuntu latest on this day in a droplet- Digital Ocean.
HOW I SOLVED IT
1. Used Tool : https://mxtoolbox.com to analyse.
1.1 see this https://in.godaddy.com/help/add-an-spf-record-19218
2. Updated my godaddy domain dns txt as given in https://www.digitalocean.com/community/tutorials/how-to-use-an-spf-recor...
I used this :TXT @ "v=spf1 a include:_spf.google.com ~all"
( Changed google.com with my domain in above keeping everything same).
3. Tried to send a mail . It landed to spam. No worries . I added other requirements to make it land in Inbox:)
Please note I have IPv6 enabled for my droplet.
A Food Tech Engineer who loves coding