I'm using GCE as a web server for the first time. Everything is fine so far, I have installed the LAMP stack without any trouble but now is the time to set up the DNS.
My two problems are :
I can't handle email adresses with GCE (can't send emails without sendgrid). So I would like to keep the emails going to my current shared hosting. So emails should be managed by my shared hosting but access to my website should be via GCE.
I also would like my DNS to point to a specific folder of my GCE instance (not the root).
I searched a lot for the answer but I can't manage to make it happen.
Thank you for your time
I found a solution... Posting here if anyone has the same problem later...
A record to GCE : # to xxx.xxx.xxx.111
A record to shared hosting : mail.domain.com to xxx.xxx.xxx.222
MX record # to mail.domain.com
Easy. Seems to be working for me right now.
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
Over the years, I used No-IP to link a domain to my IP address, and then used No-IP's DUC (Dynamic Update Client) to update my IP, so that the domain will always point to my IP.
That's very handy for running dedicated game servers.
Is there a DUC-equivalent for Google Cloud DNS?
In essence - No - there isn't :(
Unless yo're using Google Domains for your domain hosting then yes - they support just the thing.
Cloud DNS doesn't have that functionality. There are several workarounds like reserving a public IP for your VM which in my opinion would be the best way to do it. Unless your VM get's deployed using Deployment Manager then it may require some more scripting.
Similar questions have been raised on Stackoverflow here and here which you might find helpful.
If you're running Linux here you'll find a complete script how to update DNS records after a machine startup.
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.
Old linux user here; but only recently started using Google Cloud solutions to create a few VM instances running CentOS. Works great and have been using them for a few years successfully.
I am adding some new functions and I would like to be able to get emails that normally go to root to be sent to me.
In the past, I simply added a line in /etc/aliases at the end of
root: myemail#gsuitedomain.com
This worked well as most of the boxes that I managed were inside a network where I also controlled the local mail server and could just send through it.
It appears that I need to setup some sort of relay using G-Suite?
Is that the right path?
Also, I really don't want to relay the email. I just want to send it to one of the G-Suite accounts. So, no real relaying needed.
Can someone direct me in the right direction for the easiest path to accomplish this?
Thank you for your help,
Tamer
GCP by default blocks all outbound traffic on port 25 so you have to use different one. You can read about it in more detail in the GCE documentation.
In my opinion you will have to run sendmail, postfix or anything else to send emails out but you have to configure them to some other port than 25.
I want to be able to run an EC2 instance (CentOS LAMP based) as a mail server and create email addresses for users when they sign up so that they can upload files via email. The emails would be parsed and attached files processed and added to S3 for storage.
Is this feasible?
What mail package would I need for this?
I would like to be able to create email address such as username#uploads.domainname.com
my domainname points to a webserver not on amazon web services so I realise this may not be possible.
where do I start with this, are there any good resources for setting up a mail server on EC2
many thanks
To answer the question, yes it is possible. As paul says, if you require 24x7 and long term then EC2 may be more expensive than some other providers. But it can make sense if you're a startup or if you're doing this to learn more about these topics.
Basic steps would be:
Create a linux EC2 Instance http://docs.amazonwebservices.com/AWSEC2/2008-02-01/GettingStartedGuide/?ref=get-started
Install a mail package http://flurdy.com/docs/postfix/
Change your DNS MX record http://en.wikipedia.org/wiki/MX_record
Amazon has had trouble in the past with blacklisting.. but they're trying to address that. Read here: http://developer.amazonwebservices.com/connect/thread.jspa?threadID=37650
Edit: You could also use a pre-configured CentOS image (combining step 1+2), this one has postfix already installed: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=821
Using EC2 as a mail server does not seem like a good fit to me. You're not using either the "Elastic" or the "Cloud" part of the "Elastic Compute Cloud". You need something that has to be up 24x7, has the same IP all the time, and doesn't need to expand or contract on demand, so a VPS would be a better solution.
It can probably be done with the use of an elastic IP along with the correct configuration of the mail server on the ec2 instance to receive mails.
However, it might be easier to use Google AppEngine. You can forward the messages from username#uploads.domainname.com from your existing mail server to your appspot email address, then process the messages and store the files on S3 with a some appengine code in python. See the appengine documentation on receiving email for more information: http://code.google.com/appengine/docs/python/mail/overview.html