[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alpine-info
Subject:    Re: [Alpine-info] O365 XOAUTH2 via fetchmail
From:       Eduardo Chappa <alpine.chappa () yandex ! com>
Date:       2022-04-30 1:45:59
Message-ID: 6e12bbf9-0971-48f8-30c2-3548751d9cec () yandex ! com
[Download RAW message or body]


[ Bcc'ed to Matthias Andree ]

On Fri, 29 Apr 2022, Lucio Chiappetti wrote:

> On Fri, 29 Apr 2022, Carlos E. R. wrote:
>
>>> If the institute Gsuite (which is currently my main e-mail feed, via
>>> ssh from home) moves to OATH2 forbidding fetchmail AND imap, I'll guess
>>> I'd move at least my private mail to some other provider, and forward
>>> the official one to it.
>>
>> Forwarding can also have interesting mishaps ;-)
>
> Ready to test it, if FORCED to abandon fetchmail.
>
> By the way, I've made a posting to 
> fetchmail-users@lists.sourceforge.net, in reply to a posting by Matthias 
> Andree (the latter was sent to Eduardo in Bcc:)
>
> I also kept a copy of some of the latest list(s) correspondence on this 
> issue, but I have to study it, including yours about imapsync (was this 
> the name?). Will that be oauth-free ?

I did talk to Matthias over Zoom and we had a conversation on this issues. 
He does not oppose that OAUTH2 be available to fetchmail users, but the 
issue is too complicated and he makes some good points on the meaning of 
this situation.

Let me share my experience with registration/verification.

Google: They keep changing their requirements and they would issue a 
client-id and client-secret in the past to any app, but now they only give 
them to verified apps, so all one can do is to get one for testing, which 
expires every 7 days, and this leads to going through the authorization 
process once a week. This is bad for people like us who use apps like 
fetchmail, alpine or mutt that respect the permissions granted by their 
users.

Microsoft: The experience with microsoft is very good considering the 
experience with Google. Alpine users do not need to get their own 
client-id and client-secret if they follow the "device" flow, but need a 
special client-id and client-secret if they wish to use the Authorize 
method. The main obstruction is not Microsoft by itself, it is the 
administrators that do not allow Alpine to access their resources. This is 
a subtle way to create a monopoly or a situation that only benefits the 
big companies, at best. If your company allows access to your program, 
Microsoft is not the obstruction, regardless of the level of verification 
you have with Microsoft.

Yandex: I registered Alpine with Yandex, got my client-secret and 
client-id and I have never had any obstruction from Yandex or verification 
to make. All has worked well.

In general a program should allow users to go through the authorization 
stage, and for all I know, fetchmail, alpine and mutt will allow it. This 
is a good situation. There are more issues that will come up over the 
future and I am sure we will all be ready to face it when the time comes.

-- 
Eduardo
_______________________________________________
Alpine-info mailing list
Alpine-info@u.washington.edu
http://mailman12.u.washington.edu/mailman/listinfo/alpine-info
[prev in list] [next in list] [prev in thread] [next in thread]