Re: Making GNUS continue to work with Gmail

[Andrew Cohen <cohen@bu.edu>]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> Since I don't know anything about using MS mail, I can't tell
    RS> from those words whether you have described (1) something each
    RS> user can do, or (2) something that would have to be done once on
    RS> behalf of GNUS.  Which one is it?

Sorry for not being clear. Others have described the issues with gmail
and I am saying that the issues are the same with outlook.

In trying to answer your question let me list the three steps I toke to
make this work with outlook:

1. REGISTRATION: An "app" needs to be registered with MS. Successful
    registration returns certain credentials. The returned credentials
    are what others have said google's terms of service forbid from
    being embedded in the app, although kmail and others do so anyway.

2. AUTHORIZATION: A user takes the credentials returned in step 1 and
    authorizes the "app" to access the user's outlook email. A "refresh
    token" is returned to the user.

3. ACCESS: Once authorized, the user can use the "refresh token" to
    retrieve an "access token" that is used like a temporary password to
    communicate with outlook over imap and smtp. The access token has a
    short lifetime (one hour) and new logins after that require
    repeating step 3 (using the same refresh token.)

Now to answer your question: the intent behind this process is that step
1 is performed once for the app (in our case gnus) and steps 2 and 3 are
performed by users. Step 2 is performed once by the user, and step 3 is
performed each time the user logs in. (Others have said that on occasion
authorization is revoked and step 2 must then be repeated, but I haven't
yet encountered this).

Nothing prevents each user from performing step 1 (that is, each user
registers their own app) but the process is technical and tedious, and
not something I think we can realistically expect from many users. It
also requires the use of a web browser and web pages that likely involve
javascript.

Step 2 is less tedious but also involves using a web browser and web
pages that use javascript (I am not 100% confident about the use of
javascript here, so it is possible that this part of the process could
be done in some other way).

Step 3 is the part that I referred to as easy---once the app has been
registered and the user has obtained the refresh-token, gnus can use the
oauth2 library on elpa to easily and directly manage the process of
obtaining the access-token and logging in.