OAuth2?

Hi All,

Any of you guys know of a command line application that
will allow me to send mail to an smtp server that uses
OAuth2 authentication (google, yahoo, etc.)?

Many thanks,
-T

T wrote:

Any of you guys know of a command line application that
will allow me to send mail to an smtp server that uses
OAuth2 authentication (google, yahoo, etc.)?

For Gmail, don't use OAUTH2. Use the standard login credentials
(username & password) authentication. Just make sure you configure the
server-side setting in your Gmail account to "Allow less secure apps".
With that enabled, you don't need an e-mail client that does OAUTH2. By
just using the sign-in credentials (no OAUTH2 tokens), you could use
Powershell in Windows, like:

https://www.howtogeek.com/120011/stu...xtra-software/

That script uses the SMTP client included in .NET Framework. Because
Gmail demands SSL/TLS connections is why there is the line in the script
of $SMTPClient.EnableSsl = $true.

There are lots of command-line e-mail programs. Do a search, like:

https://www.google.com/search?q=bulk...command%20line

If you just must script a command-line e-mail client that uses OAUTH2
(although not actually necessary), you'll have to read up on Google's
Gmail API on OAUTH2 token generation, like:

https://developers.google.com/gmail/...auth2-protocol

OAUTH1 was a protocol. Google and Microsoft degraded OAUTH2 into a
framework, so each provider can do it their own way.

From the main developer of OAUTH1 and also OAUTH2 (you'll see Eran
credited in the RFCs):
https://vimeo.com/52882780
(gee, I wonder why this video isn't at Google's Youtube)

OAUTH, and especially version 2, was never about providing /you/ with
more security regarding logins to your account. It was always about
tracking which host was requesting a connection to an account, and the
whole point of the client have to store tokens (that have to get
refreshed) that were negotiated with the server to track the host that
wanted access. An OAUTH2 client on host-1 gets different tokens than an
OAUTH2 client on host-2, and client-1 on host-1 gets different tokens
than client-2 also on host-1, and why the server gets to track which
client on which host is requesting access.

On 2020-03-22 23:36, VanguardLH wrote:
T wrote:

Any of you guys know of a command line application that
will allow me to send mail to an smtp server that uses
OAuth2 authentication (google, yahoo, etc.)?

For Gmail, don't use OAUTH2. Use the standard login credentials
(username & password) authentication. Just make sure you configure the
server-side setting in your Gmail account to "Allow less secure apps".
With that enabled, you don't need an e-mail client that does OAUTH2. By
just using the sign-in credentials (no OAUTH2 tokens), you could use
Powershell in Windows, like:

https://www.howtogeek.com/120011/stu...xtra-software/

That script uses the SMTP client included in .NET Framework. Because
Gmail demands SSL/TLS connections is why there is the line in the script
of $SMTPClient.EnableSsl = $true.

There are lots of command-line e-mail programs. Do a search, like:

https://www.google.com/search?q=bulk...command%20line

If you just must script a command-line e-mail client that uses OAUTH2
(although not actually necessary), you'll have to read up on Google's
Gmail API on OAUTH2 token generation, like:

https://developers.google.com/gmail/...auth2-protocol

OAUTH1 was a protocol. Google and Microsoft degraded OAUTH2 into a
framework, so each provider can do it their own way.

From the main developer of OAUTH1 and also OAUTH2 (you'll see Eran
credited in the RFCs):
https://vimeo.com/52882780
(gee, I wonder why this video isn't at Google's Youtube)

OAUTH, and especially version 2, was never about providing /you/ with
more security regarding logins to your account. It was always about
tracking which host was requesting a connection to an account, and the
whole point of the client have to store tokens (that have to get
refreshed) that were negotiated with the server to track the host that
wanted access. An OAUTH2 client on host-1 gets different tokens than an
OAUTH2 client on host-2, and client-1 on host-1 gets different tokens
than client-2 also on host-1, and why the server gets to track which
client on which host is requesting access.


Hi Vanguard,

I should have probably mentioned that Google is discontinuing
Less Secure Apps for all the G-suite clients in July. So
use OAuth2 or go elsewhere, say zoho mail. Google
"equivocates" on their plans for non-g-suite users.

An yes, I think OAuth is a bit of a joke too, but neither
one of use get a vote on it.

