5 ms·

I really lament that you cannot sign in even with an application specific password any more and you need to get an oauth client and go through an oauth flow. It

I really lament that you cannot sign in even with an application specific password any more and you need to get an oauth client and go through an oauth flow. It’s my email, but Google takes away an open standard even for myself to access it.

kasey_junk 1y ago
Sorry, why do you consider app specific passwords an open standard but oauth not?
- simonw 1y ago
  POP3/IMAP work with any client that supports those protocols. OAuth really doesn't. Every OAuth integration I've ever built always feels like it needs a tiny bit of custom development. Also the OAuth flow is usually absolutely horrible for when you're trying to get a token for accessing your own data. I've had to spin up a temporary web app to handle a hunch of redirects just to get my own token!
  - sir 1y ago
    I built a proxy a while ago to make this easier - it lets you stick with IMAP/POP/SMTP as-is. No need for your client to even know that OAuth exists. See here: https://github.com/simonrob/email-oauth2-proxy https://github.com/simonrob/email-oauth2-proxy
    - the_mitsuhiko 1y ago
      > No need for your client to even know that OAuth exists Yes, you can do that, however the problem is getting a client_id/client_secret in the first place. You need to register yourself for one, you need to (nowadays) whitelist every single account or go through a google verification process. At one point you could apply for a client_id that allowed anyone to use it, but that ship has sailed.
  - kasey_junk 1y ago
    So that’s an argument about a protocol preference not an open ness one. Which frankly makes a lot of sense and wouldn’t have confused me.
    - the_mitsuhiko 1y ago
      > So that’s an argument about a protocol preference not an open ness one. Just to make sure the differences are clear: with username and password and IMAP I can use an RFC standardized protocol to sign into an inbox and I do not need Google's permission. The oauth flow they have is neither standardized (XOAUTH2 is not a standard as far as I know at least), requires provider specific logic (Outlook is different to Google) and most importantly requires me to get Google's permission to sign in. I need to get a client_id with the necessary scope, and that is only granted after a review by Google. [1] [1]: asterisk is that a development only app can authenticate up to 100 users, and those users need to be explicitly whitelisted in the dev panel.
      - tptacek 1y ago
        That's an appeal to IETF canon, which might be a valid concern (I wouldn't share it, as an opponent of the IETF) but remains orthogonal to "openness". A protocol is open if it's published and especially if it's widely used, which this configuration is.
        the_mitsuhiko 1y ago
        I think you're hyper focused on a point I wasn't making.
sdoering 1y ago
Given the amount of spam I receive on my free Gmail addresses (compared to my paid for freelance one), and the amount of spam I receive from Gmail servers on my non Gmail-E-Mail accounts I get more and more inclined towards degoogling myself. Especially as I receive more and more information that my freelance e-mail is put into spam by recipient systems. Not sure how to get rid of my Google ecosystem routines, though. Feels daunting.
- redeeman 1y ago
  step 1: extract data step 2: just dont use google shit anymore. Deal with it. you dont get it done by moping about it, but by doing
  - someguydave 1y ago
    It would also help if you did step 0: buy your own email domain
    - cowboylowrez 1y ago
      Personally, I love sending emails nobody will receive, it removes inhibitions and lets me speak my mind without regrets!
      - _lvbh 1y ago
        I've been self hosting email for a few years at this point and haven't had any delivery issues. Just make sure you set up all your DNS correctly and avoid polluted IP ranges like DO or AWS
      - codazoda 1y ago
        This isn’t as hard as you might think. I pay for https://mailwip.com https://mailwip.com because the founder helped me figure out mine. It was ultimately relatively strait-forward. I stay because I appreciate his work, my email is flawless, and I like the logs they provide.
isaachinman 1y ago
Sorry, I don't quite get the point you're trying to make... With an app password you have full IMAP access.
- the_mitsuhiko 1y ago
  > With an app password you have full IMAP access. App passwords no longer exist on Google.
  - isaachinman 1y ago
    That is 100% untrue. I've built functionality on app passwords and use them on a daily basis.
    - the_mitsuhiko 1y ago
      On my Google Workspace org, app passwords don't even show up in the user account settings any more. The documentation says they are recommended against, and the IMAP docs say only oauth2 is supported. However I just found posts that suggest that you can still access them if you navigate directly to the app passwords page. I will try.
      - isaachinman 1y ago
        We're using app passwords for Marco (https://marcoapp.io https://marcoapp.io), until we get through the unnecessarily-rigorous process of gaining privileged OAuth access for email scopes. Here's the support article we link our users to: https://support.google.com/accounts/answer/185833 https://support.google.com/accounts/answer/185833 Workspace is a bit different, however. You need an admin to enable app passwords.

