On Tue, Dec 17, 2019, at 08:56, Brandon Long via mailop wrote: > On Mon, Dec 16, 2019 at 1:30 PM Jaroslaw Rafa <[email protected]> wrote: >> Dnia 16.12.2019 o godz. 12:42:29 Brandon Long via mailop pisze: >> > Here's the announcement post: >> > >> https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html >> > >> > Note this is more than just unencrypted access, this is using password >> > based login at all. Looks like it doesn't apply to SMTP, yet, probably >> > because of the number of printers and other embedded devices that don't >> > support oauth. >> > >> > As for tools, last year I added support for OAUTHBEARER to mutt but by >> > shelling out to >> > https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py >> for >> > generating tokens. The sasl level code to send the tokens is pretty >> > trivial, the annoying part is launching a browser and getting the token >> > back from it. >> >> Do any Windows/Linux/MacOS email clients currently support OAuth "out of the >> box"? >> If not, that's basically cutting nearly everybody using regular IMAP email >> clients off of G Suite... > > The blog post specifically calls out Outlook, Mail.app and Thunderbird as > supporting OAuth, > once you add iOS Mail and various common Android Mail apps, that probably > covers 90+% of > the third party mail clients used to access Gmail. I don't know if all of the > Android Mail apps support > OAuth these days, but there tools built into Google Services on Android to > handle oauth grants very > easily (certainly the easiest of the platforms besides web apps). > > For terminal apps, doing something like I did with Mutt is probably the right > choice and pretty straightforward. > For gui apps, it's obviously more complicated if you need to embed a web > browser, not to mention > the inherent insecurity of logging into Google from an embedded web > browser... but I guess you would have given > that app your password anyways prior to oauth, so whatever.
This is one of the cases where JMAP authentication (as seen in https://datatracker.ietf.org/doc/draft-ietf-jmap-core/00/ and removed afterwards due to not wanting to mix the mail protocol with considerations of a new authentication mechanism) would have been quite nice. Basically, you try to log in and get told "please load up this URL in a your normal web browser and do stuff until the web browser tells you that the session is alive, then come back here and all will be good". Or even "you have an authenticated connection now that can't see any accounts, go sign in however many accounts you like over the web with this magic link and they will get added to this connection". I'm quite interested in that actually, because JMAP already supports having multiple accounts inside a single authenticated connection - you could have each session start off "empty" and authenticate accounts into it! Bron. -- Bron Gondwana [email protected]
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
