I have an app built with Node.js and running in Google Cloud. I need to sand certain system emails such as setting change confirmation, password reset tokens, etc. I use nodemailer and Google SMTP server for sending such mails. Till now I used a simple Gmail account like myaccount#gmail.com for this purpose. But now I want to send it from no-replay#mydomain.com.
My question is whether I need to create a new user in my Google Workspace (and pay monthly for it) for this purpose, or there is another way?
To use all the core services in Google Workspace you need to pay at least for the business standard edition $6 per month.
It's good if you're going to use it as a permanent or business solution. But if it's just for testing it's not worthy. It's better a trial.
As an alternative solution, if you have a cheaper SMTP server, you can add that email address as Send mail as in your free Gmail account and configure an alias in nodemailer
var mailOptions = {
to: user.email,
from: 'Domain Email <example#domain.com>',
subject: subject,
html: emailHTML
};
Related
I have very limited knowledge about SMTP and IMAP/POP. SMTP --> sending message, IMAP--> Mainly for receiving messages.
I have a woocommerce website and i already did setup my email system to use SMTP relay using zoho. I believe zoho also provide mailbox services since I am able to communicate with my customer(both two and fro) using its email service. They have their app and i can receive and send mail from that app. Obviously, I have set up all the records including MX to send/receive the email to my zoho inbox.
No i want to move my email services to postmark or like sendinblue. All i can see the setting related to sending the mail but how/where will I receive the mail when user reply on that??
On the postmark website it says:
Since Postmark is not a mailbox provider there's not the ability to generate mailboxes for receiving email using IMAP or POP3.
Question 1) Does the SMTP relay server is actually a different physical machine from IMAP server for sending/receiving messages. I guess both are different but why are these companies not providing solutions like zoho. Pardon me if I did not understand the use case.
Question 2) What to do in this case ???. My case is simple. I send notifications to customers regarding their orders. If they want they can reply or enquire. I receive the email on my phone and I can reply on the same mail-chain like we have on Gmail.
Question 3)
Do i need to buy some another service along with these to receive and reply back on the email ??? Like from godaddy or somewhere else.
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.
I am using moodle2.6.2 with essential theme.
I have created the smtp settings with gmail account, it was working fine.
If i changed my webmail account ,it shows the error like this,
"Sender address rejected: not owned by user rathish#mywebdomain.com".
Anybody can help me ?
I wouldn't recommend using Gmail or Google apps for sending emails from Moodle.
Gmail has a daily limit for sending emails and it won't allow sending emails from aliases - the email account has to exist.
http://docs.moodle.org/26/en/Email_setup_gmail
Check with your web host, they will probably have smtp - but also check their email sending limits too - I've had a site suspended because because too many emails going out.
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.