Gmail with Hermes

Has there been a change in Gmail May 2019 – Hermes is reporting Web login required?

Yes – passwords don’t appear to work any more in non-Google apps. You probably need an application specific password. See https://support.google.com/accounts/answer/185833?hl=en

Based on some of that info, you may find that NetFetch/Hermes 5.5 provides better results, by virtue of absolute latest SSL/TLS. However, it isn’t clear if Google’s definition of “less secure apps” is “apps we haven’t tested/approved” or “apps using older SSL/TLS standards”.

In general, gmail (used to?) require(s) you to go to your account page and enable “less secure apps”. This then fixed any login problems. The “app password” may also now be required based on what Rick linked, although how that interacts with the “less secure apps” setting is somewhat unclear.

Oh, Andrew, stop being naïve.

We’re talking about Google here.

it isn’t clear if Google’s definition of “less secure apps” is “apps we haven’t tested/approved” or “apps using older SSL/TLS standards”.

The definition is very simple. You are not using their GMail app. Therefore… insecure, unapproved, die mortal human scum, panic bells, warning lights, awooga…

I don’t know about the “less secure” setting. I may have set that ages ago when using Android’s default mail client (because I absolutely hate the behaviour of the GMail app), however what is new is the refusal to use the standard login password. If you try, you’ll either get told that an application password is required in the server error response, or the server will just ditch you. It no longer supports STARTTLS at all.

So instead of a password, you need a special sequence of gibberish. And when you have it, you need it for both sending and receiving.
Note the gibberish down – it doesn’t seem possible to view an app password later on. I had to generate a second one because my K-9 Mail SMTP part wasn’t set up correctly (wrong port, for some reason) and it wanted the password entered again.

although how that interacts with the “less secure apps” setting is somewhat unclear.

I think it is supposed to be:

• Less secure apps NOT SET – no access to email outside of GMail app
• Less secure apps SET – IMAP/POP3 access to email with app specific password

Of course, I look at that and wonder how secure GMail is. After all, wouldn’t it be using the underlying IMAP system like any other mail interface?
Part of me thinks these hoops are to “allow third party email access, but make it difficult so you prefer to use our app instead”. :-/

The definition is very simple. You are not using their GMail app. Therefore… insecure, unapproved, die mortal human scum, panic bells, warning lights, awooga…

The behavour of google and android machines and the use of your gmail address is hard enough to get a handle on, but secure connections refer to OAUTH2 connections, another level of authorising on top (of TLS I guess)
Insecure can be either STARTTLS on port 587 or straight TLS on port 465.
STARTTLS has lost favour because the textual transmission of STARTTLS can serve as a mail start marker for ‘someone who can’ unencrypt the following data. (so I read somewhere).

Of course, I look at that and wonder how secure GMail is. After all, wouldn’t it be using the underlying IMAP system like any other mail interface?

I’m going to assume that GMail doesn’t use the old IMAP on port 143 and actually uses the IMAP over TLS/SSL on port 993.
Assuming the use of port 993 the TLS revision might have been raised. We can now say we don’t care about the revision as we have a modern implementation, but anyone using the old implementation might have problems.

Part of me thinks these hoops are to “allow third party email access, but make it difficult so you prefer to use our app instead”. :-/

Complete with a Google ‘backdoor’ knowing them, although “use a defined standard, but don’t name it, then we can say we aren’t restrictive but make it difficult to use third party apps/software by adding our own layer (that’s actually not security but just an impediment to third parties)”

Ronald is correct – Google now want POP/IMAP/SMTP user authentication to be handled via OAuth instead of letting apps store and manage the usernames & passwords directly. Here are the relevant docs for how OAuth integrates with the protocols.

However, digging deeper reveals the news that applications may only be granted approval to use the OAuth APIs if they have their apps undergo expensive yearly code audits. Security audits == good, high costs == bad.

code audits.

Ah, the good old payback element where they filch bits of your code.
That couldn’t be true, I mean Google would never steal any ideas, would they?
What’s that you say? Even a google search turns up examples of just that…

It’s a “certified third party” which will be doing the assessment and not Google.

Also (having now found the relevant note hidden in their mountain of docs), local client applications may not need to be subjected to the audit procedure – it’s mainly server-hosted systems (or systems that send Gmail data to non-Gmail servers) which they’re worried about.

Well using NetFetch 5.50 I can download and send emails via GMail, pop/smtp, but as discussed I have to put in the app specific password in place of my normal one.

I do not have the “use less secure apps” option available or set in my Google security settings.

Hope that helps.

I do not have the “use less secure apps” option available

It is usually set at the actual gmail server settings by using a capable browser.
Jeffrey, someone has had OAUTH2 and gmail working for linux fetchmail in the past, dont see any recent updates so cant say for sure currently. They tend to use python scripts.
The person who did the work stated it was doubtful any security advantage over passwords and changing them regularly.

Have try the follow…
Set my GMail account in MPro 8.02 by using “simple pop” and a loaded SecureG-module to use SSL.
Set up “less secure apps” via Otterbrowser with the German version of this help
and pop download for my gmail account.
For me is working fine.