When I go to https://mxtoolbox.com/diagnostic.aspx, enter my domain (pairofdocs.net), and click ‘Test email server’, I get the error message:
Connecting to 23.23.216.253
2/19/2021 9:23:30 AM Connection attempt #1 - Unable to connect after 15 seconds.
I have no idea why this is happening – any suggestions?
I have used the test previously and it worked. My domain is configured as follows:
DNS – on NameCheap.com
Web site (a simple one) – on Amazon Web Services
Email – handled by Zoho
I rebuilt my domain about six months ago, on a new AWS instance - whose IP address is 23.23.216.253, and do not recall the problem’s having happened prior to the rebuild.
Since your Email hosting is outsource to Zoho, there is a pretty good chance the email server has been setup correctly and has a pretty decent uptime.
It is likely the problem you are having is with how you are connecting to the email server although the error you've provided shows what seems to be an offline email server.
Related
My Ubuntu based webserver needs to occasionally send emails. My python code is:
withsmtplib.SMTP('smtp-relay.gmail.com', 587, 'mydomain.com') as s:
s.sendmail(fromaddr, toaddr, msg.as_string())
s.quit()
I have
a Google workspace account
am using IP authentication (not SMTP auth)
my staging and production servers added as trusted IPs (staging is
local, production is cloud)
This setup had been working fine for 6+ months.
Two days ago I upgraded Ubuntu from 20LTS to 22LTS and python 3.8 to 3.10. Now the email is working fine on the staging server, but production keeps throwing:
Invalid credentials for relay [...]. The IP\n5.7.1 address you've registered in your G Suite SMTP Relay
service doesn't\n5.7.7 match domain of the account this email is being sent from. If you are\n5.7.1 trying to
relay mail from a domain that isn't registered under your G\n5.7.1 Suite account or has empty envelope-from,
you must configure your\n5.7.1 mail server either to use SMTP AUTH to identify the sending domain or\n5.7.1 to
present one of your domain names in the HELO or EHLO command. For\n5.7.1 more information, please visit
https://support.google.com/a/answer/6140680#invalidcred ...
Any suggestions?
Edit 1:
I fired up my old ubuntu server in the cloud. I added its new IP as trusted on Google. The email worked fine. I can think of only three possibilities
Google somehow recognizes and trusts requests coming from the old
device (even though it now has a different IP)
Linode is somehow not sending the correct IP address from my new
server
Something broke during the Ubuntu upgrade
I find each of the 3 possibilities quite bizarre and unbelievable at this point, but I'll keep researching.
PS: Three factoids that may/may not be relevant:
I upgraded the staging server in place. For production I spun a new
instance, made sure everything else was working fine (except
email) and then transferred IP from the existing instance to new
When I log in to my google admin account to edit trusted IP list, my
IP is the same as staging server. I don't think I have the same
option for production, since it's an Ubuntu server I manage through SSH
I found some comments online (none in official documentation), that
the reverse DNS needs to be setup before Google would relay anything.
I set up the entry about 20 hours ago for production, but still
getting the same error. And for my staging server, I don't have rDNS
and it still sends emails (it's accessible from the internet, but I
don't have a static IP)
PPS:
The sender email is someuser#mydomain.com (not #gmail.com)
The production server is hosted on linode.com
This post comes close
to discussing a similar situation, but that is focused more on
signing in. My setup uses IP authentication, not SMTP auth. Plus it was working fine until Friday (8/12)
It turned out to be a really frustrating issue. My best guess is that Linode's Ubuntu 22.04 repository has issues. We were thinking of migrating to AWS anyway, this gave us a strong impetus.
Anyway, here are some tips from my experience that a future reader might be able to benefit from
When you're using IP authentication for Google's SMTP relay, the updates are fairly quick. I ended up spinning at least 5 instances with 5 different IPs, and each time Google was able to trust my IP within 2-3 seconds (after I updated in workspace console)
Google didn't care about my reverse DNS entries. I had read some comments online that Google wouldn't relay without rDNS, but I didn't face any such problems (at least not any rDNS I was setting. The ISP or the cloud provider have a default entry, that was good enough - if Google was even looking for it). This one was particularly problematic because that information can take hours to propagate, and I kept thinking maybe my code will start to work tomorrow.
The error message I received from Google was pretty uninformative. I contacted Google support to see if they have access to anything more meaningful on the server side. They didn't - it was a waste of time
It was somewhat helpful to run a fake SMTP server to see what my client was sending. I got it from this post. I ran it for a setup that was working and one that wasn't. In my case, the communication received was identical. Though in hindsight maybe I would've seen some differences if I ran it on a remote server.
python -m smtpd -n -d -c DebuggingServer localhost:2500
I have created a hosting instance in GCP but unable to send or receive email from it. I have used Vesta-cp as control panel and Ubuntu 18.04 minimal as OS. I have opened all required ports in firewall rule and apply them to instance but still get nothing. Any one interested in this issue please answer. Thank You !
See this guide: https://cloud.google.com/compute/docs/tutorials/sending-mail/ Port 25 is always blocked and can't be used to send emails.
Having said that, you probably are better off using managed service for sending emails. Managing security and compliance for mail servers are increasingly getting difficult to manage. So you are better off using a managed service to send emails.
I install a brand new VM in Azure (debian). The thing is that the email i send isnt accepted by the remote mailservers. In my gmail the mail is received in my spambox and at my own webhoster the mail isnt even visible at all.
Ofcourse this can have several reasons and has todo with spam recognizion etc. The thing is that i see some errors in my mail headers what, i think, is causing the problems.
Received-SPF: temperror (google.com: error in processing during lookup of root#hstop40-w01.hstop40-web.a4.internal.cloudapp.net: DNS timeout) client-ip=137.117.203.77;
I have a cloud instance called hstop40-web and my server is called hstop40-w01.
I am kinda lost on what todo next. Hope that someone can help me fix this
Thnx
You need to ensure, at the most basic level, that reverse name resolution works for your SMTP host (i.e. 137.117.203.77 must resolve to the Fully Qualified Domain Name (FQDN) you use in your SMTP headers). If this isn't true you'll most likely get mail rejected from most public SMTP hosts (gmail included).
Beyond this challenge (which you can control by setting up DNS correctly) you might still get rejected mail because a lot of blacklists will inlcude IP address ranges from Azure and AWS (this is why both offer mail services - SendGrid on Azure and Simple Email Service (SES) on AWS).
I've recently purchased a cloud server which has public IP and I am using it to host an xmpp server.
My first task was to ensure my users connected using my subdomain - as an example m.chat.com.
In my configuration I have the following:
%% Hostname
{hosts, ["m.chat.com"]}.
I then created an admin user with that domain.
In parrellel I have created the following DNS record with my host provider, hostgator for my subdomain m.chat.com
Name TTL Class Type Record
m.chat.com 14400 IN A [IP of the server]
One thing that puzzled me was my ability to access the ejabberd web admin console. This was achieved via: [IP of the server]:5280/admin however I could not access it via m.chat.com:5280/admin
That aside, inside the web console, under "Virtual Hosts" I could see the host "m.chat.com". I created a user "user#m.chat.com" and tried to connect via Adium.
Inside Adium, simply typing in user#m.chat.com with the password did not work. Instead I had to also specify the "Connect server" which in this case was the [IP of the server].
It has connected fine and I have registered other users to check everything is working and it is.
Then I thought I'd go back to the ejabberd configuration and start messing around. I changed the hostname to the following:
%% Hostname
{hosts, ["m.chat.com", "facebook.com"]}.
I registered a user with that domain and restarted ejabberd. Upon checking the web console, to my surprise, I could see the Virtual host "facebook.com". I tested this user in Adium with the [IP of the server] defined in the "Connect server" section and it connected fine. I asked other people with their own internet connections to use this account on their PCs and they were able to connect too.
Story over - my question to everyone is how is this possible? Am I missing something? Is there no domain authentication. After searching online, it seems you can even use fake domains.
If I am to operate my own service in the future (iOS chat app) I do not want anyone using my domain names with their own public servers.
Can someone shine some light.
Thanks!
Edit: A second question - Preferably I do not want to have to define the "Connect Server" upon using a client. I would like the client to recognise the #m.chat.com domain and establish a connection to the Servers IP automatically. Have I configured my DNS record correctly? For anyone else using Hostgator, is there an additional task I must do?
Edit: I can now access the web console via m.chat.com:5280/admin and I no longer have to specify the Connect server when using a client. I didnt do anything, I think it was a case of Hostgater updating the DNS or something, they say it usually takes 4 hours. However I am still slightly puzzled as to why I can create accounts with the facebook.com domain. I understand that because I can not access the DNS admin for this domain I can not create any records but that does not prevent me from using the domain and just specifying a Connect server.
Your initial problems (unable to access the server by using m.chat.com) were almost certainly DNS issues, and it seems you have isolated that down to the time taken to update the record.
Your second question - about the fact that you can name virtual hosts without restriction, is simple but interesting. What makes you think there should be any kind of restriction? It would be like you dictating that I can't save "m.chat.com" in a file on my disk, or that I can't send "m.chat.com" in a message across the internet.
This is why DNS exists and is structured the way it is. Although I can tell my server that it hosts facebook.com, nobody will connect to it because the DNS record for facebook.com does not point at my server (users generally don't set the "connect host" manually). Which begs the question... why would I want to tell my server it hosts facebook.com, and if I did, why should Facebook care?
An additional, but relevant, identity layer on top of DNS are certificates - which clients should validate for the virtual host name in spite of any "connect host" set. Since it's not possible to have a certificate for facebook.com, clients should generally pop up warnings or fail to connect at all. If they don't, they're probably not validating the certificate correctly.
I've recently setup my Ubuntu web server with exim4 so my PHP website applications can send email such as "thank you" and "confirmation" notices.
I've got it setup and working such that I can send email to gmail, Yahoo! and my work address. However, my work email gets caught up in our spam filter. I'm new to setting up mail servers so I'm not sure what I might need to look for in making this mail server more trusted, while keeping is secure.
Here are some details:
Server is NATed behind a firewall.
Firewall has port 25 open for outgoing SMTP traffic (from server to anywhere).
Server is virtual hosting a couple different of our websites
The server is running the following exim4 config:
dc_eximconfig_configtype='internet'
dc_other_hostnames='web-serv.example1.com;example2.com'
dc_local_interfacees='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets='' dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
Questions:
Do I need to open port 25 to incoming SMTP mail (anywhere to server)? I wonder if other mail servers need to talk to my mail server to verify itself, in a sort of handshake attempt.
I have not created any MX records primarily because the server has different websites on it the mail server should send mail for all the websites. Do I need to pick/create a domain address and create MX records for it?
One thing of note is that the mail headers look like this:
Return-Path: <www-data#example2.com>
Received: from web-serv.example1.com ([Firewall public IP Address])
Received-SPF: neutral (google.com: [Firewall public IP Address] is neither permitted nor denied by best guess record for domain of www-data#example2.com)
"web-serv" is the host name of the server, such that you get this if you type it into the command line:
$ hostname
web-serv
and "www-data" is the account name for the Apache2 server that Ubuntu gave it as default.
Any other general advice would be appreciated. It's all new to me.
Cheers!
One item of note, since I posted this question time time ago (almost 10 months) is that I found out the biggest issue I had was with setting up the DNS for reverse DNS on our hosting providers side of things.
In other words, our hosting provider (the people who give us our IP address and manage our hardware) had to enter a record to match my server(s) hostname to whatever IP address it used.
There's a specific name for this. I believe it's a "PTR" record but the name escapes me at the moment, but you basically tell them "my server hostname is ..." and they do a quick update to the DNS for reverse DNS purposes.
When I asked this question, we had a different hosting provider who didn't really help explain this to me, and after switching providers, I got to talk to someone who was happy to help me understand that side of the equation.
And as I understand it, this is setup by the people who assign you the IP addresses. But there's probably more to it than that.
Once I got that setup properly, email had no problem getting through the spam filters and Gmail/Yahoo showed SPF as "passed". It was showing neutral before.
Our company email was set to drop any email that would not resolve reverse DNS, which is why I could not even receive the email or find it in the spam filter. Of course, that situation would be dependent on the company and what email policy and software they're using to manage spam. Some might just drop all email that does not reverse DNS and some might dump it in to spam filters instead.
Hope that might help some people with similar issues.
Cheers!