Do you specifically know of a command line utility to eMail
that supports OAuth2?

-T

T wrote:
[...]

Hi Vanguard,

I should have probably mentioned that Google is discontinuing
Less Secure Apps for all the G-suite clients in July. So
use OAuth2 or go elsewhere, say zoho mail. Google
"equivocates" on their plans for non-g-suite users.

An yes, I think OAuth is a bit of a joke too, but neither
one of use get a vote on it.

Do you specifically know of a command line utility to eMail
that supports OAuth2?

You describe a false dilemma.

As has been explained several times, also in the recent past, one can
use (Google) 'App password's *instead of* OAuth2. When using App
passwords, 'Less secure app access' can of course be Off (otherwise
there would be no point using App passwords).

Frank Slootweg wrote:

T wrote:

I should have probably mentioned that Google is discontinuing
Less Secure Apps for all the G-suite clients in July. So
use OAuth2 or go elsewhere, say zoho mail. Google
"equivocates" on their plans for non-g-suite users.

An yes, I think OAuth is a bit of a joke too, but neither
one of use get a vote on it.

Do you specifically know of a command line utility to eMail
that supports OAuth2?

You describe a false dilemma.

As has been explained several times, also in the recent past, one can
use (Google) 'App password's *instead of* OAuth2. When using App
passwords, 'Less secure app access' can of course be Off (otherwise
there would be no point using App passwords).

As I recall from reading Google's help articles on app passwords, 2FA
(two factor authorization) must be enabled. So, you can avoid using
OAUTH2 by creating and using a password for an app (which, I think, has
to be unique to each app, so the server gets to track which client on
which host is requesting access, just as with OAUTH2), but then you have
to get nuisanced with 2FA to access your account.

https://support.google.com/accounts/answer/185833?hl=en
"App Passwords can only be used with accounts that have 2-Step
Verification turned on."

Yep, I was right. You can use app passwords (to eliminate having to use
OAUTH2), but then you get nuisanced with forced use of 2FA.

With mobile devices (phones) now generating the most e-mail traffic, 2FA
isn't as much a hassle for phone e-mailers, because they're already on
the phone where they'll get prompted via 2FA to allow access to their
account. For other users (desktops, tables w/o cellular, notebooks,
laptops, etc), 2FA means toting along some other device (your phone)
when you want to use your account.

For non-phone e-mailers, probably the most convenient 2FA method is by
using a USB dongle as a security key. Then you don't have to get
nuisanced with okaying the access via another device.

https://support.google.com/accounts/answer/6103523

So, that so-called free Gmail account is no longer free. The cost is
getting nuisanced with 2FA (to use app passwords), or with having to buy
a security dongle. For non-G Suite users (free accounts), the obvious
choice is to avoid Google's bogus claim of OAUTH being more secure [to
users] enable the "Allow less secure apps" setting. If Google removes
that option, they will lose many freeloaders that move to a more
user-friendly (less interfering) e-mail service. I've never been able
to adopt my Gmail account as my primary account, because their
server-side rules set sucks. Their rules are searches instead of
filters, and their searches are too greedy (in regex parlance) or too
broad, plus there is no flow control of exercising the rules (e.g.,
there is no stop-clause to prevent side effects of exercising more rules
against the same message). With Gmail, and to have decent rules, you
have to employ client-side rules. To me, Gmail is my garbage and backup
e-mail account. You can't even disable their server-side anti-spam
filtering and employ your own solution. Google took away that option
many years ago.

For G-Suite accounts, well, those are business accounts, and businesses
should expect costs for using e-mail. Either businesses will absorb the
cost of app passwords + 2FA/security dongle, or they'll go elsewhere.
Sorry, but when I see a "business" that uses a Gmail address, I'm sure
that isn't really a business but some SOHO operation. That's assuming
the G-Suite admin/security console account doesn't allow control over
the type of clients that can access the accounts.

https://gsuiteupdates.googleblog.com...incorrect.html

Google wants to hide that OAUTH can be hacked, and has been. OAUTH2
became a framework versus OAUTH1 which was a protocol. As a result,
each OAUTH2 provider can implement the framework differently. How
secure it is depends on the expertise of the team involved in
implementing the framework. Eran Hammer already outlined some
stupidities of OAUTH2 back in 2012. More have cropped up, mostly due to
differing implementations of the OAUTH2 framework.

