On Wed 18 Dec 2019 at 13:00:23 +1100, Adam Bolte wrote:

On Tue, Dec 17, 2019 at 05:12:08PM +1100, Brian May wrote:

...

I am not aware of any open source IMAP client software that can use OAuth.

Although I haven't tried yet, I'm pretty sure Thunderbird and offlineimap support it.

Thunderbird 38.0beta release notes (current version is 68.3.0): https://www.thunderbird.net/en-US/thunderbird/38.0beta/releasenotes/

Using Offlineimap with the Gmail IMAP API: https://hobo.house/2017/07/17/using-offlineimap-with-the-gmail-imap-api/

I can confirm for OfflineIMAP, using this [0] to get the initial token. This is what I have in the config [Repository GMail] type = Gmail remoteuser = address@gmail.com # See [0] # [0] https://github.com/OfflineIMAP/offlineimap/blob/master/offlineimap.conf#L761: oauth2_request_url = https://accounts.google.com/o/oauth2/token oauth2_client_id = XXX.apps.googleusercontent.com oauth2_client_secret = XXX oauth2_refresh_token = 1/XXX maxconnections = 3 # See [1] # [1] https://github.com/OfflineIMAP/offlineimap/issues/573#issuecomment-417049116 ssl_version = tls1_2 ssl = yes sslcacertfile = /etc/ssl/certs/ca-certificates.crt subscribedonly = yes folderfilter = lambda foldername: foldername in ('[Gmail]/Drafts', '[Gmail]/All Mail') or not foldername.startswith('[Gmail]') nametrans = lambda folder: re.sub(r'^\[Gmail]/', r'', fo On Android, I use a fork of K9, called PeP, which also supports autocrypt. [0] https://github.com/google/gmail-oauth2-tools -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.

On Thu, Dec 19, 2019 at 07:39:57AM +1100, Brian May wrote:

Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch.

If offlineimap isn't your thing, getmail looks like it'll do the job, at least at a glance. http://pyropus.ca/software/getmail/configuration.html#retriever-parameters

On Thu, Dec 19, 2019 at 05:21:43PM +1100, Brian May wrote:

Last time I looked, getmail upstream development was dead, and only supported Python 2.7. So I switched from getmail to fetchmail. It also had problems handling timeout errors from a dead SSL connection, and would hang for ever.

Not sure if that is still the case or not.

No idea about the dead SSL connection issue. I haven't used it long enough to properly evaluate it. Most of my experience is with offlineimap (with Mutt). The getmail changelog would suggest it is still supported, with the most recent release being from late August. http://pyropus.ca/software/getmail/CHANGELOG It is still available in Debian sid and buster, and there is some interest on their mailing list in migrating getmail to Python 3 to keep it in Debian (and to drop "historical cruft and backwards-compatibility code"). It might be worth a look and perhaps giving them a hand. https://marc.info/?t=157365903900002&r=1&w=2

Adam Bolte writes:

On Thu, Dec 19, 2019 at 07:39:57AM +1100, Brian May wrote:

...

Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch.

If offlineimap isn't your thing, getmail looks like it'll do the job, at least at a glance.

Looks like instructions are here: http://www.bytereef.org/howto/oauth2/getmail.html I recently moved from getmail to fetchmail, guess I should move back again and try getmail again. I notice the instructions say "The resulting setup is not more secure than a regular getmailrc with 0600 permissions." - which is no surprise really. I can understand Google not wanting user's to authenticate to IMAP with their standard username/password, but if it is true that application specific passwords won't work either, that seems excessive to me. I have a user who is using gmail with Outlook 2007. They might be affected more so then me. I have told said user they will need to upgrade to Outlook 2019 or Office 365, or use gmail from the website, it looks like Outlook 2007 does not support OAUTH from what I can tell. -- Brian May https://linuxpenguins.xyz/brian/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 7/1/20 11:57 am, Adam Bolte wrote:

On Thu, Jan 02, 2020 at 06:13:07PM +1100, Brian May wrote:

...

I notice the instructions say "The resulting setup is not more secure than a regular getmailrc with 0600 permissions." - which is no surprise really.

Application passwords were, arguably, less secure than what you could actually use as a password and you lost the 2FA aspect of the login. So, lots of room for improvement.

As I understand it, there is arguably a *slight* security improvement in the initial application setup. If the user has two-factor authentication enabled, it would be difficult for someone who learns the password to access e-mails - they would need to have a copy of either the 2FA device, or the security token.

If you know the secret to generate the codes, you don't need any security token. Of course you need the username (email address generally) AND the actual password as well. TOTP, as per "Google Authenticator" and other implementations is still better than plain username and password, but it isn't bulletproof.

I suspect the real reason Google is forcing this is because they want to help make using client applications less convenient over the web interface.

Perhaps, but adding security can add all sorts of "other" risks or pain.

...

I have a user who is using gmail with Outlook 2007. They might be affected more so then me. I have told said user they will need to upgrade to Outlook 2019 or Office 365, or use gmail from the website, it looks like Outlook 2007 does not support OAUTH from what I can tell.

