Menu
▾
▴
fetchmail-users
|
From: Andrew C A. <fet...@ai...> - 2022-04-20 09:00:42
|
On Wed, 13 Apr 2022, Matthias Andree wrote: > Am 12.04.22 um 23:18 schrieb Marco Gaiarin: > > I've followed literally: > > > > https://gitlab.com/fetchmail/fetchmail/-/blob/next/README.OAUTH2 > > > > (eg, the readme of fetchmail 7) and works as expected. Now i have to manage > > some script to refresh the token, and download the email. > > > > I've only a question, before put all that stuff in 'production'. > > > > Juergen Edner say that the OAuth client created in 'Test mode' least at > > maximum a week. > > But if i try to publish the app, i need the Google approval process, because the api used (eg, GMAIL > > API) is 'restricted'. > > > > So, it is needed to publish the app? If yes, what is the shortest and error > > prone path to get it approved? > > > Their requiring registration of the "app" (we have never called > fetchmail that) - and not solely the user for his or her own account - > is one of the reasons why I say that OAUTH2 in this form is generally a > non-starter and does not scale. > > I cannot possibly register fetchmail with each and every mail service, > and device registration is somewhat pointless anyways. There has been some discussion of fetchmail and google in the email list for alpine - another open source MUA - particularly the thoughts of the main alpine developer at https://mailman12.u.washington.edu/pipermail/alpine-info/2022-April/001162.html > So tell your mail service provider to stop that "app" registration > nonsense. I may seem pointless, but if nobody tells them, they will > never notice. Good idea. -- Andrew C. Aitchison Kendal, UK an...@ai... |
|
From: J.Edner <fli...@te...> - 2022-04-24 09:51:11
|
Hello Marco,
>> Juergen Edner say that the OAuth client created in 'Test mode' least at
>> maximum a week.
>> But if i try to publish the app, i need the Google approval process, because
>> the api used (eg, GMAIL API) is 'restricted'.
>> So, it is needed to publish the app? If yes, what is the shortest and error
>> prone path to get it approved?
>
> OK, i can confirm Juergen is true; after 7 days:
>
> /home/famiglia/fetchmail-oauth2.py -c /home/famiglia/.oauth2.conf --auto_refresh
> Traceback (most recent call last):
> File "/home/famiglia/fetchmail-oauth2.py", line 591, in <module>
> main(sys.argv)
> File "/home/famiglia/fetchmail-oauth2.py", line 502, in main
> newTok = response['access_token']
> KeyError: 'access_token'
>
> I've redone the auth with '--obtain_refresh_token_file' and now works back
> as usual.
>
>
> I perfectly agree that big G is not fair on this, but... more practically,
> how can i 'register' a (fake?) fetcmail app?
In general there is not always a requirement to get your application
verified by Google, if you set the status to "external" and
"production". This was one of the most irritating facts for me too,
as I configured Fetchmail OAuth2 access for the first time. These are
the verification rules:
Verification Status
-------------------
Google verifies projects configured for a user type of External and
a publishing status of In production if they meet one or more of the
OAuth verification criteria:
* You want to display an icon or display name for your project on the
OAuth consent screen.
* Your project's OAuth clients request authorization of any sensitive
or restricted scopes.
* The number of authorized domains for your project exceeds the domain
count limit.
* There are changes to your project's OAuth consent screen
configuration after a previous published, verified configuration.
Regards
Juergen
|
|
From: Robin A. <ro...@bi...> - 2022-04-24 14:37:06
|
On Sun, 24 Apr 2022 11:38:50 +0200
"J.Edner" <fli...@te...> wrote:
> Hello Marco,
>
> >> Juergen Edner say that the OAuth client created in 'Test mode'
> >> least at maximum a week.
> >> But if i try to publish the app, i need the Google approval
> >> process, because the api used (eg, GMAIL API) is 'restricted'.
> >> So, it is needed to publish the app? If yes, what is the shortest
> >> and error prone path to get it approved?
> >
> > OK, i can confirm Juergen is true; after 7 days:
> >
> > /home/famiglia/fetchmail-oauth2.py -c /home/famiglia/.oauth2.conf
> > --auto_refresh Traceback (most recent call last):
> > File "/home/famiglia/fetchmail-oauth2.py", line 591, in <module>
> > main(sys.argv)
> > File "/home/famiglia/fetchmail-oauth2.py", line 502, in main
> > newTok = response['access_token']
> > KeyError: 'access_token'
> >
> > I've redone the auth with '--obtain_refresh_token_file' and now
> > works back as usual.
> >
> >
> > I perfectly agree that big G is not fair on this, but... more
> > practically, how can i 'register' a (fake?) fetcmail app?
>
> In general there is not always a requirement to get your application
> verified by Google, if you set the status to "external" and
> "production". This was one of the most irritating facts for me too,
> as I configured Fetchmail OAuth2 access for the first time. These are
> the verification rules:
>
> Verification Status
> -------------------
> Google verifies projects configured for a user type of External and
> a publishing status of In production if they meet one or more of
> the OAuth verification criteria:
>
> * You want to display an icon or display name for your project on
> the OAuth consent screen.
> * Your project's OAuth clients request authorization of any
> sensitive or restricted scopes.
> * The number of authorized domains for your project exceeds the
> domain count limit.
> * There are changes to your project's OAuth consent screen
> configuration after a previous published, verified configuration.
>
> Regards
> Juergen
Juergen -
I tried publishing my "fetchmail" app but when I do the "oauth2
--obtain_refresh_token_file" step, I get an HTTP 400 error from Google.
So what's the simplest way to resolve this? Create a display name? Is
that possible without creating yet another app?
Thanks
Robin
--
----------------------------------------------------------------------
Robin Atwood.
"Ship me somewheres east of Suez, where the best is like the worst,
Where there ain't no Ten Commandments an' a man can raise a thirst"
from "Mandalay" by Rudyard Kipling
----------------------------------------------------------------------
|
|
From: Marco G. <ga...@li...> - 2022-04-27 21:40:19
|
Mandi! J.Edner In chel di` si favelave... > Google verifies projects configured for a user type of External and > a publishing status of In production if they meet one or more of the > OAuth verification criteria: [...] > * Your project's OAuth clients request authorization of any sensitive > or restricted scopes. fetchmail OAUTH2 README suggest: + I think that the scope ".../auth/gmail.modify" to "View and modify but not delete your email" is sufficient. and '.../auth/gmail.modify' scope is a restricted ones; so seem to me required to 'register' the app... But... you *have* registered the app? Your doc suggest you have not, but seems to me clear that auth done with a non-registered app last max a week... -- La virulenza delle polemiche su un argomento è inversamente proporzionale alla reale importanza dell'argomento stesso. (Legge di Potter) |
|
From: Marco G. <ga...@li...> - 2022-05-01 22:10:15
|
> But... you *have* registered the app? Your doc suggest you have not, but
> seems to me clear that auth done with a non-registered app last max a
> week...
And register the app seems a no-way:
Eseguire il push in produzione?
La tua app sarà disponibile a tutti gli utenti dotati di Account Google.
La configurazione che hai effettuato richiede che la tua app venga sottoposta a verifica. Per completare la verifica, dovrai fornire:
Un link ufficiale alle norme sulla privacy della tua app
Un video YouTube che mostri come intendi utilizzare i dati degli utenti Google ottenuti dagli ambiti
Una spiegazione scritta che motivi a Google la tua necessità di accedere a dati utente sensibili e/o riservati
Tutti i tuoi domini verificati in Google Search Console
in english:
Push into production?
Your app will be available to all users with Google Accounts.
The configuration you've done requires your app to be verified. To complete the verification, you'll need to provide:
An official link to your app's privacy policy
A YouTube video showing how you intend to use Google user data obtained from scopes
A written explanation that motivates Google for your need to access sensitive and/or confidential user data
All your domains verified in Google Search Console
All requirement out of scope, AFAIK...
--
Mi piaccion le fiabe
raccontane altre (F. Guccini)
|
|
From: Robert H. <rjh...@gm...> - 2022-05-02 12:41:53
|
The Google documentation indicates that the following apps do not need verification. The documentation for setting this up is very well hidden. I've not found it yet. The hint that I found is to follow the "Advanced" on the consent screen (https://support.google.com/cloud/answer/7454865#unverified-app-screen). Unfortunately, just that hint, not further documentation. ------------- from https://support.google.com/cloud/answer/9110914#ver-prep&zippy=%2Csteps-to-prepare-for-verification%2Cwhat-app-types-are-not-applicable-for-verification What app types are not applicable for verification? You do not need to submit your app for review if it's going to be used in any of the following scenarios: Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in. SMTP/IMAP/WP: The app is used to send emails through WordPress, or similar single account SMTP plug-ins. Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. Learn how to mark your app as internal in the FAQ How can I mark my app as internal-only? Domain-Wide Install: If your app is intended for only Google Workspace enterprise users, access will depend on permission being granted by the domain administrator. Google Workspace domain administrators are the only ones that can whitelist the app for use within their domains. To learn how to make your app Domain-Wide Install, see My application has users with enterprise accounts from another Google Workspace Domain. How does this apply to my Google Workspace or Cloud Identity enterprise accounts? Development/Testing/Staging: If your app is in development/testing/staging mode and not ready to be publicly accessible, then you do not need to submit your app for verification. Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect when an app is in development/testing/staging. If your app is for Development/Testing/Staging, it is recommended that you keep your app’s publish status set to Testing and only update to In Production once it is ready for public use. If your app’s publishing status is set to “Testing” and not “In production”, then you do not need to submit your app for verification. Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect when an app is in development/testing/staging. Learn more about Publishing status. Service Accounts: When your app is trying to access data from users' Google Cloud project and can run API requests on its behalf. To understand what service accounts are, see Service accounts. For instructions on using a service account, see Using OAuth 2.0 for Server to Server Applications. -- Robert Horn rjh...@gm... |
|
From: Marco G. <ga...@li...> - 2022-05-10 21:10:24
|
> And register the app seems a no-way: I've tried this way: https://support.google.com/accounts/answer/185833 eg, enable 2-Step verification and then enable 'App Password', and works as expected. -- Galleggiano lenti, rotondi e contenti la faccia pero` e` solo quella coi denti (R. Vecchioni) |
|
From: Marco G. <ga...@li...> - 2022-05-11 12:50:17
|
Mandi! Andrew C Aitchison In chel di` si favelave... > > https://support.google.com/accounts/answer/185833 > > eg, enable 2-Step verification and then enable 'App Password', and works as > > expected. > Yes, that is a reasonable option for now. Yes, i confirm. Very simple, compared to all the fuss for registering to oauth services.... > We would like to stop fetchmail from being what Google call a > "less secure app", even though we don't believe that that > description is accurate. Good point; also, this is a general problem, many 'unsecure app' (recently i've found the Youtube KODI plugin) exist, a common and simple way will be cool... |
|
From: Robin A. <ro...@bi...> - 2022-05-13 14:00:25
|
On Wed, 11 May 2022 14:45:49 +0200 Marco Gaiarin <ga...@li...> wrote: > Mandi! Andrew C Aitchison > In chel di` si favelave... > > > > https://support.google.com/accounts/answer/185833 > > > eg, enable 2-Step verification and then enable 'App Password', > > > and works as expected. > > Yes, that is a reasonable option for now. > > Yes, i confirm. Very simple, compared to all the fuss for registering > to oauth services.... Will this technique work past the end of the month? Thanks Robin -- ---------------------------------------------------------------------- Robin Atwood. ---------------------------------------------------------------------- |
|
From: Marco G. <ga...@li...> - 2022-05-17 12:08:16
|
Mandi! Robin Atwood In chel di` si favelave... >> > > https://support.google.com/accounts/answer/185833 > Will this technique work past the end of the month? AFAIK yes, or at least i've not found anywhere a bigG docs stating the opposite... -- Che ruolo può avere all'interno di una società uno che non parla ed il cui curriculum é misero? IL Presidente. (Si Può Fare - Nello) |
|
From: Robin A. <ro...@bi...> - 2022-05-14 06:33:08
|
On Fri, 13 May 2022 19:42:28 +0100 (BST) Andrew C Aitchison <an...@ai...> wrote: > On Fri, 13 May 2022, Robin Atwood wrote: > > > On Wed, 11 May 2022 14:45:49 +0200 > > Marco Gaiarin <ga...@li...> wrote: > > > >> Mandi! Andrew C Aitchison > >> In chel di` si favelave... > >> > >>>> https://support.google.com/accounts/answer/185833 > >>>> eg, enable 2-Step verification and then enable 'App Password', > >>>> and works as expected. > >>> Yes, that is a reasonable option for now. > >> > >> Yes, i confirm. Very simple, compared to all the fuss for > >> registering to oauth services.... > > > > Will this technique work past the end of the month? > > Sounds as if you know more than me, since you have a specific date, > but my guess would be "no". > > You are definitely asking the rght question. > Some of us got emails from GMail telling us that apps like fetchmail, using a simple password, would stop working at the end of May. Hence all the interest in Oauth2. Robin -- ---------------------------------------------------------------------- Robin Atwood. "Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst" from "Mandalay" by Rudyard Kipling ---------------------------------------------------------------------- |
|
From: Matthias A. <mat...@gm...> - 2022-05-14 09:03:44
|
Am 14.05.22 um 08:32 schrieb Robin Atwood: > > Some of us got emails from GMail telling us that apps like fetchmail, > using a simple password, would stop working at the end of May. Hence > all the interest in Oauth2. > Sure, but fetchmail has supported several passwordless schemes for ages (Kerberos, client-side certificates), and none of them required application registration or other power play. If some provider tells you "you can't get to your data without jumping hoops", find one that is happy with your, or fetchmail's, access methods. |
|
From: Robin A. <ro...@bi...> - 2022-05-14 12:42:09
|
On Sat, 14 May 2022 11:03:25 +0200
Matthias Andree <mat...@gm...> wrote:
> Am 14.05.22 um 08:32 schrieb Robin Atwood:
> >
> > Some of us got emails from GMail telling us that apps like
> > fetchmail, using a simple password, would stop working at the end
> > of May. Hence all the interest in Oauth2.
> >
> Sure, but fetchmail has supported several passwordless schemes for
> ages (Kerberos, client-side certificates), and none of them required
> application registration or other power play.
>
> If some provider tells you "you can't get to your data without jumping
> hoops", find one that is happy with your, or fetchmail's, access
> methods.
Sure, I have pre-paid one year's access at Mailbox.Org while I see what
plays out. :)
Robin
--
----------------------------------------------------------------------
Robin Atwood.
"Ship me somewheres east of Suez, where the best is like the worst,
Where there ain't no Ten Commandments an' a man can raise a thirst"
from "Mandalay" by Rudyard Kipling
----------------------------------------------------------------------
|
|
From: Matthias A. <mat...@gm...> - 2022-04-28 20:16:57
|
[Bcc'd to Eduardo Chappa's address found on repo.or.cz/alpine.git] Am 20.04.22 um 11:00 schrieb Andrew C Aitchison: > > On Wed, 13 Apr 2022, Matthias Andree wrote: > >> Am 12.04.22 um 23:18 schrieb Marco Gaiarin: >> > I've followed literally: >> > >> > https://gitlab.com/fetchmail/fetchmail/-/blob/next/README.OAUTH2 >> > >> > (eg, the readme of fetchmail 7) and works as expected. Now i have to > manage >> > some script to refresh the token, and download the email. >> > >> > I've only a question, before put all that stuff in 'production'. >> > >> > Juergen Edner say that the OAuth client created in 'Test mode' least > at >> > maximum a week. >> > But if i try to publish the app, i need the Google approval process, > because the api used (eg, GMAIL >> > API) is 'restricted'. >> > >> > So, it is needed to publish the app? If yes, what is the shortest and > error >> > prone path to get it approved? >> > >> Their requiring registration of the "app" (we have never called >> fetchmail that) - and not solely the user for his or her own account - >> is one of the reasons why I say that OAUTH2 in this form is generally a >> non-starter and does not scale. >> >> I cannot possibly register fetchmail with each and every mail service, >> and device registration is somewhat pointless anyways. > > There has been some discussion of fetchmail and google in the email list > for alpine - another open source MUA - particularly the thoughts > of the main alpine developer at > https://mailman12.u.washington.edu/pipermail/alpine-info/2022-April/001162.html I have read Eduardo's mail again, and I come to different conclusions. The thought of supporting users of accessing some service is nice, and I have sympathy for it. Also, sticking together as maintainers of Free and Open Source Software and explaining the situation to users seems useful. So here is my take. On a broader view, stepping back a yard from the drawing board: The entire OAuth discussion so far has revolved around Google and Microsoft wherever I have seen it (either by Andrew's pointer to ALPINE, or on the getmail mailing list). The intro always goes as a variation on the "$BIGCOMPANY wants OAuth to let me access my own data where IMAP or POP3 used to work" theme. So why do YOU, the user, allow that to happen? Why do we foster monopolies? Meaning we are not it is not technically about OAuth, but it is about $BIGCOMPANY trying to own the game, your data, your whatever_other_valuable by changing the rules. In essence, they try to exert control over what applications the users are permitted to use to access their VERY OWN PERSONAL data. Since when have we allowed such intrusions into users' liberties to happen? What do I have to gain as maintainer of a free and open source software in that race? Nothing. If I open the OAuth floodgate now, I pay with my time to implement, debug, or - if contributed - review and integrate things. I will create a technical debt for myself that there will be a permanent expectation that this is supported, and that will also take time. All time that is spent, or rather wasted, on trying to implement technical solutions for a political problem. It could be invested in other changes that would be useful to fetchmail. But look, if $BIGCOMPANY want to change rules again tomorrow, they will do so. And fetchmail would be back to square one. A spare-time open source maintainer cannot possibly win such a race. I will not try. We can stop that nonsense today, and not be made jump through the hoops. The proper user response is: take your data while you still can, and to where you will not be bullied. It may be inconvenient. I am not picking up a technical fight to attack political arbitrariness. I am not going to register fetchmail with any service provider. I have one voice, users have many. If someone has come to fetchmail for free beer, sorry, you've taken the wrong turn. We want free choice in this place. This includes the choice to leave fetchmail behind because I am not catering for that OAuth 2 need. But unlike $BIGCOMPANY, I need no high user count, I need not bind your attention, I do not need you to stay on my site longer, because I am not selling advertisements. Fetchmail does not call home, it does not track you, it does not breach your privacy, and everyone can see the source code and confirm that to him- or herself. Try that with Outlook, or with the web-based interfaces to GMail or Outlook.com/MSN. What does this mean? The existing prototypical code in the "next" branch (towards 7.0.0) can remain until found vulnerable or nonfunctional. It will be considered experimental unsupported code. Feel free to discuss OAuth on the list, but make sure OAuth is in the subject, and do not expect me to even pay attention. If there is a service that offers OAuth 2.0 as part of a non-discriminatory public mail service through IMAP and/or POP3 WITHOUT requiring app registration, verification, and other nonsense, feel free to tell me about it, we will need something to test against if it's not M or G, and if it's not too much of an effort, we may actively implement for that service to make a public demonstration that OAuth 2.0 can go without exerting control over apps. That would be valuable in defanging all the FUD and distractions around "less secure apps". For OAuth pull requests, stick to contrib/ and make it standalone, except for the minimal changes to the fetchmail code (which we already have and might be sufficient already). Be sure to make contributions high-quality, include documentation, be easily reviewed, and best two other fetchmail users have tested the code on their systems, too, then I may look at pull request. Make sure that you have all licenses to the code you share, and the only acceptable languages for now are C, C++, Python 3 (for upstream-supported versions) and portable Shell. Anything else, ask me before you spend your time. About libraries, make sure they blend in with existing licenses, in particular, they need to be compatible with GPL v2, GPL v3, Apache, and OpenSSL licenses. Only use widely-used high-quality libraries (Boost would be fine). I consider dynamic linking to be creating derivative works, because the FSF (author of the GPL) does. Happy mail fetching, Matthias |
|
From: Lucio C. <lu...@la...> - 2022-04-29 15:36:50
|
On Thu, 28 Apr 2022, Matthias Andree wrote: > We can stop that nonsense today, and not be made jump through the hoops. > The proper user response is: take your data while you still can, and to > where you will not be bullied. It may be inconvenient. ... I have been following the discussion on oauth2 both on the alpine and fetchmail mailing lists. With some (or a lot of) worry. I have "always" (that means from the '90s) been used to receive *and store* my mail on my (work) computer. This was fine and gradually I added also a number of procmail filters. For a time I also followed the local implementation of sendmail in my institute. For some time we had a local institute IMAP, but that was mainly for those we called "the homeless" (those using a Windows PC and not having a home on a Linux workstation). I still received all mail on my work computer. I had (still have) a local IMAP which can be activated on my own work computer, and used it seldom on some long trips. But I prefer to ssh to such work computer, and run alpine there (what I regularly do from home during this pandemics). Unfortunately a while ago my institution (which is composed of several institutes) made a move towards Gsuite (apparently one of the reasons was that the kmow-how about home-grown mail handling solutions was disappearing). I managed to continue "business as usual" like before ADDING fetchmail in the loop: http://sax.iasf-milano.inaf.it/~lucio/WWW/WhereManWins/gs.html I still get all my mail on my work computer through my procmail rules, with the little price of a 5 min delay (I run fetchmail every 5 min) and a daily cleanup of the Gsuite Bin (I can manage 99% of this via Alpine/IMAP without using Gmail web interface) ... I leave only spam there :-) I receive only a smll percentage of my mail on another public provider (an old fashioned civic network, which has only POP support; I now use fetchmail on it too, but 3-4 times a day only). If fetchmail would not continue to operate with Gsuite, I guess I'd be forced to look for some other (fetchmail-friendly) provider (if I only had a static IP and not a CGNAT DHCP at home, I would even be ready to run my own MX/SMTP) and possibly route all Gsuite mail to it. Advices and suggestions are welcome. -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X