https://www.google.com/search?q=oauth2%20vulnerable

Moving authentication to client side seems just so stupid. Oh yeah,
let's hope app authors know how to do OAUTH2. Wrong!

In article , VanguardLH
wrote:

With mobile devices (phones) now generating the most e-mail traffic, 2FA
isn't as much a hassle for phone e-mailers, because they're already on
the phone where they'll get prompted via 2FA to allow access to their
account. For other users (desktops, tables w/o cellular, notebooks,
laptops, etc), 2FA means toting along some other device (your phone)
when you want to use your account.

using 2fa does not require toting along anything.

install a totp utility on whatever device, which can even autofill the
code, making it hassle-free.

For non-phone e-mailers, probably the most convenient 2FA method is by
using a USB dongle as a security key. Then you don't have to get
nuisanced with okaying the access via another device.

a physical key is more secure, however, much *less* convenient,
especially for someone using multiple computers where the key would
need to be swapped among them.

On 3/23/2020 12:37 PM, nospam wrote:
In article , VanguardLH
wrote:

With mobile devices (phones) now generating the most e-mail traffic, 2FA
isn't as much a hassle for phone e-mailers, because they're already on
the phone where they'll get prompted via 2FA to allow access to their
account. For other users (desktops, tables w/o cellular, notebooks,
laptops, etc), 2FA means toting along some other device (your phone)
when you want to use your account.

using 2fa does not require toting along anything.

install a totp utility on whatever device, which can even autofill the
code, making it hassle-free.

For non-phone e-mailers, probably the most convenient 2FA method is by
using a USB dongle as a security key. Then you don't have to get
nuisanced with okaying the access via another device.

a physical key is more secure, however, much *less* convenient,
especially for someone using multiple computers where the key would
need to be swapped among them.

While I have not tried any of the CLI programs myself a quick "Google"
search with the words "oath2 command line client", minus the quotes,
turned up quite a few programs/methods that seem to do what you are
asking for.

On 3/23/2020 12:37 PM, nospam wrote:
In article , VanguardLH
wrote:

With mobile devices (phones) now generating the most e-mail traffic, 2FA
isn't as much a hassle for phone e-mailers, because they're already on
the phone where they'll get prompted via 2FA to allow access to their
account. For other users (desktops, tables w/o cellular, notebooks,
laptops, etc), 2FA means toting along some other device (your phone)
when you want to use your account.

using 2fa does not require toting along anything.

install a totp utility on whatever device, which can even autofill the
code, making it hassle-free.

For non-phone e-mailers, probably the most convenient 2FA method is by
using a USB dongle as a security key. Then you don't have to get
nuisanced with okaying the access via another device.

a physical key is more secure, however, much *less* convenient,
especially for someone using multiple computers where the key would
need to be swapped among them.

Even with OAuth2 spelled wrong google figured out what I asked for
anyway. Sorry about the misspelling.

On Mon, 23 Mar 2020 12:27:50 -0500, VanguardLH wrote:

As I recall from reading Google's help articles on app passwords, 2FA
(two factor authorization) must be enabled. So, you can avoid using
OAUTH2 by creating and using a password for an app (...), but then you have
to get nuisanced with 2FA to access your account.

https://support.google.com/accounts/answer/185833?hl=en
"App Passwords can only be used with accounts that have 2-Step
Verification turned on."

Yep, I was right. You can use app passwords (to eliminate having to use
OAUTH2), but then you get nuisanced with forced use of 2FA.


My app password still works, and I do not have 2FA turned on.
Two factor authentication had to be enabled to _create_ the app password.
The app password still works after I turned off 2FA.

Your link is for regular Google accounts and not a G-Suite accounts.
Mine is also a regular Google (Gmail) account and not a G-Suite account.
OTOH, T appears to be asking about G-suite accounts.

"The difference between Gmail, a Google Account, and G Suite accounts"
https://www.techrepublic.com/blog/google-in-the-enterprise/the-difference-between-gmail-a-google-account-an-apps-account-and-an-apps-for-business-account/


--
Kind regards
Ralph

VanguardLH wrote:
Frank Slootweg wrote:

T wrote:

