[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making GNUS continue to work with Gmail

From: Uwe Brauer
Subject: Re: Making GNUS continue to work with Gmail
Date: Wed, 12 Aug 2020 08:54:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:

   >>>>>> On Tue, 11 Aug 2020 17:25:27 +0200, Uwe Brauer <oub@mat.ucm.es> said:
   >>>>> "RP" == Robert Pluim <rpluim@gmail.com> writes:
   >>>>>>>> On Mon, 10 Aug 2020 08:54:38 -0700, "T.V Raman" <raman@google.com> 
   T> soyeomul@doraji.xyz (황병희) writes:
   T> That will let you send email, not read email using gnus

   >>> You can use the same "password" in .authinfo.gpg and have it be used
   >>> for IMAP.

   Uwe> I am confused, now, the strategy (황병희) describes could work for
   Uwe> gnus, even after February 15th, 2021?

   Uwe> Then where is the problem?

   Uwe> What do I miss here?

   > The problem is that today you can turn on 'app specific passwords',
   > and generate one for Gnus to use, and thatʼs the end of it. Tomorrow
   > you need to generate an Oauth2 token by registering an 'app' with
   > Google, jumping through some more hoops, and generating a 'token' that
   > you then use with Gnus. Google can probably revoke that token whenever
   > they want, and then you need to jump through the hoops again.

   > The end result is the same: a string that Gnus uses for
   > authentication. The proces to get it will require logging into Google
   > with a browser [1], and cutting and pasting a bunch of identifiers around,
   > which is much more involved and easier to mess up.

   > The alternative is to register an 'Emacs' app, do the hoop jumping,
   > and stick the various secret tokens in the Emacs sources, but as I
   > understand it thatʼs expressly forbidden by Google's terms-of-use
   > (correct me if Iʼm wrong, I haven't read them).

Ok, now I understand the issue this is really bad and a clear example of
locked it.

   > Iʼm starting to agree with Stefan here: maybe itʼs time to start using
   > a different email provider.

Right now this is not possible for me, or at least I am not willing to
spend private money to access my work email.

In the academic world, at least 50 are using MUA and not the web
interface. This will also put an end to encrypted email, at least for smime[1]
I hope would can get around using the ideas expressed in the python
script approach.

I wonder if it makes some sense to try to talk to the google folks.


[1]  there are some solution, but it was never clear to me where the
     certificates are stored.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]