OAuth2?

Frank Slootweg wrote:

I don't use command-line e-mail clients either, 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).

If he can't manage to do his own online search for a command-line e-mail
client (that will do encrypted SMTP connects), I already gave him a very
short Powershell to do that. Now he just needs to create an app
password in his Google account to use with the Powershell script or
whatever command-line e-mail client he wants.

On 2020-03-24 09:31, VanguardLH wrote:
If he can't manage to do his own online search for a command-line e-mail
client (that will do encrypted SMTP connects), I already gave him a very
short Powershell to do that. Now he just needs to create an app
password in his Google account to use with the Powershell script or
whatever command-line e-mail client he wants.

Hi Vanguard,

What makes you think I did not do an extensive search?
(Hint: I spent hours.) You sure do jump to a lot of
conclusions.

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

And I have a lot of customers using g-suite.

As of now, I have not found a command line utility that
supports OAuth2.

Oh, and I am half way through writing one myself. I
am having a few glitches with Zef, Git, and tar files,
but I will prevail.

And I have already written modules to eMail to non-OAuth
smtp server. And yes, they support SSL/TLS.

-T

On Wed, 25 Mar 2020 10:16:49 -0700, T wrote:

On 2020-03-24 09:31, VanguardLH wrote:
If he can't manage to do his own online search for a command-line e-mail
client (that will do encrypted SMTP connects), I already gave him a very
short Powershell to do that. Now he just needs to create an app
password in his Google account to use with the Powershell script or
whatever command-line e-mail client he wants.

Hi Vanguard,

What makes you think I did not do an extensive search?
(Hint: I spent hours.) You sure do jump to a lot of
conclusions.

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.


I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.


And I have a lot of customers using g-suite.

As of now, I have not found a command line utility that
supports OAuth2.

Oh, and I am half way through writing one myself. I
am having a few glitches with Zef, Git, and tar files,
but I will prevail.

And I have already written modules to eMail to non-OAuth
smtp server. And yes, they support SSL/TLS.

-T


--
Kind regards
Ralph

On 2020-03-25 11:04, Ralph Fox wrote:
I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.

What eMail client are you using?

The link I sent does to apply to web browsers.

[Disclaimer: Intentional morph to get past your silly fingers-in-ears
filter/attitude.]

T wrote:
On 2020-03-24 09:31, VanguardLH wrote:
If he can't manage to do his own online search for a command-line e-mail
client (that will do encrypted SMTP connects), I already gave him a very
short Powershell to do that. Now he just needs to create an app
password in his Google account to use with the Powershell script or
whatever command-line e-mail client he wants.

Hi Vanguard,

What makes you think I did not do an extensive search?
(Hint: I spent hours.) You sure do jump to a lot of
conclusions.

Try to read in context and for comprehension. As usual, the one
jumping to conclusions is you.

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Nope, *you* ignored most - if not all - of the conversation. That
explained - several times - that you do *not* need OAuth2 for Google/
Gmail, but can use App passwords instead.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we?ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

And I have a lot of customers using g-suite.

Irrelevant. As we've explained umpteen times, you don't need 'Less
secure app access'.

As of now, I have not found a command line utility that
supports OAuth2.

You don't need OAuth2 for Google/Gmail. In your OP, you also mention
Yahoo, but that doesn't need OAuth2 either, at least not for normal
accounts (I just re-tested this).

Bottom line: Like last year, you keep harping on OAuth2 without trying
the solutions which several people have proposed. And you expect people
to continue to try to help you!?

Oh, and I am half way through writing one myself. I
am having a few glitches with Zef, Git, and tar files,
but I will prevail.

And I have already written modules to eMail to non-OAuth
smtp server. And yes, they support SSL/TLS.

On 2020-03-25 11:31, Knarf Gewtools wrote:
[Disclaimer: Intentional morph to get past your silly fingers-in-ears
filter/attitude.]

Thank you for helping me update my kill file

T wrote:

VanguardLH wrote:

If he can't manage to do his own online search for a command-line e-mail
client (that will do encrypted SMTP connects), I already gave him a very
short Powershell to do that. Now he just needs to create an app
password in his Google account to use with the Powershell script or
whatever command-line e-mail client he wants.