I should have probably mentioned that Google is discontinuing
Less Secure Apps for all the G-suite clients in July. So
use OAuth2 or go elsewhere, say zoho mail. Google
"equivocates" on their plans for non-g-suite users.

An yes, I think OAuth is a bit of a joke too, but neither
one of use get a vote on it.

Do you specifically know of a command line utility to eMail
that supports OAuth2?

You describe a false dilemma.

As has been explained several times, also in the recent past, one can
use (Google) 'App password's *instead of* OAuth2. When using App
passwords, 'Less secure app access' can of course be Off (otherwise
there would be no point using App passwords).

As I recall from reading Google's help articles on app passwords, 2FA
(two factor authorization) must be enabled. So, you can avoid using
OAUTH2 by creating and using a password for an app (which, I think, has
to be unique to each app, so the server gets to track which client on
which host is requesting access, just as with OAUTH2), but then you have
to get nuisanced with 2FA to access your account.

https://support.google.com/accounts/answer/185833?hl=en
"App Passwords can only be used with accounts that have 2-Step
Verification turned on."

Yep, I was right. You can use app passwords (to eliminate having to use
OAUTH2), but then you get nuisanced with forced use of 2FA.

AFAIK, that is incorrect (as in: not fully correct).

You must have 2-Step Verification [1] turned on to *create*
('generate') an App password, but not to *use* it. I.e. after setting
the App password, you again can turn off 2-Step Verification.

This was described by Ralph Fox in his Sep 9, 2018 post in
alt.windows7.general.

http://al.howardknight.net/?STYPE=msgid&MSGI=%3C0ud8pd5m6ler41kl54cdelql22rhb bed81%404ax.com%3E

I followed that procedure and it worked perfectly and still works, so
unless something has changed, 2-Step Verification does not have to be
on to *use* and App password.

So to summarize, I have:

- App password
- Less secure app access: Off
- 2-Step Verification: Off

[...]

[1] 2-Step Verification is not the same as Two-Factor Authentication, so
using the acronym 2FA is not correct.
https://en.wikipedia.org/wiki/Multi-factor_authentication
"Two-step verification or two-step authentication is a method of
confirming a user's claimed identity by utilizing something they know
(password) and a second factor /other/ than something they have or
something they are."

On 2020-03-23 11:57, Ralph Fox wrote:
T appears to be asking about G-suite accounts.

Yes.

And in general, I would like a command line utility
to eMail to other OAuth2 servers as well.

Ralph Fox wrote:

My app password still works, and I do not have 2FA turned on. Two
factor authentication had to be enabled to _create_ the app password.
The app password still works after I turned off 2FA.

Oh, interesting. Comply with their initial requirement to enable 2FA,
get the app password, then disable the 2FA option, and the app password
still works. I like it! Wonder when Google will discover that
loophole.

Your link is for regular Google accounts and not a G-Suite accounts.
Mine is also a regular Google (Gmail) account and not a G-Suite
account. OTOH, T appears to be asking about G-suite accounts.

"The difference between Gmail, a Google Account, and G Suite accounts"
https://www.techrepublic.com/blog/google-in-the-enterprise/the-difference-between-gmail-a-google-account-an-apps-account-and-an-apps-for-business-account/

I've never had a G-Suite account, so I've never seen the admin/console
account that determines configuration of member accounts. I couldn't
get a pic via Google Images to show all the settings.

The OP (and I gave the link to an article from Google) said Google is
dropping the "Allow less secure apps" option for G-Suite accounts.
Could be there's something in the admin/console account that would
compensate. The OP, T, could go look since he has a G-Suite account.
I've never found anything that draws me to a G-Suite account to pay for
those enhanced accounts: $6/month per user for Basic, $12/month per user
for Business, or $25/month per user for Enterprise. G-Suite Education
is free, but I'm not going back to college to pay for overpriced
tuition, books, etc just to get a free G-Suite account that gives me
nothing more than I already want with a free account. If I later need
collaboration, I'll find a free way to do it.

Frank Slootweg wrote:

VanguardLH wrote:
Frank Slootweg wrote:

T wrote:

I should have probably mentioned that Google is discontinuing
Less Secure Apps for all the G-suite clients in July. So
use OAuth2 or go elsewhere, say zoho mail. Google
"equivocates" on their plans for non-g-suite users.

