OAuth isn’t really doable right now and I’m not sure how much that will change - it’s a flow that requires interaction and a browser component, which makes it less than ideal for use in scripting or a backend process like alarm notification.
It might turn out that it’s possible to set it up once on the Ignition gateway and have it not expire for a long time but I’m not sure right now.
Your best bet is to switch to a paid mail service other than Gmail/GSuite if you don’t have your own internal IT department running a mail server.
As SMTP support is getting tougher and tougher ( Email still using TLSV1) I have been migrating some of my other systems over to a mail sending service that can more easily evolve over time. It seems to be easier to support and requires my apps don’t need to deal with SMTP.
The most recent one I like is MailGun. https://www.mailgun.com/ Its basically email for devs and backends where all interaction can be done via REST and webhooks. It might be something to look into an option for notifications and such in Ignition to support some type of REST style email service in the future.
You seem to know more about email than I do, so maybe you can answer a question I have. Could a service like MailGun be used to get around my problem with GSuite? What I mean is, could I connect Ignition to MailGun and then have MailGun relay emails through GSuite using an OAuth connection?
The reason I’m thinking about this is because I currently have GSuite sending emails from addresses in my domain (i.e. firstname.lastname@example.org). I would prefer to continue using this address. My alternative would be to sign up for MainGun with a different domain like email@example.com.
I’m also assuming I can’t have two services sending emails from the same domain. If this is not the case, I wouldn’t mind moving the firstname.lastname@example.org from GSuite to another service, but continuing to use GSuite for other accounts.
You can have multiple services sending emails for the same domain… Any server can send emails for your domain provided you have the right setup.
The easiest would be to use another mail service for sending. Do you have a webhost or something? A internal email server beyond gmail? All you need is an SMTP relay, you could even add an SMTP server to the Ignition server if you want. The trick (and every email service is different) is to ensure the security and domain settings are correct to ensure you messages are not flagged as spam/phishing… GSuite should be able to walk you through the correct settings somewhere.
Mailgun does offer outbound SMTP services as well, so it would be worth a shot. They seems good at being easily to setup and walked me through all the domain configuration when I did it. They you would just connect Ignition to their SMTP service.
I will look into using another mail service to send alarms for Ignition while keeping GSuite for other accounts. MailGun or some other service sound like they may be what I need. We don’t have our own mail server outside of gmail, but I may try to set one up on Azure someday.
We had a Gmail account for a customer for sending reports/alarm emails stop working at the end of May. Is SMTP going to be a long term solution for email notification from Ignition if providers are ending their access to it? The customer’s IT was unable to get their Zoho email connected to Ignition due their security policies which is why we gave them a Gmail account. Just wondering if eventually we will have the same problem in the future even if we do switch to a new Email provider.
We’re working on OAuth client support in Ignition as well as an Email profile type that can use a configured OAuth client, which should let you switch from the away from “Less Secure Apps” setup when it’s ready.
You’re willingly adding a 3rd party cloud dependency. You’re at their whim, and something can always change or go wrong.
Yup. Running a mailserver is not trivial, but it isn’t rocket science either. My tiny company runs its own (that is, me), and I run another for my family. I’d have fired Zoho for not helping prepare a secure path. It can be done without OAuth.