Sending emails with “allow less secure apps” turned off in Gmail

I got an email this week from Google saying they will be removing the ability to choose “allow less secure apps” when sending an email from a source other than through gmail. This is happening in the summer, and then they are removing this altogether in September I think

I have a desktop and a web app that use one of my Gmail accounts to send emails, and if I remember correctly, I had to check the box in my Gmail settings to “allow less secure apps”. Otherwise, the emails wouldn’t send

With this going away, how will this be accomplished? I would like to start working on this now rather than later. I’m not sure if the one account that sends the emails has 2-step verification in place, but I’m also afraid to do this or anything else prematurely. Do you know what needs to be done if less secure apps is unchecked and the app can still send emails?

If you only send yourself emails then use an app-specific password. If you send emails to your users: if you don’t send too many emails use SendGrid. Otherwise go to AppSumo and buy yourself something with an API.

See this post about setting up an app password for your application to use

https://forum.xojo.com/t/send-email-with-attachment/70816

Far as I know Google enforced all this a couple of years ago. But I did find that if you enable two-factor-authentication for your google login, then in your google account’s security section ask for an app-specific password, you can use that for pop3 login to your gmail server.

I have a drop in replacement class for sending EmailMessage with Mailjet instead of SMTPSocket. GitHub - devtimi/Mailjet: Xojo class for sending transactional email via Mailjet

I’m not sure who the best transactional email service is, but that’s what I use and have available.

1 Like

Will be needing to send both to myself and to users

Great walkthrough on that post. The app-specific password should still work when sending an email to the user, right? It sounds like it should from that post, but Beatrix mentioned only for sending to yourself. Hoping that’s not the case

I recall seeing this move some years ago too, but they maintained the less secure apps, at least for one of my accounts

Good to know. I’ll take a look at this too. Thanks!

Thanks for the replies all. This was helpful

Yes the app password does work and will work going forward. The caveat is that if the primary password of the account is changed all app passwords are dropped. So you have to setup another one if you ever change the primary password.

Public mailbox providers are slowly moving towards OAuth2. Partly because it’s more secure and partly to reduce breaches of privacy regulations. We have had two large UK providers attempt to remove app-passwords already. The challenge has been the majority of end users clinging to what they already know and being unprepared and unwilling to change how they do things.

You can avoid being beholden to the mass market providers by registering your own domain name. Some registrars will throw in a mail forwarder which may be all you need. A cheap cPanel account will get you your own mailserver for peanuts.

Fully agree. Don’t forget that the dkim, spf and dmarc thingies need to be set correctly by the end of the month. I’ll also bet my behind that Goggle really doesn’t like anyone sending mass emails from Gmail anymore.

Business accounts can, but you have to slowly ramp up otherwise they start pushing your emails into people’s spam buckets.
By slowly ramp up I mean start off with a few hundred / week, then double that, rinse and repeat until you hit a thousand. Once you are doing that amount you can generally add about 500 or so every other week. Regardless, you have to have someone monitoring things and you will need to work with a Google representative to make sure you can adjust things in case they start to go south. It is not a super smooth or easy process, but it is doable.
If you have your own domain and you are sending to a lot of gmail accounts you have to gradually ramp up too.

I ran my own email server for longer than I can be sure of, but 20 years sounds about right. The best advice I can give after all these years of experience is simple: don’t run your own email server.

As a user, your spam detection will suck. SpamAssassin does not compare to Google’s spam detection. It’s not even in the same ballpark. This is simply a matter of volume. As the largest email provider in the world, Google can detect patterns far faster than SpamAssassin ever will. It’s something I was tinkering with a tuning often, but I’d always have plenty of false positives and negatives. After years of feeding SA training data, it really didn’t improve.

When sending to your customers, your email server will suffer reputation problems that hurts deliverability. Even with DKIM, DMARC, and SPF setup perfectly you just won’t achieve the deliverability that you’ll get with an email provider. My best results came from Postmark, but there are others. I strongly recommend not sending customer emails out of Google, either transactional or marketing.

In terms of administration, your email server will be a house of cards that you won’t want to touch out of fear of breaking something. You’ll put off server upgrades for the same reason. You don’t want to be held back by this concern. Unless you are using something like Ansible to ensure you can replace your email server at any moment - which you won’t with a cheap cPanel server - just don’t do it. That ignores the issue of data migration too.

The price I pay to Google Workspaces and Postmark monthly - $12 and $10 respectively - is peanuts compared to the sanity spent on maintaining my own server for worse results.

And for the record, I love running my own servers. I have a network of 5 servers that run my website around the globe. I can delete any of them at any moment and have them perfectly replaced in about 20 minutes. With 4 of them, customers would never notice.

It took a long while to let go of running my own email server. It felt wrong. But it’s been one of the best business decisions I’ve ever made.

9 Likes

IME the app-specific password works for sending to anyone.

Confirmed. Just tested this with sending to several of my other email accounts and not only to my account sending the email

My next question I think I already might have the answer but want to check with you all. My desktop app already uses the one gmail account with the less secure apps setting marked. If I implement the 2-step verification and the app password on this account, will emails still be sent with both versions of my app? Meaning some users will still be on the current version of the desktop app that sends emails with the “less secure” method. If I push out today an update to the app with now using the app-specific password, and some users don’t update, will their apps still send messages, or will that cease and only the updated version with the new app password send?

I have a feeling the old “less secure” versions will cease once 2-step/app password is enabled. If this is the case, I will just use one of my other accounts for the time being

Why does this require a change to your app? All you’ve done is change the password for that account.

I use the MailSocket and have the UN and PW saved as constants at the app level. I assume I need to change the PW in the constant to the new app password, yes?

MailSocket.Username = app.kMailUN
MailSocket.Password = app.kMailPW

If you have all that hard-wired, then yes.

Yes, it works. But Goggle doesn’t like that. As a result your delivery rate will decrease.

I’m pretty sure that 2-Step only comes into play when logging on to the account via the web.

That’s right. But it’s the price you pay for being allowed to be issued with a password that works for a pop3 client to pick up mail from the gmail mail server.

I agree the days of dedicating an old PC to run your own mail server for day to day business use are over. There is still a business case for specialised uses, like m2m relay and forwarding. Shared cPanel accounts are so cheap these days it’s sort of rude not to.