I just wish people would stop using Google mail services altogether, same with Outlook (hotmail / m$, Yahoo and other bad providers.

Maybe you could put in a plug for Thunderbird or something else that's free software, since it sounds like the user will have to upgrade anyway. Better to make it a true upgrade. :)

Sadly too many people / business are happy to keep paying M$ taxes on everything with subscription services; hence why Microsoft is taking in considerably more income in this area, so much so, that they care less about Windows license fees as anyone using Windows is more likely to be using O365 and/or other pay for services for their lifetime. All in all, lots of pain points ... enough said :( A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXhQmpgAKCRCoFmvLt+/i +2otAP4rwrk3C+8lJwm9U1yL+YX9cSpcvBBB+UlnZ5OACP5sRgD/bpQCz0RlR9Ht f/OpJzkl+JwryjjNtDQQ24WczWZuJaY= =DVK2 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 8/1/20 7:54 am, Brian May wrote:

Andrew McGlashan writes:

...

Application passwords were, arguably, less secure than what you could actually use as a password and you lost the 2FA aspect of the login. So, lots of room for improvement.

No, not really. e.g. if you look at the getmail implementation, it is still just storing a secret (token) stored on the filesystem that is completely usable without any 2FA. You do need 2FA to obtain the original token (just like you need 2FA to obtain an application specific password), but once you have that there is no need for 2FA anymore.

I think you misunderstand my views on Google authentication. If you login to your Google account, then you can add in 2FA using Google Authenticator app or anything compatible with TOTP (I use a python script myself). When you set up 2FA, at least way back (not sure if it any different now), you could setup "application passwords" for things like Thunderbird or something else that has to login to your Google account. It is these passwords that use a fixed length and a small number of hexadecimal characters (so only 16 base characters, not even close to base64 or the printable character set and forget about using non-printable characters). If you want a secure password, then long is great, but using a range of characters or perhaps better still a long list of dice words so it can be easily typed. Anywhere you have plain text tokens or passwords stored in the file system, then you had better take care of those well. Use FDE (full disk encryption and/or ensure proper use of file permissions, etc). btw my use of a Google account or rather accounts is more for testing purposes or for Android devices -- I should probably be using F-driod though instead of the play store, but that's a whole different story and can of worms ;) Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXhcZpwAKCRCoFmvLt+/i +yk/AQCUJupTt81Pt3EAV0H4qBj7HcicQfjpf02noiUFuHWr4wEAsuKRpgDfyoHM i07apxT5MzESBu0CUA/v1uTMprIWeWE= =nKnF -----END PGP SIGNATURE-----

"Matt Cengia" writes:

Hi Brian,

Are you able to provide a quote of this email from Google or any website it links to? I don't use Gmail any more, so haven't received it, but am interested in its contents.

In particular, does it state it's removing *all* password auth from IMAP, or just that you'd need to use app passwords instead of your Google password? I definitely think the latter makes sense; the former is going a bit far IMO.

I am not exactly sure how much of this I have understood. It does seem clear though OAuth only. Except maybe for SMTP, which is odd. I personally don't see how OAuth is going to be any more secure then an application specific password. === cut === Beginning June 15, 2020, non-Google apps that use only a password to access Google accounts will no longer be supported. Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported. Dear Administrator, We're constantly working to improve the security of your organization's Google accounts. As part of this effort, and in consideration of the current threat landscape, we'll be turning off access to less secure apps (LSA) — non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account. Access to LSAs will be turned off in two stages: June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. What do I need to do? To continue using a specific app with your G Suite accounts, users in your organization must switch to a more secure type of access called OAuth. This connection method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (included below) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also included below. MDM configuration If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below: June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. Other less secure apps For any other LSA, ask the developer of the app you are using to start supporting OAuth. If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. Scanners and other devices No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth. User instructions If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect. Email If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. Alternatively you can use G Suite Sync for Microsoft Outlook. If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you'll need to remove and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth. Mac OS iOS mail app view Mac OS mail app view iOS Calendar If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you'll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more Contacts If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you'll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. Note: If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth, or ask your admin to contact the supplier of your app and request that they add OAuth as a way of connecting your Google account. Developer instructions To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. How can I get help? If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552. Thanks for choosing G Suite. —The G Suite Team Was this information helpful? YES NO © 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 You have received this important update about your G Suite account because you designated this email address as a primary or secondary contact for mandatory service communications in your Google Admin console profile. -- Brian May https://linuxpenguins.xyz/brian/

On Tue, Dec 17, 2019 at 5:12 PM Brian May wrote:

email I received from Google today saying that they intend to phase out support for username/password authentication for LSA ("less secure apps") using protocols such as IMAP, and require using OAuth authentication instead. I am not aware of any open source IMAP client software that can use OAuth.

I've been using OAuth with Thunderbird for IMAP to gmail, as my workplace has been enforcing that and disabled app password access. I vaguely remember having to upgrade Thunderbird or something to get it going. Glenn