Logging on to GMail accounts: This app isn't verified


Hey folks! I failed to run the gauntlet of Google’s OAuth2 verification process, so our credentials have been revoked. I’m working on getting new ones. The relevant Github issue is here: https://github.com/mailpile/Mailpile/issues/2222

In the meantime, this means accessing a GMail account using Mailpile looks a bit hostile and scarier than it used to and you will get e-mails warning you about an insecure app (Mailpile) accessing your account. Nothing has really changed, it’s still the same old Mailpile doing the same old things, but Google doesn’t trust us any more.

This is what the authentication flow looks like for now:


For further clarity (sorry if I’m stating the obvoius):

This authentication flow comes up when a Mailpile account with a gmail.com address is set up for the first time. After that, when email is received or sent to that GMail account by the same instance of Mailpile (same workdir), authentication is automatic and there are no further requests for authorization by the user. Authentication is automatic even if the user quits Mailpile and then runs it again.

It also comes up the first time that Mailpile accesses a GMail account which was set up before the new “verification” requirement came into effect.

If a new Mailpile instance (new workdir) is set up, authorization will be required the first time that instance acccesses the GMail account.

Tested this today with commit e86d5ba8 which was master on 2019-07-11.


I’m wondering if Google can reasonably be asked to change some of the scary language in the authentication screens.

It’s OK for Google to say This app hasn’t been verified by Google yet. Only proceed if you know and trust the developer. That is good advice.

But, the line Go to Mailpile (unsafe) is defamatory. Google has no evidence that Mailpile is unsafe and should not say that it is. IIRC the screen that follows after this one (Bjarni doesn’t show it) contains additional objectionable uses of the word “safe”.

Even if Google “verifies” an app, does that ensure that the app is “safe”? Is Google really going to do an in-depth security audit of tens or hundreds of thousands of lines of code to verify that every app is safe? We all know that it is possible to create a back door (intentionally or not) with a few lines of code hidden in some otherwise innocuous module. It is probable that there are undiscovered vulnerabilities even in Google’s own API code. The idea that Google can magically find or prevent every possible vulnerability is absurd and arrogant.

Safety or the lack of it is not a binary property, but a continuum. Many of us feel that it is “unsafe” to use Google itself!

Pardon the rant. But, this is something that government anti-competition regulators should be looking at.


I agree. Their use of language is offensive and it is very tempting to think there are anti-competitive reasons for it. But I have no idea how to raise the issue anywhere it’s likely to make a difference.

Thanks for helping test this BTW, it’s great to have another set of eyes on this.


Thank you @JackDca for sharing your insights, effort and remarks.

I really dislike where this is going. Google hurts the open source community - and especially smaller projects like Mailpile. Google contributing towards a more secure internet is bad, but this methodology is really bad.

It would be preaching to the choir here, but I’d recommend not using Google if that is a viable move. But as to the best alternative, that is a hard one. ProtonMail and Tutanota come to mind, but they don’t have a way to interface with IMAP/POP3 - except for the first one, with a bulky extra application they call a “bridge”.

I am actually in the process of contacting all mail providers that refer to themselves as secure or respective of privacy with a questionnaire. Combined with known information, I am compiling an extensive overview of email providers, the pros and cons. A bit like this comparison but much more detailed.

Besides self-hosting there are some pretty neat alternatives :slight_smile:


Brand-new member, jumping right into the deep end…

Speaking individually, this is good advice, but as for MP itself, it still needs to support gmail accts relatively painlessly (y’know, eventually), at least as long as gmail maintains its elephantine user base.

@h3artbl33d , looks like you’re one of the core people here, so I expect you know that … I guess it just wasn’t clear from your post (to me, at least) that your intent was to advise users, as opposed to dropping MP support for gmail.


looks like you’re one of the core people here

Sorry - no, I am not a project member, just an enthusiast user :slight_smile: At least, at this moment.

Speaking individually, this is good advice, but as for MP itself, it still needs to support gmail accts relatively painlessly

I agree that MP should support Gmail. At least with custom domains, they are the most used mail provider (judging from the global MX records). GoDaddy seems to make a good second to my suprise :wink:


You realize that you are the 2nd most prolific person in this community, 2nd only to Bjarni? And it sounds like you know MP pretty well, too… Allow me to be the first to welcome you to the project. :wink:


Thank you for your warm words and welcome :slight_smile: I certainly hope to evolve in a (code) contributor some day. As for now, I help everywhere I can.


More on the “Less secure apps” issue:

I have several gmail accounts that I use for testing purposes. I have been using these for months, in some cases years.

IIRC I did not have to explicitly turn on either IMAP access, or “Less secure apps” access when I first set up these accounts.

In the last few weeks, perhaps in the last week (can’t pin it down because I was caught unaware and was not taking notes), IMAP access has been disabled, and/or “Less secure apps” been disabled for some of them. There were no notification emails from GMail in any case, other than the original “This app isn’t verified email” which was sent back in June. In at least one case, IIRC, both IMAP access and “Less secure app” access was turned off a day or two after I had explicitly turned on both. I have not been able to figure out the pattern.


Quoting @BjarniRunar above, “I have no idea how to raise the issue anywhere it’s likely to make a difference.”

Agreed, it’s unlikely that Google can be convinced to change their behaviour on this one issue.

One possible action is to bring the issue to the attention of government agencies that are responsible for monitoring anti-competitive actions by big corporations. For example, in my country, the Competition Bureau (a Canadian government law enforcement agency) on 2019-09-04 published a “call-out to market participants for information on potentially anti-competitive conduct in the digital economy”’. Comments close 2019-11-30.

On the down side, preparing a good submission to a government agency is a lot of work and not rewarding. As in the case of a lot of social justice work, knowing that you are on the side of the angels has to be its own reward, because the effect of one submission is usually imperceptible. On the other hand, this is the only way that things get better! Maybe I’ll find time to do this in Canada.

Is there anything similar happening in the European Community?


I can report that progress (slow, but progress) is being made with the verification process. We’re currently putting together a Youtube video that meets their procedural requirements, and I did get e-mail from them which indicates my messages so far aren’t going into the void.

So this isn’t stalled or hopeless, yet.