I've noticed on the Networking and Firewalls page that Port 25 (outgoing) is blocked on Google Compute instances.
I've configured postfix to forward emails on my instance, but I assume this won't work due to this port blocking, what are my options if I want my emails to forward (or at least work)?
This looks pretty similar to Google Compute Engine (GCE) email delivery solution?
Those answers reference https://cloud.google.com/compute/docs/sending-mail as a solution using SendGrid to handle the email.
That question also references a solution using smtp.gmail.com using MSA to send mail as your gmail account, which might or might not work for you depending on your needs.
Related
I have a gmail account that I want to use for one of our internal services. We have a server running and we want this gmail account to be used to send out an automated email to people who register.
Now, here's the problem. I have correctly configured my gmail id in the server and know that I am able to correctly ping the gmail smtp server. However,I always get stuck because gmail by default expects you to verify any new device you log in from using an OTP. In my case, this is the first time login from this server machine and hence this happens. I can see it in the logs as well - it brings up this device verification page.
Some questions:
Is there a way I can turn off this feature in gmail? I don't think this is the same as 2 step verification. I have turned it off. I have also enabled my gmail account to be accessible from non secure apps.
If not, is there a way to do the verification step via command line on my Linux server?
Any other smtp based email service I could use that does not have so many security features?
Lastly, I am doing this for a quick prototype. Therefore I am ok bypassing some of these aspects. However, I would definitely want to ensure that the access to my account is secure once this is productized. Any links on how we can do this from non google apps or services?
Thanks in advance!!
It sounds to me you have an application that needs to work on your behalf and do some gmail-related tasks.
If that's the case, why not use the Gmail API with Service Account impersonation?
In short, a service account can impersonate a real user. This is a process that does not require manual input after it's setup, so it's ideal for server-side usage, where you might not even have a UI to interact with.
Also, the Gmail API is much easier to set up than Gmail SMTP, and there are examples out there on how to do this with this setup. You can look at this answer for some references on what it would take.
Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I'm having problems with gmail smtp server. I already read many posts here in StackOverflow about that subject.
The best post I found about test the connection is this one.
Although it is very well explained the error I'm getting I couldn't find a answer:
Google SMTP just says "Please log in via your web browser and then try again". I'm completely sure that the password and the email (both in base64) are well encoded.
As you can see here, in this image:
,
there is just one difference I can notice: the user#gmail.com and password is sent in two steps. In the link above the guy sends both at the same time. Google didn't accepted that.
But the fact is, I write
auth login Y29udGF0...
(user in base64, googles responds: )
334 UGFzc3dvcmQ6
(wich means "Password: ")
YzQ2MjJmNWVi.... (paste my password in base64 and hit "enter")
Then Goggle says:
Please log in via your web browser and then try again.
534-5.7.14 Learn more at https://support.google.com/mail/answer/7126229
And I'm going through all this problem because #MediaTemple and #DreamHost are not working with PHPMailer. I already use PHPMailer for a long time ago, in so many different hosts, using SMTP but failed with (mt) and Dreamhost. Now I'm in middle of a project that it >must< work on these two hosts.
I know this is an older issue, but I recently had the same problem and was having issues resolving it, despite attempting the DisplayUnlockCaptcha fix. This is how I got it alive.
Head over to Account Security Settings (https://www.google.com/settings/security/lesssecureapps) and enable "Access for less secure apps", this allows you to use the google smtp for clients other than the official ones.
Update
Google has been so kind as to list all the potential problems and fixes for us. Although I recommend trying the less secure apps setting. Be sure you are applying these to the correct account.
If you've turned on 2-Step Verification for your account, you might need to enter an App password instead of your regular password.
Sign in to your account from the web version of Gmail at https://mail.google.com. Once you’re signed in, try signing in
to the mail app again.
Visit http://www.google.com/accounts/DisplayUnlockCaptcha and sign in with your Gmail username and password. If asked, enter the
letters in the distorted picture.
Your app might not support the latest security standards. Try changing a few settings to allow less secure apps access to your
account.
Make sure your mail app isn't set to check for new email too often. If your mail app checks for new messages more than once every 10
minutes, the app’s access to your account could be blocked.
I did this every time the problem happens:
https://accounts.google.com/DisplayUnlockCaptcha
problem sorted in my case!
I recently got this message, too, after I switched the data center location of a web application sending through Google SMTP.
The URL that apparently Google means is: https://support.google.com/mail/answer/78754. At that link, one of the steps is to reset your password. Not coincidentally, I also received an email from google with a subject of "Suspicious sign in prevented" that instructed me to change my password.
After resetting my password, I was back to using Google SMTP as usual.
I know this question is already been answered but for new comers those two solutions may help:
Make sure your gmail is allowing low secure apps to sign in, you can
turn it on here:
https://www.google.com/settings/security/lesssecureapps.
Change your password.
There are two ways to resolve this, and only one may work, depending on how you're accessing Google.
The first method is to authorize access for your IP or client machine using the https://accounts.google.com/DisplayUnlockCaptcha link. That can resolve authentication issues on client devices, like mobile or desktop apps. I would test this first, because it results in a lower overall decrease in account security.
If the above link doesn't work, it's because the session is being initiated by an app or device that is not associated with your particular location. Examples include:
An app that uses a remote server to retrieve data, like a web site or, in my case, other Google servers
A company mail server fetching mail on your behalf
In all such cases you have to use the https://www.google.com/settings/security/lesssecureapps link referenced above.
TLDR; check the captcha link first, and if it doesn't work, try the other one and enable less secure apps.
To send mail using Gmail SMTP, need to change your account setting. Login into your gmail accout then follow the link below to change your gmail account setting to send mail using your apps and program. https://www.google.com/settings/security/lesssecureapps
Note: This setting is not available for accounts with 2-Step Verification enabled. Such accounts require an application-specific password for less secure apps access.
I also came across this problem. Google detected my Mac as a new device and blocked it. To unblock, in a web browser log in to your Google account and go to "Account Settings".
Scroll down and you'll find "Recent activities". Click just below that on "Devices".
Your device will be listed. Okay your device. SMTP started working for me after I did this and lowered the protection as mentioned above.
There are at least these two issues I have observed for this problem:
1) It could be either because your sender username or password might not be correct
2) Or it could be as answered by Avinash above, the security condition on the account. Once you try SendMail using SMTP, you normally get a notification in to your account that it may be an unauthorized attempt to access your account, if not user can follow the link to turn the settings to lessSecureApp. Once this is done and smtp SendMail is tried again, it works.
Some apps are marked as less secure by google, so you just need to give access for those app so google will allow you to access its services to you.
follow this http://www.codematrics.com/your-imap-server-wants-to-alert-you-to-the-following-please-login-via-your-web-browser-gmail/
I run my business email through Google Mail, using my own domain (i.e. my email address is 'info#mydomain.com'). I've recently set up a support forum on my website which needs to send emails from the site admin via a PHP script. However, none of the settings I've tried seem to work. I thought these would work but they don't:
SMTP server: smtp.mydomain.com
SMTP username: info#mydomain.com
Password: test123
I've also tried setting up a different email account on my domain on the server and using the server IP and settings for this different account but I can't get this working either.
Can anyone suggest how to get this working? Do I need to use Google's own SMTP settings as opposed to those for my domain?
I don't know much about this so apologies if it's a dumb question - I've tried searching but can only find examples where people are actually using GMail as their email account rather than their own domain.
Thanks
This turned out to be an issue with WHMCS, which they have apparently since resolved (although it was a show-stopper for me at the time so I wasn't able to see the resolution through).
I've got a PHP app with an invitation system where users can invite other users to try the service. Internally we use google apps for our domain to send/receive emails (mydomain.com).
1) My question is, can I send emails from my server with the from address being invite#mydomain.com? I am worried about the emails being blocked/ignored by the destination server. I am aware that it is possible to send the emails by configuring my php installation to use google smtp server, but there is a limit of 500 emails a day, which is not very scalable.
I don't really know that much about sending emails and why/how they are blocked/considered spam. I'd appreciate any good advice/tips you can give me.
2) What is a good way to test to see if the email portion of my app is working without installing it on my live server. Can I just setup an smtp server on my desktop and send mails this way? Can you recommend any other good ideas for testing. I'll basically be sending just a few emails to my personal webmail accounts to make sure that everything works.
Thanks,
Bill
1) My question is, can I send emails
from my server with the from address
being invite#mydomain.com? I am
worried about the emails being
blocked/ignored by the destination
server. I am aware that it is possible
to send the emails by configuring my
php installation to use google smtp
server, but there is a limit of 500
emails a day, which is not very
scalable.
I don't really know that much about
sending emails and why/how they are
blocked/considered spam. I'd
appreciate any good advice/tips you
can give me.
There is a way track if mail has been bounced (there are more than 10 possible bounce reasons!). You can set the return-path header in your outgoing emails. Best practice is to specify a different mail address in the return-path. When e-mails are getting bounced for whatever reason, a notification will be sent to this address. Additionally you can have for example a (PHP) cron job that connects using IMAP to the bounced email account and do something with the bounced e-mails. This is a pretty reliable way to track the status of your sent emails.
Additionally, in order to minimize the chance your e-mail will get blacklisted you could think about signing your e-mails using a certificate (you can get one for free for personal usage. A commercial one may cost you around 25 dollars a year)
2) What is a good way to test to see
if the email portion of my app is
working without installing it on my
live server. Can I just setup an smtp
server on my desktop and send mails
this way? Can you recommend any other
good ideas for testing. I'll basically
be sending just a few emails to my
personal webmail accounts to make sure
that everything works.
You can actually send a test email from everywhere as long as the outgoing SMTP port (25) is not blocked. If you have an own smtp server with username/passwd authentication enabled, you will be able to send e-mails from everywhere using the these credentials/settings. In all other cases, you will have to use the smtp of your internet provider to send emails.
To address the second part (as Eric pointed out, you'll have better luck at serverfault.com with the first part), any locally hosted SMTP server should be able to do the trick, and there are plenty available for any given OS. Google can help you there.
The main thing you'll want from a local SMTP server is detailed logging. It's entirely possible that the local server could fail/refuse to deliver the message to its intended destination for any number of reasons (again, serverfault.com), but that's outside the scope of testing the code's delivery of the email to the SMTP server.
If it does properly forward the test message to you, great. But if it doesn't, you just want to be able to see in the server's logs that it received the message correctly and was able to process it. Whatever that processing accomplished is a separate issue.
For email testing I use Pappercut. It's easy to use but some antivirus may not like you opening port 25.
I use Dumbster for testing. I will catch the emails, then my test code can check the content.
To avoid spam, there are a number of things you have to do, and I'm not sure I've found them all. Make sure that your IP is registered, and that a reverse lookup returns the right domain.
1) Sending:
This is a good article describing some of the pitfalls around sending email http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html
Check out the comments too.
2) Testing:
Disclaimer - I work for the company behind the service linked to below.
If you would rather not set up your own smtp server you can use a hosted email testing service like Clickity
You can create as many test email addresses as you like or configure your app to point directly at our smtp server. You can then view the complete email on our site as part of your manual testing or automate the tests it via our API.