Google hates Mail.app
May 14, 2020 11:23 AM Subscribe
When I send email from any of my Gmail addresses using Mail.app, Google now drowns me in security alerts. Details inside...
First off, I am, for reasons, stuck using a very old iMac running OSX 10.9.5. I use Apple's Mail.app (v7.3) to manage four different Gmail accounts. If it maters, they are all POP accounts, because I don't need the multi-device feature of IMAP. Things have been running just fine for several years until a couple of weeks ago.
It began one Monday morning, when I started Mail.app and it contacted my Gmail accounts. I suddenly received a deluge of security alerts saying "A new device just signed in to your Google Account. You're getting this email to make sure it was you." Additional alerts were also sent to the recovery mail accounts. I, of course, had to go to the Gmail website and log in to each account to let it know that, yes, that was me. Doing this, though, seemed to generate more security alerts, and this vicious circle continued most of the morning. Accidentally, I found that, if I just went in and checked my security settings, this seemed to placate Google, and the alerts finally stopped.
This was just as lock-down started, and my email sending has kind of dropped to zero. Mail.app retrieving emails from the Google servers doesn't seem to bother them anymore. Today, though, I replied to an email I had just received (using my main Gmail account) and immediately got a security alert. Once again, I went to the Gmail website, logged in, and confirmed it was me. I'm crossing every finger I have, in hopes that that will be all for today. But, of course, this makes me wary of every using my Gmail accounts.
I cannot find anything in the Gmail security settings to tell it to trust this device.
Is there anything I can do to stop this from happening, or is this the new normal for those of us unable to keep up with the times, tech-wise? Logging into each account using the Gmail site is not a viable option.
FWIW, I do not have 2FA activated on any of the accounts. Mostly because I don't exactly understand the process or if my old version of Mail.app is even able to handle 2FA (or if it even needs to. I honestly don't understand the process.)
Additional FWIW...A couple of months ago, before this all began, I started having another issue with Mail.app and my Gmail accounts. Sending emails from any of the Gmail accounts suddenly started taking forever to leave. Any outgoing Gmail would sit in my Outbox for 30 seconds or so before it would eventually send. Just a basic text-only email would just sit and sit and sit. Email sent from a non-Gmail account would leave immediately, just as the Gmails used to do. This behavior continues.
Any help/suggestions will be greatly appreciated.
Thanks.
First off, I am, for reasons, stuck using a very old iMac running OSX 10.9.5. I use Apple's Mail.app (v7.3) to manage four different Gmail accounts. If it maters, they are all POP accounts, because I don't need the multi-device feature of IMAP. Things have been running just fine for several years until a couple of weeks ago.
It began one Monday morning, when I started Mail.app and it contacted my Gmail accounts. I suddenly received a deluge of security alerts saying "A new device just signed in to your Google Account. You're getting this email to make sure it was you." Additional alerts were also sent to the recovery mail accounts. I, of course, had to go to the Gmail website and log in to each account to let it know that, yes, that was me. Doing this, though, seemed to generate more security alerts, and this vicious circle continued most of the morning. Accidentally, I found that, if I just went in and checked my security settings, this seemed to placate Google, and the alerts finally stopped.
This was just as lock-down started, and my email sending has kind of dropped to zero. Mail.app retrieving emails from the Google servers doesn't seem to bother them anymore. Today, though, I replied to an email I had just received (using my main Gmail account) and immediately got a security alert. Once again, I went to the Gmail website, logged in, and confirmed it was me. I'm crossing every finger I have, in hopes that that will be all for today. But, of course, this makes me wary of every using my Gmail accounts.
I cannot find anything in the Gmail security settings to tell it to trust this device.
Is there anything I can do to stop this from happening, or is this the new normal for those of us unable to keep up with the times, tech-wise? Logging into each account using the Gmail site is not a viable option.
FWIW, I do not have 2FA activated on any of the accounts. Mostly because I don't exactly understand the process or if my old version of Mail.app is even able to handle 2FA (or if it even needs to. I honestly don't understand the process.)
Additional FWIW...A couple of months ago, before this all began, I started having another issue with Mail.app and my Gmail accounts. Sending emails from any of the Gmail accounts suddenly started taking forever to leave. Any outgoing Gmail would sit in my Outbox for 30 seconds or so before it would eventually send. Just a basic text-only email would just sit and sit and sit. Email sent from a non-Gmail account would leave immediately, just as the Gmails used to do. This behavior continues.
Any help/suggestions will be greatly appreciated.
Thanks.
Mail.app is up to version 13.4 right now, so it's possible gmail changed some security settings that aren't contemplated in your very old version of Mail.app.
You should check the Mail.app settings for your gmail accounts to make sure that port 587 with "Use TLS/SSL" checked and "Authentication > Password" selected is specified for outgoing email. You may also want to go into the security settings for your gmail accounts and enable "use less secure apps."
posted by slkinsey at 12:31 PM on May 14, 2020
You should check the Mail.app settings for your gmail accounts to make sure that port 587 with "Use TLS/SSL" checked and "Authentication > Password" selected is specified for outgoing email. You may also want to go into the security settings for your gmail accounts and enable "use less secure apps."
posted by slkinsey at 12:31 PM on May 14, 2020
It's not just Gmail and Mail.app because I use Outlook on my Macs and this happens to me on occasion. There's a Gmail security setting that says "Allow less secure apps to run..." or something like that; you have to login to your actual gmail account using a browser to tick that. Once you do, it will cut down on the amount of security warnings you get. They won't be completely eliminated, but it will seriously cut them down.
There are a two other things that trigger the stupid security warnings on my Macs:
1. If my VPN uses a different ip address than I previously used with Gmail through Outlook.
2. If I login on a different device, like a laptop I haven't used in a while or a new phone.
Google just wants to try to force us to use gmail in the browser, imo. There should be a setting in gmail that we can tweak once to prevent this from happening after we allow each device.
posted by LuckySeven~ at 12:31 PM on May 14, 2020
There are a two other things that trigger the stupid security warnings on my Macs:
1. If my VPN uses a different ip address than I previously used with Gmail through Outlook.
2. If I login on a different device, like a laptop I haven't used in a while or a new phone.
Google just wants to try to force us to use gmail in the browser, imo. There should be a setting in gmail that we can tweak once to prevent this from happening after we allow each device.
posted by LuckySeven~ at 12:31 PM on May 14, 2020
Best answer: They won't be completely eliminated
at least in part because Google will occasionally turn Allow Less Secure Apps off again, apparently just for shits and giggles. It's infuriating.
Mail.App is nothing special as far as email clients go. If you'd be willing to give Thunderbird a try instead, the current version works on OS X 10.9 and supports the use of OAuth2 to secure connections to mail accounts, which is the "more secure" method that Google will not grief you for using. Feed Thunderbird's first run wizard a Gmail address and it even sets that up automagically.
posted by flabdablet at 12:51 PM on May 14, 2020
at least in part because Google will occasionally turn Allow Less Secure Apps off again, apparently just for shits and giggles. It's infuriating.
Mail.App is nothing special as far as email clients go. If you'd be willing to give Thunderbird a try instead, the current version works on OS X 10.9 and supports the use of OAuth2 to secure connections to mail accounts, which is the "more secure" method that Google will not grief you for using. Feed Thunderbird's first run wizard a Gmail address and it even sets that up automagically.
posted by flabdablet at 12:51 PM on May 14, 2020
You could also try generating an app password and using it (with the same account name) instead of your normal password to log in. As far as I can tell, this is the closest thing Google has to an officially sanctioned way of accessing your email via standard (non-Google) APIs. I believe you'll have to turn on 2FA, but you won't be asked for 2FA when you log in with the app password.
posted by panic at 3:55 PM on May 14, 2020 [1 favorite]
posted by panic at 3:55 PM on May 14, 2020 [1 favorite]
Response by poster: You may also want to go into the security settings for your gmail accounts and enable "use less secure apps."
Just jumping in to say that I have never been able to find this setting in any of my Gmail accounts’ settings. I’ve heard about it, but haven’t found it.
posted by Thorzdad at 6:19 PM on May 14, 2020
Just jumping in to say that I have never been able to find this setting in any of my Gmail accounts’ settings. I’ve heard about it, but haven’t found it.
posted by Thorzdad at 6:19 PM on May 14, 2020
Here's a process that should get you there. It's not the only one but I don't know any tidier way to avoid derails down false trails.
1. Open accounts.google.com in a new private or incognito window.
2. Log in with your Gmail email address and password. This should take you to a page with a URL of https://myaccount.google.com/ titled "Google Account" .
3. In that page's left-side navigation menu, click Security. This should take you to a page with a URL of https://myaccount.google.com/security still titled "Google Account".
4. Scroll nearly to the bottom of that page, and in the right pane you should discover a panel headed "Less secure app access". Follow your nose from there.
posted by flabdablet at 12:52 AM on May 15, 2020
1. Open accounts.google.com in a new private or incognito window.
2. Log in with your Gmail email address and password. This should take you to a page with a URL of https://myaccount.google.com/ titled "Google Account" .
3. In that page's left-side navigation menu, click Security. This should take you to a page with a URL of https://myaccount.google.com/security still titled "Google Account".
4. Scroll nearly to the bottom of that page, and in the right pane you should discover a panel headed "Less secure app access". Follow your nose from there.
posted by flabdablet at 12:52 AM on May 15, 2020
Response by poster: Is your outbound mail set to go through port 587? I don't know how or do this in Mail.app, but sending via port 25 or 465 is what you used to do, but now they are enforcing that those ports are for other mail servers to connect to, not clients. Clients should use port 587.
Sorry for the threadsit. I checked and my Gmail accounts are set for port 995 (not 25 or 465) I re-set them to 587.
Also, currently TLS is set to "None". When I toggle it, there is a choice between two certificates. I have no idea which to use, or if it matters.
Also, also, I found the "allow less secure device" setting, at it was already set to allow.
posted by Thorzdad at 3:54 AM on May 15, 2020
Sorry for the threadsit. I checked and my Gmail accounts are set for port 995 (not 25 or 465) I re-set them to 587.
Also, currently TLS is set to "None". When I toggle it, there is a choice between two certificates. I have no idea which to use, or if it matters.
Also, also, I found the "allow less secure device" setting, at it was already set to allow.
posted by Thorzdad at 3:54 AM on May 15, 2020
Port 995 is the right one for POP3 over encrypted connections, so if you've changed any POP3 server settings away from that I'd recommend putting them back. Ports 25, 465 and 587 are for outbound mails going via SMTP, not inbound mailbox fetches via POP3.
Fastmail has a good backgrounder on the history and use of these port numbers, if you're interested.
TL/DR: set your mail client up to use secured connections, via port 993 for IMAP servers, port 995 for POP3 servers, and port 465 for SMTP servers.
There are real though somewhat unlikely ways for a client that's been told to use STARTTLS over port 587 with its outgoing SMTP server to end up being tricked into sending passwords over the wire in plain text, which is why Google describes this authentication method as "less secure". No such loopholes exist for the implicitly secured connections that are the only kind that mail servers have ever supported on port 465.
Picking port 465 rather than 587 has the bonus advantage of really annoying the kind of Internet pedant who continues to insist that 465 Isn't The Standard and is therefore The Wrong Thing while failing to notice that the de facto standard actually became the official standard in 2018.
posted by flabdablet at 5:37 AM on May 15, 2020
Fastmail has a good backgrounder on the history and use of these port numbers, if you're interested.
TL/DR: set your mail client up to use secured connections, via port 993 for IMAP servers, port 995 for POP3 servers, and port 465 for SMTP servers.
There are real though somewhat unlikely ways for a client that's been told to use STARTTLS over port 587 with its outgoing SMTP server to end up being tricked into sending passwords over the wire in plain text, which is why Google describes this authentication method as "less secure". No such loopholes exist for the implicitly secured connections that are the only kind that mail servers have ever supported on port 465.
Picking port 465 rather than 587 has the bonus advantage of really annoying the kind of Internet pedant who continues to insist that 465 Isn't The Standard and is therefore The Wrong Thing while failing to notice that the de facto standard actually became the official standard in 2018.
posted by flabdablet at 5:37 AM on May 15, 2020
currently TLS is set to "None"
If you actually mean that TLS Certificate is set to None, that's OK. The effect of that is that the server you're connecting to won't be able to verify that you are who you claim to be until after you've already established an encrypted connection session with it.
Your end can be confident that it's getting a genuinely end-to-end encrypted session with a server belonging to Google, because it will check the server-side TLS certificate while establishing the connection; the principle is that no man-in-the-middle attacker can spoof that certificate because ultimately the check can only succeed against a certificate signed with a secret key that only Google has.
So once that's happened, your end then has to run a login process over the encrypted connection to convince Google's mail server it's allowed to give you access to your account.
Client-side TLS certificates are typically used to let work computers authenticate themselves to corporate mail servers, where getting them installed on client machines and managing revocation and so forth can be problems that belong to corporate IT departments rather than end users. Free Gmail accounts don't use them.
posted by flabdablet at 6:57 AM on May 15, 2020
If you actually mean that TLS Certificate is set to None, that's OK. The effect of that is that the server you're connecting to won't be able to verify that you are who you claim to be until after you've already established an encrypted connection session with it.
Your end can be confident that it's getting a genuinely end-to-end encrypted session with a server belonging to Google, because it will check the server-side TLS certificate while establishing the connection; the principle is that no man-in-the-middle attacker can spoof that certificate because ultimately the check can only succeed against a certificate signed with a secret key that only Google has.
So once that's happened, your end then has to run a login process over the encrypted connection to convince Google's mail server it's allowed to give you access to your account.
Client-side TLS certificates are typically used to let work computers authenticate themselves to corporate mail servers, where getting them installed on client machines and managing revocation and so forth can be problems that belong to corporate IT departments rather than end users. Free Gmail accounts don't use them.
posted by flabdablet at 6:57 AM on May 15, 2020
By the way, another possible cause for the initial flood of security warnings could be that your machine has ended up in a different IP address block than the one Google is accustomed to seeing associated with that account. I've had this kind of thing happen when, for example, our wonderful National Broadband Network has shat itself again and I've had to tether my laptop to my phone to get Internet connectivity back. Not with Google specifically, because I don't use Gmail any more, but I'm pretty sure they'd be doing the same kinds of tests to identify client devices.
posted by flabdablet at 7:06 AM on May 15, 2020
posted by flabdablet at 7:06 AM on May 15, 2020
Response by poster: I decided to go with flabdablet's suggestion to try Thunderbird, and this seems to be the best, simplest solution. Gmail seems to play nice with Thunderbird. It sent a "Thunderbird is now accessing Gmail" response the first time it connected. *fingers crossed*
posted by Thorzdad at 9:27 AM on May 16, 2020
posted by Thorzdad at 9:27 AM on May 16, 2020
« Older Optical repair in Seattle/Tacoma? | What is good timing for a 10k race for a 67 year... Newer »
This thread is closed to new comments.
posted by kindall at 12:19 PM on May 14, 2020