What makes you think I did not do an extensive search?
(Hint: I spent hours.) You sure do jump to a lot of
conclusions.

Based on your past performance in your posts here. If you had done
research, you wouldn't be asking respondents to duplicate that effort by
reporting which ones you already investigated.

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Already proven incorrect by several respondents.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we¢ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

And I have a lot of customers using g-suite.

Yep, I already gave that URL to Google's article. Doesn't preclude you
from using an app password.

As of now, I have not found a command line utility that
supports OAuth2.

Don't see why they would bother. To whose OAUTH2 framework API would
they write their code? Google's OAUTH2 implementation may differ from
someone else's. That's why v2 became a framework instead of a protocol.

Plus some GUI e-mail clients have a CLI (Command Line Interface) to
access the e-mail client from the command line. Thunderbird supports
OAUTH2 and has a CLI. Use the -compose command-line switch along with
all the arguments to send from the command line.

http://kb.mozillazine.org/Command_li...Thunderbird%29
https://stackoverflow.com/questions/...o-next-command

I don't have Thunderbird to see if their CLI merely composes the
messages and you end up stuck in their GUI client awaiting you to click
the Send button, or if the Send gets performed by the GUI client as part
of the CLI command (no user interaction required). I remember using the
mailto: protocol with its myriad of arguments, but all that does is send
the arguments to whatever is the currently assigned MailTo handler
(defined in the registry) which halts the process with the e-mail client
opening its new-message compose window. I still had to click on the
Send button. I suppose you could use AutoHotkey, or another script
handler that can detect when certain windows open, to automatically
click on the Send button.

Another e-mail program with a CLI is Bat!. See:

https://www.ritlabs.com/en/products/...mmand-line.php

They added OAUTH back in 2016. See:

https://www.ritlabs.com/en/news/6777/

Never used it, so I don't know if using their CLI results in sending
without user interaction, or if it merely passes the arguments to their
new-message compose window whereupon you have to click the Send button.

eM Client (I use it) also has command-line arguments, like:

MailClient.exe /mailurl ?subject=hello&body=bodyte xt"

It supports RFC 6068 (mailto protocol). However, I've not used it, so I
don't know if you're dumped into a new-message compose window and have
to click the Send button, or if the message goes without user
intervention. It supports OAUTH2.

Most search on a command-line e-mail client that supports OAUTH2 end up
reading about code users are coming up with to do that. Most don't seem
to contain all the functions needed for all the management tasks
involved with OAUTH2.

There are e-mail clients that use Google's Mail API instead of the
standard e-mail protocols (POP, IMAP, STMP). You can find articles,
like https://www.npmjs.com/package/gmail-cli, telling you how to use the
API. However, using the API means you have to define a project at
Google to register your e-mail client. The problem that I've found with
using a Google project to use their Mail API is there is a maximum quota
regarding how many requests can be issued against their API server
within some period, like a day. I hit the problem with eM Client. It
uses the Mail API at Google for all Gmail accounts defined within it.
By default, it uses the API instead of the standard protocols unless you
do a custom new account define. Users started getting error messages
saying they had exceeded the API quota. eM Client, Inc. has just one
Google project to access the API, and for both paid and free customers
of that client. The same project ID is specified in the API request.
When their customers started getting API max-count errors, eM Client
upped their quota (costs money) in their project to let their clients
have a larger API request quota. That lasted all of 3 days. I have up
on using the default in eM Client of using the Gmail API when creating a
Gmail account in eM Client, and went to a custom account creation with
it using IMAP/SMTP. Even with using their API, you still need to write
the code to handle the token passing, managing secrets, refreshing
tokens, expiring them, and all the crap involved with OAUTH2.

https://developers.google.com/identity/protocols/oauth2

That says how to use the API to do OAUTH2, but that seems to require you
create a project for API access, and that means quota restrictions.
There are libs already built to use the API method, so pick one that
matches the language you like for coding.

https://developers.google.com/api-client-library

Since using the API means having to use a service account (aka project),
some help is available on how to do that, like:

https://www.emailarchitect.net/easen...ce_account.htm
https://www.emailarchitect.net/easen...ject_oauth.htm

