I performed the simple Digital Ocean ghost droplet setup (Ubuntu 14, Ghost 0.7) and the blog works fine, except the fact that, when I try to invite other authors, I read the following error in the console:
http://politidados.io/ghost/api/v0.1/users/ Failed to load resource: the server responded with a status of 504 (Gateway Time-out)
And, of course, the emails aren't sent.
The same error happens with different smtp configs in the config.js file (I tried mailgun and gmail).
Any help is more than welcome! Thanks!
After some precious time struggling with nginx configs and ghost configs, I figured it all out:
Digital Ocean blocks SMTP for newly created accounts on certain conditions. That was the case for me.
So all my configs were right from the very beginning - I just needed to send some personal information to the support#digital ocean.
All in all, the digital ocean droplet works fine and all you have to do is to follow these 2 tutorials:
https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-ghost-application
and
support.ghost.org/mail/
And ask them to lift the SMTP block.
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
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.
My company has 4 different third party applications that use 4 different gmail addresses to send mail over port 587. One of the applications is distributed across over a hundred clients.
All four apps stopped working last week. I've been struggling to figure this out with GSuite support for the past week and they have so far been very unhelpful. One representative pointed to this recent update as the likely culprit:
https://gsuiteupdates.googleblog.com/2020/04/improve-email-security-in-gmail-with-TLS.html
But I don't have a ton of experience with mail servers and much of this is going over my head. I'm not sure why exactly the above update cause our apps to stop working.
The apps are failing to establish a TLS connection to the server and result in the following error:
handshake failure
Closing connection in response to fatal SSL/TLS alert.
Aborting handshake due to fatal alert
This comes after receiving a "Ready to start TLS" response from the smtp.gmail.com server.
All of the apps are using the Chilkat Mailman Active X component for the mail features.
https://www.chilkatsoft.com/refdoc/xChilkatMailManRef.html
Assuming the recent update is the actual culprit, I'm wondering if someone can explain why this caused our applications to stop working? Has GMail stopped supporting StartTLS? I also need to know if there is anything we can do from our GSuite account to get this working again without having to update over a hundred client applications.
The first support rep I spoke to suggested doing the following in the google admin console:
Apps -> G Suite -> Settings for GMail -> Advanced Settings -> Secure transport (TLS) compliance:
We unchecked the "Require CA-signed certificate" box and saved the setting. This has not resolved our problem.
The support rep also briefly mentioned the "Alternate Secure Route" setting in Gmail advanced settings, but I'm not sure if he knew what he was talking about or if this is applicable to our issue.
Edit
It looks like this is a combination of the GMail server update and some sort of incompatibility in the Chilkat mail component. I tried testing with a trial of a newer version of the component and SMTP works using the same settings with this component.
The developer of the component says he is not able to help me with this issue unfortunately. So I'm still wondering why the GMail server update caused the old component to stop playing nicely. I'm hoping that if I can understand what the specific change is, I can find a solution that doesn't require a major rollout.
My java mail client also just stopped working not long ago. I was using TLS connection as well. I got authentication errors.
I look forward to your findings!
-- I found my issue:
https://myaccount.google.com/u/1/lesssecureapps was no longer less security
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.
We have a VPS with CentOS combined with DirectAdmin which we use for a Magento shop. This runs fine, except for sending email.
Problem:
It appears that some specific domains won't receive our emails and we get a bounce. If we use any other email sending systems, the mails arrive without problems.
The bounce mail contains the following error:
SMTP error from remote mail server after HELO Company-Shops:
host mx-cluster-b2.one.com [IP ADRESS]: 504 5.5.2 :
Helo command rejected: need fully-qualified hostname
After googling and trying things for a week now, I am a bit lost. I tried checking postfix in CentOS, but this is not installed and I'm not quite sure if this is needed.
Possible issue?
I believe the hostfile in CentOS is setup incorrectly:
127.0.0.1 localhost localhost.localdomain localhost4 ... etc
OUR IP Company-Shops
'Company-Shops' should probably be a domain name, am I right? The same as the rDNS. But I'm afraid if I change this it will kill my site and whatnot. I'm not sure if this entry correlates with the 'company-Shops' helo label in the bounce error.
Some extra info:
- We use the webmail Roundcube from DirectAdmin
- At the moment we run one shop, but this might grow a bit (multiple sites on 1 IP)
- We don't use subdomains
- We've set up a reverse DNS, with the domain
Is there anyone with similiar experiences or with a bit more knowledge about this subject? I appreciate any advice we can get, as we are stuck..
Many thanks.
Yes, that's right: your mail server should identify itself using a fully-qualified domain name when it connects to send mail via SMTP. You don't say what mail server you're running, but since you're using DA, it's probably Exim. If so, you want to edit /etc/exim.conf and set primary_hostname to the FQDN of your server.
This would also be a good time to double-check that reverse DNS is set up properly for your IP address. Many hosts will also reject email from servers on IPs without a valid rDNS record.
I'm not familiar with Magento, but I can't see any way that changing the Exim configuration in this way could impact that program.