> insecure app password [...] and will eventually be phased out in favor of OAuth access tokens over IMAP What's so "insecure" about "per-app passwords"? I as

> insecure app password [...] and will eventually be phased out in favor of OAuth access tokens over IMAP What's so "insecure" about "per-app passwords"? I ask, because I've lost the past 5 years of my life to building and running an internet-facing OAuth2+OIDC IAM system and I'm (still) an active contributor back to the open-source OIDC framework it's built-on. I grok the grants and flows and I've got the blood-pressure to show for it (and developed a healthy opposition to SAML); but despite all of that, I appreciate simple solutions to problems where there's a very real risk of over-engineering - and especially when a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made, even if some clinicaly-dry technical assessment mathematically proves the complex solution is more "secure" by some measure. /// > although there's a lacking ecosystem to import the big .mbox files back to an email provider. Everyone I know (okay, just a handful of ("normal") people) who has done this ended-up converting the .mbox to a PST for Outlook and copied it over to any other machines they have; it's an archive mailbox after-all, so just put it in read-only mode and don't worry about data-synchronization issues. Kinda ironic that Gmail's credibility was/is built on ex-Outlook users looking for something better, only for Outlook to be the refuge (and last resting place?) for hundred-gigabyte-sized e-mail archives.