None of this stuff is easy to figure out or get functional bug-free
code, and probably why simplistic command-line only e-mail clients don't
bother with all this ... um, "stuff". Tis simple enough, also, to use
an SMTP server other than Google's to eliminate all the OAUTH crap, and
just use an "insecure" (which it is not) access via POP, IMAP, or SMTP.
Being obstinate doesn't resolve the requirement to send e-mails from the
command line. Lots of non-Gmail SMTP providers have no such "Allow less
secure apps" option, and lots of those have free accounts.

Doctor, it hurts when I do this. Then don't do that.

If Gmail doesn't do what you want, there are plenty of alternatives.

On 2020-03-25 19:09, VanguardLH wrote:
If Gmail doesn't do what you want, there are plenty of alternatives.

I don't think you get the concept of multiple customers
with multiple needs. I can only work with what I
am presented. Sometimes they follow my suggestions
and most of the time they don't. And g-suite is
a wonderful tool for several of my customers and
has solved a lot of problems for them.

With Thunderbird, you can do everything from the command line EXCEPT
push the "Send" button. I eMail my purchase orders
out this way. Yes, I wrote the program. (It is damned
slick too!)

As far as my research goes, I have found ZERO CLI apps that
will do OAuth2. I have not found a single one that says it
supports OAuth2 and then falls apart when tried. So no
references to any supplied.

This is the way I need to do it. I was concise on what I
am after. And at this point, I really serious do not
care if you like other methods of doing things. This
is method I need to use.

So do you or do you not know of a CLI tool that
will do OAuth2 and that includes the "Send" button?

Gee Wiz Vanguard, I already have written eMail modules
to handle non-OAuth2 servers. Do you seriously think
I'd put myself thought this OAuth2 **** if I was not
forced to? And yes, I think OAuth is ****, but I
don't get a vote on it.

Vanguard are a walking encyclopedia of Windows and you
have been very helpful in the past, which I seriously
appreciate, but sometimes you go off on tangents and
get quite condescending in the process.

On Wed, 25 Mar 2020 11:12:02 -0700, T wrote:
On 2020-03-25 11:04, Ralph Fox wrote:
On Wed, 25 Mar 2020 10:16:49 -0700, T wrote:

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.

What eMail client are you using?

I have two email clients.
The email client using an app password is Forté Agent.


The link I sent does to apply to web browsers.

In your link, https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html,
I see no mention of web browsers.


--
Kind regards
Ralph

On 2020-03-25 22:14, Ralph Fox wrote:
On Wed, 25 Mar 2020 11:12:02 -0700, T wrote:
On 2020-03-25 11:04, Ralph Fox wrote:
On Wed, 25 Mar 2020 10:16:49 -0700, T wrote:

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.

What eMail client are you using?

I have two email clients.
The email client using an app password is Forté Agent.

When I asked Google tech support about their plans for
regular eMail accounts, they "equivocated". I don't
see them dropping less secure apps any time soon for
regular accounts as the push back would be something
to behold



The link I sent does to apply to web browsers.

In your link, https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html,
I see no mention of web browsers.



I forget the "not" in "does not". AAAHHHHH

:'(

T wrote:

On 2020-03-25 19:09, VanguardLH wrote:
If Gmail doesn't do what you want, there are plenty of alternatives.

I don't think you get the concept of multiple customers
with multiple needs. I can only work with what I
am presented. Sometimes they follow my suggestions
and most of the time they don't. And g-suite is
a wonderful tool for several of my customers and
has solved a lot of problems for them.

With Thunderbird, you can do everything from the command line EXCEPT
push the "Send" button. I eMail my purchase orders
out this way. Yes, I wrote the program. (It is damned
slick too!)

As far as my research goes, I have found ZERO CLI apps that
will do OAuth2. I have not found a single one that says it
supports OAuth2 and then falls apart when tried. So no
references to any supplied.

This is the way I need to do it. I was concise on what I
am after. And at this point, I really serious do not
care if you like other methods of doing things. This
is method I need to use.

So do you or do you not know of a CLI tool that
will do OAuth2 and that includes the "Send" button?