An yes, I think OAuth is a bit of a joke too, but neither
one of use get a vote on it.

Do you specifically know of a command line utility to eMail
that supports OAuth2?

You describe a false dilemma.

As has been explained several times, also in the recent past, one can
use (Google) 'App password's *instead of* OAuth2. When using App
passwords, 'Less secure app access' can of course be Off (otherwise
there would be no point using App passwords).

As I recall from reading Google's help articles on app passwords, 2FA
(two factor authorization) must be enabled. So, you can avoid using
OAUTH2 by creating and using a password for an app (which, I think, has
to be unique to each app, so the server gets to track which client on
which host is requesting access, just as with OAUTH2), but then you have
to get nuisanced with 2FA to access your account.

https://support.google.com/accounts/answer/185833?hl=en
"App Passwords can only be used with accounts that have 2-Step
Verification turned on."

Yep, I was right. You can use app passwords (to eliminate having to use
OAUTH2), but then you get nuisanced with forced use of 2FA.

AFAIK, that is incorrect (as in: not fully correct).

You must have 2-Step Verification [1] turned on to *create*
('generate') an App password, but not to *use* it. I.e. after setting
the App password, you again can turn off 2-Step Verification.

This was described by Ralph Fox in his Sep 9, 2018 post in
alt.windows7.general.

http://al.howardknight.net/?STYPE=msgid&MSGI=%3C0ud8pd5m6ler41kl54cdelql22rhb bed81%404ax.com%3E

I followed that procedure and it worked perfectly and still works, so
unless something has changed, 2-Step Verification does not have to be
on to *use* and App password.

So to summarize, I have:

- App password
- Less secure app access: Off
- 2-Step Verification: Off

[...]

[1] 2-Step Verification is not the same as Two-Factor Authentication, so
using the acronym 2FA is not correct.
https://en.wikipedia.org/wiki/Multi-factor_authentication
"Two-step verification or two-step authentication is a method of
confirming a user's claimed identity by utilizing something they know
(password) and a second factor /other/ than something they have or
something they are."

So, you don't need OAUTH2 just because Google is dropping the "Allow
less secure apps" option for G-Suite accounts. You can get an app
password (and disable 2FA afterward) for your command-line e-mail
client.

I don't use command-line e-mail clients, because I'm not spamming or
sending UCE/UBE mailings. I'd end up mentioning what I found in an
online search, but you can do that. You could search on "command line
e-mail client" or "bulk mail programs" depending on just what you plan
to do with the e-mail program.

VanguardLH wrote:
Frank Slootweg wrote:
[...]
So to summarize, I have:

- App password
- Less secure app access: Off
- 2-Step Verification: Off
[...]

So, you don't need OAUTH2 just because Google is dropping the "Allow
less secure apps" option for G-Suite accounts. You can get an app
password (and disable 2FA afterward) for your command-line e-mail
client.

['you' being the OP ('T').]

Indeed. So now we'll have to see whether T takes the advice he gets or
rejects it without even trying it, like he did the last time. Looking at
his response to Ralph, it doesn't look promising.

I don't use command-line e-mail clients, because I'm not spamming or
sending UCE/UBE mailings. I'd end up mentioning what I found in an
online search, but you can do that. You could search on "command line
e-mail client" or "bulk mail programs" depending on just what you plan
to do with the e-mail program.

I don't use command-line e-mail clients either [1], but T should be
able to find/use many, because for Google/Gmail he only needs one which
can use username/password (and stuff like SSL/TLS and setting the SMTP
port).

[1] Well, I am using one (ssmtp), but only for sending a backup report
to myself.

VanguardLH wrote:
Ralph Fox wrote:

My app password still works, and I do not have 2FA turned on. Two
factor authentication had to be enabled to _create_ the app password.
The app password still works after I turned off 2FA.

Oh, interesting. Comply with their initial requirement to enable 2FA,
get the app password, then disable the 2FA option, and the app password
still works. I like it! Wonder when Google will discover that
loophole.

I don't think it's a loophole. IMO, it's quite/somewhat sane to
require increased security when creating an App password and not needing
increased security when the App password is used.

But of course as long as we cannot find a Google document which
describes this, we cannot know for sure whether it's a loophole or not.

[...]