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.


I’m a newbie here and I’m trying to evaluate this app which sounds really promising.
I’m struggling w/ the same issue reported here and apparently there’s no way to work around it nor w/ Firefox nor w/ Chrome. I cannot authorize the app.
Any hint?


Hello @simahawk

Last time I looked (a few weeks ago now) I was still able to set up Mailpile to use Gmail acounts, though it certainly is painful. For details see my last post to Issue 2222 on Github:


@JackDca hi,

thanks for your reply. Tried several times as described there (was the same thing I did already).
It does not work here :frowning:



Hi @simahawk,

l will try this with a new GMail account to check if it still works for me. It may be a day or two before I get to this. If it works for me and not for you, we should try to determine what is different. So, what is your operating system? What browser are you using? How did you install Mailpile (.deb? Github clone?) and what version is it?


Hi @simahawk,

I created a new gmail account and tried to set it up with Mailpile using the procedure that I have used before. Even though I have “Allow less secure apps” enabled on the GMail side, I can’t connect to GMail either incoming (IMAP) or outgoing (SMTP). The IMAP login gives the message “IMAP protocol error” in the Notifications window.

I also tried this with an existing Mailpile instance that had previously been set up to work with GMail. That doesn’t work any more. Same problem as above with the IMAP. When I try to send an email, there is a pop-up authentication window, but after filling in the password I get a message " Sign in with Google temporarily disabled for this app - This app has not been verified yet by Google in order to use Google Sign In."

I note that GMail presents an option to use a “application password”. Not clear on how this works, maybe I’ll try it.

Perhaps @BjarniRunar understands what has changed? I thought that my earlier tests were done after Google had already revoked Mailpile’s “verification”. But clearly, something else has changed.


I have not found a solution that allows the current Mailpile version to access GMail via IMAP. This includes some efforts to use application passwords and two-factor authentication.

I have searched the Google support pages for a clear statement of what Google is doing without any results. The closest that I have come is this page (applicable only to G-Suite users) which indicates that “Less secure apps” will be disabled completely as of 2021-02-15. I can’t find any similar statement or timetable for ordinary GMail users. My guess is that Google has decided to eliminate “less secure apps” and has done so, essentially without notice, for ordinary users of free GMail accounts, but has provided a year advance notice to its business users to avoid upsetting them.

So it appears that, unless or until someone is able to devote considerable time to navigating Google’s increasingly onerous obstacle course to get Mailpile “verified”, Mailpile cannot be used as a client for GMail accounts. Of course, this applies to any small, volunteer run “free as in speech” email client; indeed, it even would be an issue for a small commercial startup. Which of course, enhances GMail’s market share and user lock-in. Funny about that.

Strangely enough, I have one gmail account that I created a long time ago, whose IMAP interface continues to be accessible to Mailpile, although other old accounts have become inaccessible (and of course no new account is accessible). I’m guessing I turned on “less secure apps” for that account when Google first started limiting use of that option; more recently, even though the option is turned on, it has no effect.


I was able to connect to gmail IMAP with a unique system generated password.


  1. Enable 2-step verification.

  2. Create an app password .
    Choose app as “Mail” and add “Linux” as device. The system will generate a password.

  3. Back in Mailpile, in the Sending and Receiving mail settings, choose password and enter the password from Step 2.

I didn’t test sending (which I don’t care about), but it did download all my emails.


See recent comments at