I have a Meteor App that I put on their new Galaxy Platform that throws this error when attempting to send a verification email.
Exception while invoking method 'sendEmailVerificationMessage' Error: Greeting never received
at Object.Future.wait (/app/bundle/programs/server/node_modules/fibers/future.js:398:15)
The Meteor people said that it's an issue with my App but it works just fine both on my testing server and when deployed to Modulus. When checking the email server it never shows any attempt to send email from Galaxy.
My question is, is there any further testing that I can do to see exactly what the problem is, maybe some debugging code that I can add to the code?
process.env.MAIL_URL = 'smtp://' + encodeURIComponent(smtp.username)
+ ':' + encodeURIComponent(smtp.password) + '#'
+ encodeURIComponent(smtp.server) + ':25';
It often hosting provider block SMTP server as it often being abused by user
First, check it with localhost. If it work, then probably Galaxy block SMTP server. Contact them for more info
EDIT
This work with me with Digital Ocean. Haven't test with Galaxy
/*Send Email Through Gmail SMTP*/
process.env.MAIL_URL="smtp://gmailUsername:gmailPassword#smtp.gmail.com:587";
EDIT 2
See here: Gmail SMTP is not working in ec2 instance
Galaxy use AWS EC2, so you should setup AWS SES. Free SMTP include gmail isn't work with AWS
When I set my port to 587 it started working. I'm setting process.env.MAIL_URL inside Meteor.startup() for local/development and seeing no problems. Hope this helps someone!
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.
I'm working on a Laravel 4.2 application that needs to be able to send emails. When the SwiftMailer component contacts the Microsoft Exchange server we use here it's receiving the following reply:
* OK The Microsoft Exchange IMAP4 service is ready.
* BYE Connection is closed. 13
My understanding is that I should be seeing SMTP response codes 220 and 221 instead of those asterisks; the SwiftMailer module is throwing an Exception when it receives the message without the codes.
I'm trying to do some investigation before bugging my coworker who manages the server in question. Does anybody have an idea how this substitution of asterisks for the codes may be occurring? I'm confident based on reviewing the code in SwiftMailer than this isn't occurring to the text of the response after it's received. Is this some sort of Exchange server security feature I'm unfamiliar with (and can't imagine the value of)?
The messages indicate that you are talking to an IMAP server, not an SMTP server. I'm guessing you put the wrong port number somewhere.
Odds are that you've got an "intelligent" network device between you and the server that's doing traffic inspection. I've seen this with Cisco devices, where the SMTP connection banner is replaced with a string of asterisks and all the command words in the SMTP traffic are replaced with "XXXX".
I'm using Symfony 2.1 and SwiftMailer to send out registration e-mails.
The process handling for this takes abouts 20 seconds if there's an email to be send. Meanwhile the website is loading. This might give users the impression that something went wrong.
I'm connecting using SMTP.
I have a similar Symfony2 Installation which connects to the same mail server, also using SMTP and there an email is send immediately.
Is there a way using XDEBUG or something else to see what is causing the delay?
I think this was a slow DNS lookup problem.
In parameters.yml I've changed the SMTP host from the domain name to 127.0.0.1 and it works perfectly now.
I got this project "skpsmtpmessage" and I tried to send mail first. So I changed all the mail id to gmail id. But replay host is problem. I tried smtp.gmail.com, smtp.google.com, smtp.googletalk.com. But when I run my program, I get error that "Unable to connect server"
Which relay host should I use for gmail.
The correct SMTP server for Gmail is smtp.gmail.com, but I don't know how to help you further, the question is pretty vague.
You can also take a look at the configuration instructions for using Gmail on the iPhone to see if you're making a mistake with another parameter.