Gee Wiz Vanguard, I already have written eMail modules
to handle non-OAuth2 servers. Do you seriously think
I'd put myself thought this OAuth2 **** if I was not
forced to? And yes, I think OAuth is ****, but I
don't get a vote on it.

Vanguard are a walking encyclopedia of Windows and you
have been very helpful in the past, which I seriously
appreciate, but sometimes you go off on tangents and
get quite condescending in the process.

In your unpublished white paper, just what is the source of condemning
the use of app passwords to preclude that as a solution as the
workaround already deliberately offered by Google? You say you must use
OAUTH2, but don't substantiate that claim. Customers will always make
demands that cannot be achieved. You'll have to get used to saying No.
Give them a summary of your research, but likely they won't bother
because they still want something they can't have.

Since you're the one that would building the solution for your
customers, how would they even know app passwords were used as the
workaround supplied by Google? They just want a CLI client (or maybe
it's you and only you that wants one) that can use Gmail. Do they
really care how it happens? When they use a regular GUI e-mail client,
do they care about what are the POP, IMAP, SMTP, Exchange, or Gmail API
commands that get sent by the client?

Google's workaround appears not only designed to allow continued use of
old clients that don't support OAUTH2, but even scripts or CLI clients
that make simple SMTP commands without any OAUTH2 overhead.

mailto: and Thunbderbird, along with other OAUTH2 capable GUI clients
using their CLI typically end up inputting the arguments into the fields
in their new-message compose window, but they don't do the Send
automatically. Okay, so why can't you use Autohotkey, AutoIt, or
another window capture tool to notice when that new-message window
appears to push the Send button? Handling windows is one of the fortes
of those types of programs. Typically you don't even have to write any
code. You use their recorder to monitor your keystrokes or mouse
clicks, and they link them to the window's object, so it doesn't matter
where on the screen the window appears next. You might not find a
pre-written CLI client that does what you want because there is almost
no demand for one, especially due to the existing workaround.

No, I haven't bothered searching for a OAUTH2-capable CLI e-mail client
because I've never had the need for one. I'd use an SMTP server that
doesn't force use of OAUTH2, or I'd use the app password workaround. My
solution wouldn't require writing new code, or borrowing from others and
hoping they got it right. And I wouldn't be wasting time on a solution
that already exists. Sorry, but I'm not the only one being obstinate
here. I say to use the workaround, because it already exists. You say
no, but without cause. Guess we're at an impass. My background is in
hardware and software QA, and the objective was to get a working
solution, not spend time on an ideal solution that wastes tons more
manhours, delays when the solution becomes available, and will require
more manhours to debug for reliable operation. QA always had a time
restraint to get the job done, not an open-ended vague timeline.

Even with TB's CLI that ends up halting at their new-message compose
window, that doesn't preclude you from employing additional software to
hit the Send button. Even without using AutoHotkey, or similar, you
have not explained how your solution will get used to know why, for
example, halting at the new-message compose window in a GUI e-mail
client that has a CLI is not a solution for you. Is the e-mail going to
send status of a backup job after it finishes? Is it to be a scheduled
event in Task Scheduler? Why is halting at the new-message compose
window a fail condition? You want a solution but don't explain the
requirements, like you need to keep it all a secret. No one besides you
even knows why Gmail is a requirement to send e-mails using a CLI
client. Just because your customer is using G Suite does not mandate
that Gmail be used to send CLI-generated messages.

In addition, I mentioned The Bat! client, because I've heard it is more
scriptable. If spammers like it, should be good for you, too. Does
what they want, so a subset of its abilities might be doable for your
OAUTH2-demanded use. One of the command-line arguments is /MAIL along
with all the typical mailto arguments. Another is /SEND which,
according to its description, "If this parameter is used, the created
message will be sent as soon as it has been created." Sure sounds like
a GUI e-mail client with a CLI that fits your requirements (although the
reasons for such have not been mentioned). Hard to come up with a
solution when there is no Functional Spec or Engineering Spec describing
just what the solution is needed, the requirements, and the Why's for
those requirements. You want others to come up with a solution that
isn't defined, and OAUTH2 is not sufficient to explain why your solution
cannot employ a workaround to avoid OAUTH2.

VanguardLH wrote:

In addition, I mentioned The Bat! client, ...
One of the command-line arguments is /MAIL along with all the typical
mailto arguments. Another is /SEND which, according to its
description, "If this parameter is used, the created message will be
sent as soon as it has been created."

Forgot to cite where I got the info on the command-line switches and
their args for The Bat! client, which are described at:

https://www.ritlabs.com/en/products/...mmand-line.php

I don't use Bat!, so I'm just going by their help article.

On Wed, 25 Mar 2020 21:09:01 -0500, VanguardLH wrote:

Plus some GUI e-mail clients have a CLI (Command Line Interface) to
access the e-mail client from the command line. Thunderbird supports
OAUTH2 and has a CLI. Use the -compose command-line switch along with
all the arguments to send from the command line.

http://kb.mozillazine.org/Command_li...Thunderbird%29
https://stackoverflow.com/questions/...o-next-command

I don't have Thunderbird to see if their CLI merely composes the
messages and you end up stuck in their GUI client awaiting you to click
the Send button, or if the Send gets performed by the GUI client as part
of the CLI command (no user interaction required). I remember using the
mailto: protocol with its myriad of arguments, but all that does is send
the arguments to whatever is the currently assigned MailTo handler
(defined in the registry) which halts the process with the e-mail client
opening its new-message compose window. I still had to click on the
Send button. I suppose you could use AutoHotkey, or another script
handler that can detect when certain windows open, to automatically
click on the Send button.


I can confirm that an AutoIt script is quite capable of
launching Thunderbird with the CLI and then poking Send.
(FWIW it is easier to use the accelerator than the button.)



--
Kind regards
Ralph

Γ��ιζε, βάζε, β�άζε, ανακάτονε.
Καίε φωτιά και τ�ίζε, κόχλαζε νε�ό!

On Wed, 25 Mar 2020 22:41:55 -0700, T wrote:
On 2020-03-25 22:14, Ralph Fox wrote:
On Wed, 25 Mar 2020 11:12:02 -0700, T wrote:
On 2020-03-25 11:04, Ralph Fox wrote:
On Wed, 25 Mar 2020 10:16:49 -0700, T wrote:

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.

What eMail client are you using?

I have two email clients.
The email client using an app password is Forté Agent.

When I asked Google tech support about their plans for
regular eMail accounts, they "equivocated". I don't
see them dropping less secure apps any time soon for
regular accounts as the push back would be something
to behold


Do you have another link which actually says that you won't be able
to use an app password with a G-suite account?


--
Kind regards
Ralph

On 2020-03-26 02:23, Ralph Fox wrote:
On Wed, 25 Mar 2020 22:41:55 -0700, T wrote:
On 2020-03-25 22:14, Ralph Fox wrote:
On Wed, 25 Mar 2020 11:12:02 -0700, T wrote:
On 2020-03-25 11:04, Ralph Fox wrote:
On Wed, 25 Mar 2020 10:16:49 -0700, T wrote:

Also, you ignored my specification that it support OAuth2.
Sorry, it has to support OAuth2.

Turning off less secure app access to G Suite accounts:
https://gsuiteupdates.googleblog.com...incorrect.html

Starting in June 2020, we’ll limit the ability for
less secure apps (LSAs) to access G Suite account
data.

I have turned off less secure apps in my regular Google (Gmail) account,
and my app password still works.

The above quote and blog link does not say that app passwords won't work.
I see no evidence there, that it has to be OAuth2 rather than an app password.

Turning off less secure apps here only stops me using my main Google
account password in programs like my email client. It does not stop
my app password.

What eMail client are you using?

I have two email clients.
The email client using an app password is Forté Agent.

When I asked Google tech support about their plans for
regular eMail accounts, they "equivocated". I don't
see them dropping less secure apps any time soon for
regular accounts as the push back would be something
to behold


Do you have another link which actually says that you won't be able
to use an app password with a G-suite account?

No, but I never really looked as what I need is to get
OAuth2 working. I am about 1/2 done with writing it myself.
So far I am able to get tokens back from server, but
have to figure out how to format the header-str-pairs
with MIME64 to send to an SMTP server, but I will get
there.