On Sun, 3 Dec 2023, Damion Yates wrote:
Lucio Chiappetti <lu...@lambrate.inaf.it> wrote:
I am quite concerned about the moves of gmail moving away from IMAP
sometimes next year. I am seeking solutions ...
Sorry what?! So you have a reference to this notice?
I might have misinterpreted what I read on the fetchmail mailing list,
which I include here
F> Seems that Google have defined the total phase out:
F>
https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html
F>
F> seems that 'app password' still will be supported:
F>
F>
https://knowledge.workspace.google.com/kb/how-to-generate-an-app-passwords-000009237?hl=en
On Sun, 3 Dec 2023, Eduardo Chappa wrote:
IMAP will continue to be supported by Gmail, what will not be supported is
that you use username/password authentication. Instead you will have to set
up Oauth2, which you can do with Alpine. I recommend that you upgrade to the
latest version of Alpine, which has the best Oauth2 support.
Thanks Eduardo, but as I said my usage of Alpine+Gsuite is for "occasional
maintenance" (once per day or less, for cleanup). My main delivery agent
is fetchmail, which allows to work with all my old extensive set of
procmail rules "as if I were receiving directly". And the use Alpine
"locally".
BTW some of those procmail rules do deal automatically with some
form-generated messages to update some institute database as a service for
my institute. Renouncing to them would be a real pain.
I would not be happy to compile fetchmail from source (I use the
OS-bundled version).
Also it is not clear to me whether a crontab-invoked fetchmail (or
replacement) can use Oauth2.
Probably yes. I am very ignorant of Oauth2, which I suffered as a nuisance
(I have an oauth2 txt file generated years ago which I use in conjunction
with GAM (the Gsuite administration line mode interface) and that is
invoked by a crontab script (essentially to verify a list of addresses is
set up). That's why I ask here, where there are competent and kind
persons without vested interests.
I always use GAM from a single machine (my work machine, which has a
static permanent public IP). I ignore how it links with Oauth2 unless it
is simply because the file resides in the same directory as the
executable.
Considering instead using Oauth2 (e.g. with Alpine) from different
machines, or from a dynamic CGNAT private IP, as if it would be the case
if I'd use my home machines (which currently do not do, byt maybe will do
sometimes), will the "Oauth2 txt file" (or key, or whatever is called) be
locked to a static IO, or a MAC address, or be "portable" ?
Sorry for the naive questions.
And thanks to whoever replies anyhow ...
_______________________________________________
Alpine-info mailing list
Alpine-info@u.washington.edu
http://mailman12.u.washington.edu/mailman/listinfo/alpine-info