kasey_junk 1y ago

Sorry, why do you consider app specific passwords an open standard but oauth not?

simonw 1y ago
POP3/IMAP work with any client that supports those protocols. OAuth really doesn't. Every OAuth integration I've ever built always feels like it needs a tiny bit of custom development. Also the OAuth flow is usually absolutely horrible for when you're trying to get a token for accessing your own data. I've had to spin up a temporary web app to handle a hunch of redirects just to get my own token!
- sir 1y ago
  I built a proxy a while ago to make this easier - it lets you stick with IMAP/POP/SMTP as-is. No need for your client to even know that OAuth exists. See here: https://github.com/simonrob/email-oauth2-proxy https://github.com/simonrob/email-oauth2-proxy
  - the_mitsuhiko 1y ago
    > No need for your client to even know that OAuth exists Yes, you can do that, however the problem is getting a client_id/client_secret in the first place. You need to register yourself for one, you need to (nowadays) whitelist every single account or go through a google verification process. At one point you could apply for a client_id that allowed anyone to use it, but that ship has sailed.
- kasey_junk 1y ago
  So that’s an argument about a protocol preference not an open ness one. Which frankly makes a lot of sense and wouldn’t have confused me.
  - the_mitsuhiko 1y ago
    > So that’s an argument about a protocol preference not an open ness one. Just to make sure the differences are clear: with username and password and IMAP I can use an RFC standardized protocol to sign into an inbox and I do not need Google's permission. The oauth flow they have is neither standardized (XOAUTH2 is not a standard as far as I know at least), requires provider specific logic (Outlook is different to Google) and most importantly requires me to get Google's permission to sign in. I need to get a client_id with the necessary scope, and that is only granted after a review by Google. [1] [1]: asterisk is that a development only app can authenticate up to 100 users, and those users need to be explicitly whitelisted in the dev panel.
    - tptacek 1y ago
      That's an appeal to IETF canon, which might be a valid concern (I wouldn't share it, as an opponent of the IETF) but remains orthogonal to "openness". A protocol is open if it's published and especially if it's widely used, which this configuration is.
      - the_mitsuhiko 1y ago
        I think you're hyper focused on a point I wasn't making.

sdoering 1y ago

Given the amount of spam I receive on my free Gmail addresses (compared to my paid for freelance one), and the amount of spam I receive from Gmail servers on my non Gmail-E-Mail accounts I get more and more inclined towards degoogling myself. Especially as I receive more and more information that my freelance e-mail is put into spam by recipient systems. Not sure how to get rid of my Google ecosystem routines, though. Feels daunting.

redeeman 1y ago
step 1: extract data step 2: just dont use google shit anymore. Deal with it. you dont get it done by moping about it, but by doing
- someguydave 1y ago
  It would also help if you did step 0: buy your own email domain
  - cowboylowrez 1y ago
    Personally, I love sending emails nobody will receive, it removes inhibitions and lets me speak my mind without regrets!
    - _lvbh 1y ago
      I've been self hosting email for a few years at this point and haven't had any delivery issues. Just make sure you set up all your DNS correctly and avoid polluted IP ranges like DO or AWS
    - codazoda 1y ago
      This isn’t as hard as you might think. I pay for https://mailwip.com https://mailwip.com because the founder helped me figure out mine. It was ultimately relatively strait-forward. I stay because I appreciate his work, my email is flawless, and I like the logs they provide.

isaachinman 1y ago

Sorry, I don't quite get the point you're trying to make... With an app password you have full IMAP access.

the_mitsuhiko 1y ago
> With an app password you have full IMAP access. App passwords no longer exist on Google.
- isaachinman 1y ago
  That is 100% untrue. I've built functionality on app passwords and use them on a daily basis.
  - the_mitsuhiko 1y ago
    On my Google Workspace org, app passwords don't even show up in the user account settings any more. The documentation says they are recommended against, and the IMAP docs say only oauth2 is supported. However I just found posts that suggest that you can still access them if you navigate directly to the app passwords page. I will try.
    - isaachinman 1y ago
      We're using app passwords for Marco (https://marcoapp.io https://marcoapp.io), until we get through the unnecessarily-rigorous process of gaining privileged OAuth access for email scopes. Here's the support article we link our users to: https://support.google.com/accounts/answer/185833 https://support.google.com/accounts/answer/185833 Workspace is a bit different, however. You need an admin to enable app passwords.