In article <t79r8f$1nuo$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

>
> Fun that in the same post you said "it's demonstrably wrong and you don't
> even realize it. " without, ofcourse, demonstrating anything.

i did demonstrate it. you are lying.

> Also fun is that you you have remained amadant that POP cannot be used to
> just download headers, while at some point providing a link to a /microsoft
> page/(1) describing exactly how to do that.

i never said pop cannot be used to download only headers. you are lying
again.

> (1) remember how you tried to attack me me for referring to microsoft as the
> source of my information ? *Ofcourse* you do the same yourself.

you are lying yet again.

you used microsoft as a reference for pop/imap, something they did not
create.

i pointed out that microsoft outlook, their own email app, contradicts
what that link said.

you're so lost that you don't understand the contradiction and why it's
a problem.

> You've also peppered your thread with - as always unproven, unsupported and
> even unexplained - claims that making POP3 behave, in regard to message
> retention, like IMAP is "impossible".

you're moving the goalposts.

don't think that's going to go unnoticed.

> Bottom line : you do not seem to know much of anything but are using your
> claiming as a method to make it /look/ as if you do.

projection.

nospam,

It seems we go back to our regular programming. Oh well.

>> :-D As someone who refuses to explain /anything/ you've lost the
>> privilege
>> of me explaining stuff to you. I thought I already made that quite
>> clear.
>
> as usual, you're avoiding answering the question, because you know
> you're over your head.

Another claim without explanation or underbuilding. Its worth ? Absolutily
nothing.

>> Besides, isn't that what that document you linked to describes ?
>
> nope. read it again.

Again trying to send me on a wild goose chase for something in there only
you know is in there.

> actually, i did, you just don't understand enough to realize it.

Another claim without explanation or underbuilding. Its worth ? Absolutily
nothing.

> it's supported by both the link i provided and microsoft itself, as
> well as common knowledge (except to you).

It might be, but you bashed me over trying to use Microsoft as source. The
above just makes you a hypicrite. Again.

Besides, you've posted just a link without any kind of explanation to how it
would support your stance. As such is just another claim without
explanation or underbuilding. Its worth ? Absolutily nothing.

> actually, i did, you just don't understand enough to realize it.

Chose your pick "no you didn't" or "Another claim without explanation or
underbuilding. Its worth ? Absolutily nothing."

> nope. you cited microsoft as a reference for pop/imap and i pointed
> out that their own email app contradicts what that link stated. do
> you not understand the problem there?

I do. You're making another claim without explanation or underbuilding.
Its worth ? Absolutily nothing.

> it's not to show off, but to demonstrate you aren't pretending to
> know more than you actually do.

Kid, I've asked you the same over-and-over-and-over again. To demonstrate
that you actually know anything by just supporting your own claims. You
categorically refused to do so. Why do you now think I will just throw you
a freebee and humour you by giving you exactly what you want ?

> actually, what you'd be doing is digging yourself a deeper hole,
> which is why you continue to avoid answering.

Actually, I offered to give you want you want. Under the condition you work
for it. But it looks like you rather stay willfully ignorant. Oh well.

>> Fun that in the same post you said "it's demonstrably wrong and you don't
>> even realize it. " without, ofcourse, demonstrating anything.
>
> i did demonstrate it. you are lying.

Then there should have been no problem for you to quote that demonstration,
just to prove beyond a shadow of a doubt that I'm lying. The fact that you
didn't just do that ...

>> Also fun is that you you have remained amadant that POP cannot be used to
>> just download headers, while at some point providing a link to a
>> /microsoft
>> page/(1) describing exactly how to do that.
>
> i never said pop cannot be used to download only headers. you are lying
> again.

[quote=you, <280520221257343334%nospam@nospam.invalid>]
you claim to know what imap is and how it differs from pop, so it
should be easy for you to explain how to read only headers it in
outlook, something which microsoft says is not possible.
[/quote]

In the above you certainly tried to make it sound as if, when I would not be
able to prove that a specific email client could not do it that, that would
be fault of the pop protocol. Or perhaps even both.

>> (1) remember how you tried to attack me me for referring to microsoft as
>> the
>> source of my information ? *Ofcourse* you do the same yourself.
>
> you are lying yet again.

Me using an MS reference

[quote=you, <310520220623425988%nospam@nospam.invalid>]
the mere fact that you're citing microsoft as a reference for email
standards indicates you know very little about email (or much else).
[/quote]

You using an MS reference

[quote=you, <310520220840328542%nospam@nospam.invalid>]
you claim to know what imap is and how it differs from pop, so it
should be easy for you to explain how to read only headers it in
outlook, something which microsoft says is not possible.
[/quote]

> you used microsoft as a reference for pop/imap, something they did
> not create.

Yes, and ? Whats your point ?

> i pointed out that microsoft outlook, their own email app,
> contradicts what that link said.

[quote=me, <t74vbg$657$1@gioia.aioe.org>]
LOL!!!!! The very first paragraph there describes how to configure Outlook
to do exactly that, just downloading headers. But here you are, trying to
convince us/me that that is *not* how Outlook works.
[/quote]

> you're so lost that you don't understand the contradiction and why
> it's a problem.

Can you quote where you tried to explain it to me ? No? I didn't think so.

>> You've also peppered your thread with - as always unproven, unsupported
>> and
>> even unexplained - claims that making POP3 behave, in regard to message
>> retention, like IMAP is "impossible".
>
> you're moving the goalposts.
>
> don't think that's going to go unnoticed.

[quote=you, <280520221034076953%nospam@nospam.invalid>]
given that imap can do many things that pop cannot, it's *impossible*
to 'make pop look like imap', at least not without magical powers.
[/quote]

Kid, I did not bring that up, you did. So much for "moving goalposts".

And by the way, your blatant lying did not go unnoticed here either. But
than again, whats new in that ? Nothing.

>> Bottom line : you do not seem to know much of anything but are using your
>> claiming as a method to make it /look/ as if you do.
>
> projection.

Yeah ! That must be it ! I'm certain of it !

On the other hand, its just another claim without explanation or
underbuilding. Its worth ? Absolutily nothing.

Regards,
Rudy Wieser

nospam,

[quote=you]
the mere fact that *you're citing microsoft as a reference for email
standards* indicates you know very little about email (or much else).
[/quote]
(bolding mine)

[quote=you]
you claim to know what imap is and how it differs from pop, so it
should be easy for you to explain how to read only headers it in
outlook, *something which microsoft says is not possible*.
[/quote]
(bolding mine)

You know, its remarkable that you think you can reject information thats
available on Microsofts servers - without even having taken a single peek at
it, as I don't think that anyone in their right mind would have dared to
refer to it as "a reference for email standards" - because they somehow are
a bad company, but at the same time trying to use a product they make,
outlook, as some kind of singular yardstick in regard to those same email
standards.

IOW,Something stinks there ...

Bottom line, besides taking the absolutily moronic stance that just one
product outof many, outlook, defines how a standard works - showing that you
still have zero clue how a standard and an implementation of it are not the
same thing - you've /again/ shown yourself there to be a "one rule for them,
another for me" hypocrite.

Regards,
Rudy Wieser

P.s.
I'm noticing you're slowing down. I guess it most be hard work for you to
have to deal with someone who doesn't just drops the whole matter and let
you get away with your never-ending hollow claims, hypocricy and other
shennigans.

Char Jackson <none@none.invalid> wrote:
> On Fri, 27 May 2022 09:29:26 -0700, The Real Bev <bashley101@gmail.com>
> wrote:
[...]

[About IMAP:]

> >What I object to is the inability to access OLD mail -- perhaps
> >preparing replies to send when the network goes back up. It always has
> >come back up again, right?
>
> I'm not familiar with an email client that doesn't automatically store a
> local copy of your email, regardless of the protocol you use to retrieve
> it from the server. If such a thing exists, others will have to chime
> in.

Automatically storing a local copy of received (and viewed?) email is
probably/hopefully the default for most clients. But some (many? most?
all?) clients can be configured to sync fewer messages (based on age
or/and storage size), especially in the inbox.

For example, IIRC, BlueMail has a non-unlimited default for its inbox.
Not sure if Thunderbird's 'Message Synchronising' is on/ticked by
default.

[...]

Op ma 23-05-2022 om 20:05 schreef Frank Slootweg:

> FWIW, I am in The Netherlands (EU/Europe) and have not gotten any
> notifications for our (four) Google/Gmail accounts, so I don't think
> either POP3 access to Gmail, nor (Google) App Passwords [1] use for
> Gmail (as opposed to OAuth2) are going away anytime soon. (I do use POP3
> with App Passwords in Thunderbird.)

I received notifications on my two Gmail accounts on vr 04-03-2022 03:36.

--
Alex.

Alex Plantema <alex@nl.invalid> wrote:
> Op ma 23-05-2022 om 20:05 schreef Frank Slootweg:
>
> > FWIW, I am in The Netherlands (EU/Europe) and have not gotten any
> > notifications for our (four) Google/Gmail accounts, so I don't think
> > either POP3 access to Gmail, nor (Google) App Passwords [1] use for
> > Gmail (as opposed to OAuth2) are going away anytime soon. (I do use POP3
> > with App Passwords in Thunderbird.)
>
> I received notifications on my two Gmail accounts on vr 04-03-2022 03:36.

What did the notifications say?

Note that (Google) App Passwords have *not* been removed. I still use
them - for three accounts - as we speak.

Did your notifications perhaps say that they (Google) would turn off
'Less secure app access'? Because *that* is indeed going away or has
gone away.

Andy Burns wrote:

>> Google explicitly says app passwords are disappearing.
>
> No, they say "insecure apps" are disappearing, "app passwords" are staying.
>
> Notice here, the red warning about less secure apps, yet they still link to app
> passwords
>
> <https://support.google.com/accounts/answer/6010255?hl=en>
>
> Or here, where they describe how to enable 2SV if you want to create an app
> password, with not a mention that they might be going away anytime soon
>
> <https://support.google.com/accounts/answer/185833?hl=en>
>
> I have no idea how many Google arses you have to lick to become a Diamond or
> Platinum Product Expert, but maybe you'll believe them if you don't believe me?
>
> <https://support.google.com/accounts/thread/161738917?hl=en>

I need help.

Andy & anyone else out there who understand this stuff because I am missing
somethign _fundamental_ about this 2FA/2SV/MSA/MSV stuff with respect to
Thunderbird on Windows and K9 (or any MUA) on Android.

I think this would be an issue that others would also have, if, and this is
important, if they too do not have a Google Account set up on their phone.

Given that, I need to ask a question since I'm a 2FA/2SV/MSA/MSV noob who
is also extremely allergic to anything that requires my phone number or
another email address.

Hence my limitations are specifically:
a. I want to give away as little privacy as I can
b. While setting up "something" that allows an MUA on Android
c. To access Android email using "something" (perhaps "app passwords")
d. While still accessing google email on Windows TB using OAuth2

I realize there are quite a few constraints there; but they are all in teh
name of privacy (mainly no Google Account & mainly no phone number if
possible).

That's why I _love_ login/password (which no longer works after May 30th),
and why I settled for OAuth2 (which won't work for Android, unfortunately);
so now I'm stuck with the third-best option, which, I think, from what you
say, is "app passwords" on Android (with, say, oh, K9 mail).

Bear in mind I _tried_ OAuth2 on Android. But I realized only after
physically testing Android FairMail that OAUth2, which works fine on
Windows Thunderbird, won't work on "most" unfunded Android MUAs because it
costs from $15K to $75K yearly for Google to accept OAUTH2 authentication
via the web - and most free unfunded MUAs just can't afford that yearly
expense.

The MUA developers' only OAuth2 workaround, as much as they hate it
themselves, is to _create_ a Google Account on the Android phone and then
let Google run the OAuth2 step for them using that account on the phone.

That works fine for the vast majority of Android owners who have a Google
Account already on their phone, but as you're well aware, that won't work
for me because I don't ever want a Google account on my phone.

Hence I'm _stuck_ with whatever is the "next best thing", which, from what
you've told me, is "app passwords" which, from what you've told me,
requires 2FA/2SV/MSA/MSV - which is why I've installed these two apps:

*andOTP* Android OTP Authenticator by Jakob Nixdorf
no cost, no ads, no gsf, rated 4.3, 100K+ installs
<https://play.google.com/store/apps/details?id=org.shadowice.flocke.andotp>
*FreeOTP Authenticator* by Red Hat
no cost, no ads, no gsf, rated 3.7, 1M+ installs
<https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp>

The problem I have with those apps is you have to have _already_ set up
your email account as 2FA/2SV/MSA/MSV in order to get them to do anything:
<https://i.postimg.cc/VN5y8vt9/otp01.jpg> Flocke free andOTP settings
<https://i.postimg.cc/rFC2Gvc4/otp02.jpg> Red Hat freeOTP settings

The problem I have with setting up 2FA/2SV/MSA/MSV is that I've never set
it up and yet I'm trying to understand how it works _before_ I set it up.

One "issue" I have (mostly it's a fear) is that I won't be able to access
email via Thunderbird/OAUth2 once I set up 2FA/2SV/MSA/MSV since you set it
up by account, and not by MUA, right?

So, if I do set up 2FA/2SV/MSA/MSV for my Google mail account, how does
that Google mail account know to use OAuth2 for Windows Thunderbird but,
oh, say, app passwords for K9 mail?
--
BTW, I thank you for suggesting I use Google Voice on the iPad as my
verification number since on the iPad, Google does _not_ create an account
(whereas if you log into Google Voice on Android, Google _does_ create an
account on Android).

Op ma 27-06-2022 om 20:36 schreef Frank Slootweg:

> What did the notifications say?

Vanaf 30 mei raak je mogelijk de toegang
kwijt tot apps die gebruikmaken van een
minder beveiligde inlogtechnologie.

Google biedt geen support meer voor het gebruik van apps van derden
of apparaten die je vragen om in te loggen op je Google-account met
alleen je gebruikersnaam en wachtwoord. We doen dit om je account te
beschermen. In plaats daarvan moet je inloggen via Inloggen met
Google: https://support.google.com/accounts/answer/112802 of andere technologieën met een betere beveiliging, zoals
OAuth 2.0. Meer informatie: https://support.google.com/accounts/answer/6010255

Wat moet je doen?

E-mailsoftware, zoals Outlook 2016 of lager, biedt minder goed
beveiligde toegang tot je Gmail. Schakel over naar Office 365,
Outlook 2019 of hoger of andere e-mailsoftware waarmee je kunt
inloggen via Inloggen met Google.
Meer informatie: https://support.google.com/accounts/answer/6010255

--
Alex.

Op ma 27-06-2022 om 20:36 schreef Frank Slootweg:

> What did the notifications say?

Vanaf 30 mei raak je mogelijk de toegang
kwijt tot apps die gebruikmaken van een
minder beveiligde inlogtechnologie.

Google biedt geen support meer voor het gebruik van apps van derden
of apparaten die je vragen om in te loggen op je Google-account met
alleen je gebruikersnaam en wachtwoord. We doen dit om je account te
beschermen. In plaats daarvan moet je inloggen via Inloggen met
Google: https://support.google.com/accounts/answer/112802 of andere technologieën met een betere beveiliging, zoals
OAuth 2.0. Meer informatie: https://support.google.com/accounts/answer/6010255

Wat moet je doen?

E-mailsoftware, zoals Outlook 2016 of lager, biedt minder goed
beveiligde toegang tot je Gmail. Schakel over naar Office 365,
Outlook 2019 of hoger of andere e-mailsoftware waarmee je kunt
inloggen via Inloggen met Google.
Meer informatie: https://support.google.com/accounts/answer/6010255

--
Alex.

On Mon, 27 Jun 2022 20:30:39 +0100, Andy Burnelli <spam@nospam.com>
wrote:

>Andy Burns wrote:
>
>>> Google explicitly says app passwords are disappearing.
>>
>> No, they say "insecure apps" are disappearing, "app passwords" are staying.
>>
>> Notice here, the red warning about less secure apps, yet they still link to app
>> passwords
>>
>> <https://support.google.com/accounts/answer/6010255?hl=en>
>>
>> Or here, where they describe how to enable 2SV if you want to create an app
>> password, with not a mention that they might be going away anytime soon
>>
>> <https://support.google.com/accounts/answer/185833?hl=en>
>>
>> I have no idea how many Google arses you have to lick to become a Diamond or
>> Platinum Product Expert, but maybe you'll believe them if you don't believe me?
>>
>> <https://support.google.com/accounts/thread/161738917?hl=en>
>
>I need help.

ROFL... Arlen admits it.

Andy Burnelli wrote:

> Andy & anyone else out there who understand this stuff because I am missing
> somethign _fundamental_ about this 2FA/2SV/MSA/MSV stuff with respect to
> Thunderbird on Windows and K9 (or any MUA) on Android.

Are you running an old Thunderbird? If not then oAuth should "just work".

Regarding K9, currently oAuth isn't an option, which leaves app passwords, which
depend on 2SV, so it turns on whether using 2SV itself is acceptable to you, and
whether the one-off methods to enable 2SV are also acceptable.

It seems they don't recommend using a google voice account as the phone number
to receive the text or spoken one-time code to enable 2SV, probably because it
could end-up with the method to "recover" a locked-out account depending on that
same locked-out account?

If you have the google account on any android device, it can send a notification
within the app (not an SMS or voice call) but I think you exclude that method by
not having mothership accounts?

The final alternative is google's "Advanced Protection" programme which uses
physical security dongles (such as google titan, or yubikey) but also requires
you to have a recovery email and recovery phone number registered for the
account, so you don't get locked out permanently.

<https://landing.google.com/advancedprotection/>

I have a spare yubikey, so could give it a whirl ...

Alex Plantema <alex@nl.invalid> wrote:
> Op ma 27-06-2022 om 20:36 schreef Frank Slootweg:
>
> > What did the notifications say?
>
> Vanaf 30 mei raak je mogelijk de toegang
> kwijt tot apps die gebruikmaken van een
> minder beveiligde inlogtechnologie.
>
> Google biedt geen support meer voor het gebruik van apps van derden
> of apparaten die je vragen om in te loggen op je Google-account met
> alleen je gebruikersnaam en wachtwoord. We doen dit om je account te
> beschermen. In plaats daarvan moet je inloggen via Inloggen met
> Google: https://support.google.com/accounts/answer/112802 of andere technologieën met een betere beveiliging, zoals
> OAuth 2.0. Meer informatie: https://support.google.com/accounts/answer/6010255
>
> Wat moet je doen?
>
> E-mailsoftware, zoals Outlook 2016 of lager, biedt minder goed
> beveiligde toegang tot je Gmail. Schakel over naar Office 365,
> Outlook 2019 of hoger of andere e-mailsoftware waarmee je kunt
> inloggen via Inloggen met Google.
> Meer informatie: https://support.google.com/accounts/answer/6010255

As I suspected - see the (snipped [1]) part in my previous response -
they're talking about 'Less secure app access' going away.

You probably had enabled 'Less secure app access', which would explain
why you got notifications and I did not.

So the current remaining options are OAuth2 or (Google) App Passwords.

[1] Please don't snip relevant parts when responding, especially if it's
so little text as in this case. Yes, one/people can go back and look,
but most people don't and it makes it hard to follow the discussion.

Andy Burns <usenet@andyburns.uk> wrote:
> Andy Burnelli wrote:
>
> > Andy & anyone else out there who understand this stuff because I am missing
> > somethign _fundamental_ about this 2FA/2SV/MSA/MSV stuff with respect to
> > Thunderbird on Windows and K9 (or any MUA) on Android.
>
> Are you running an old Thunderbird? If not then oAuth should "just
> work".
>
> Regarding K9, currently oAuth isn't an option, which leaves app
> passwords, which depend on 2SV, so it turns on whether using 2SV
> itself is acceptable to you, and whether the one-off methods to enable
> 2SV are also acceptable.
>
> It seems they don't recommend using a google voice account as the
> phone number to receive the text or spoken one-time code to enable
> 2SV, probably because it could end-up with the method to "recover" a
> locked-out account depending on that same locked-out account?
>
> If you have the google account on any android device, it can send a
> notification within the app (not an SMS or voice call) but I think you
> exclude that method by not having mothership accounts?
>
> The final alternative is google's "Advanced Protection" programme
> which uses physical security dongles (such as google titan, or
> yubikey) but also requires you to have a recovery email and recovery
> phone number registered for the account, so you don't get locked out
> permanently.
>
> <https://landing.google.com/advancedprotection/>
>
> I have a spare yubikey, so could give it a whirl ...

Why not use 'Backup codes' for Google's 2-Step Verification (as I
suggested several times before)?

It ticks all of Andy Burnelli's boxes.

Of course 'Andy Burnelli' only want problems, not solutions, so he
(silently) ignored my 'Backup codes' solution and went on another wild
goose chase (TOTP apps), but that doesn't mean *all* Andy's must have
their blinkers on! :-)

Frank Slootweg wrote:

> Why not use 'Backup codes' for Google's 2-Step Verification (as I
> suggested several times before)?

I think you can only use printed codes for 2SV itself, but you can't use them as
a method to *enable* 2SV ?

Andy Burns <usenet@andyburns.uk> wrote:
> Frank Slootweg wrote:
>
> > Why not use 'Backup codes' for Google's 2-Step Verification (as I
> > suggested several times before)?
>
> I think you can only use printed codes for 2SV itself, but you can't
> use them as a method to *enable* 2SV ?

I don't quite follow. So let me explain in another way.

'Andy Burnelli' ('he') wants to use Gmail with email apps without
being forced to use OAuth2 and without having a Google Account *on the
device* on which he uses the email app(s).

We have established that the only way to do this is use (Google) App
Passwords and that App Passwords require (Google) 2-Step Verification to
be turned on and probably a one-time 2SV login to create the App
Passwords. But he does not want to give out a phonenumber for 2SV.

Using Gmail means he has a Google Account. He can access that Google
Account from any browser on any device, doesn't have to be the device(s)
on which he uses the email app(s).

So he logs into his Google Account from some browser on some device,
enables 2-Step Verification, creates the (2SV) 'Backup codes', creates
the App Password(s) and Bob's his uncle.

If he wants/needs to perform account-related actions at some later
points, he can either use the 'Backup codes' or - preferred - use the
same browser/device for those actions and check the "Don't ask again on
this computer" box.

End result:

- No need for OAuth2.
- No Google Account on devices with e-mail apps.
- No need to give a phonenumber for 2SV.
- No need for TOTP apps.

Agreed?

Frank Slootweg wrote:

> I don't quite follow. So let me explain in another way.
>
> 'Andy Burnelli' ('he') wants to use Gmail with email apps without
> being forced to use OAuth2 and without having a Google Account *on the
> device* on which he uses the email app(s).
>
> We have established that the only way to do this is use (Google) App
> Passwords and that App Passwords require (Google) 2-Step Verification to
> be turned on and probably a one-time 2SV login to create the App
> Passwords. But he does not want to give out a phonenumber for 2SV.
>
> Using Gmail means he has a Google Account. He can access that Google
> Account from any browser on any device, doesn't have to be the device(s)
> on which he uses the email app(s).
>
> So he logs into his Google Account from some browser on some device,
> enables 2-Step Verification, creates the (2SV) 'Backup codes', creates
> the App Password(s) and Bob's his uncle.
>
> If he wants/needs to perform account-related actions at some later
> points, he can either use the 'Backup codes' or - preferred - use the
> same browser/device for those actions and check the "Don't ask again on
> this computer" box.
>
> End result:
>
> - No need for OAuth2.
> - No Google Account on devices with e-mail apps.
> - No need to give a phonenumber for 2SV.
> - No need for TOTP apps.
>
> Agreed?

Close, but I don't think fully agreed ...

If the user doesn't have a mothership-linked android device, then the step of
*enabling* 2SV requires either a voice call, or an sms message, or a physical
dongle and the account to have a recovery phone number ... so all of those
options require giving google a phone number, which AIUI, Arlen is averse to doing?

Once 2SV is enabled, you can get/print/save the backup codes, which can be used
either to login to gmail web interface on a 3rd party computer, or if you wipe
out the 2SV cookies from your browser.

Op di 28-06-2022 om 17:25 schreef Frank Slootweg:

> As I suspected - see the (snipped [1]) part in my previous response -
> they're talking about 'Less secure app access' going away.
>
> You probably had enabled 'Less secure app access', which would explain
> why you got notifications and I did not.
>
> So the current remaining options are OAuth2 or (Google) App Passwords.

I also use an old client not suited for Oauth. I got it working using an app password.

--
Alex.

Andy Burns <usenet@andyburns.uk> wrote:
> Frank Slootweg wrote:
>
> > I don't quite follow. So let me explain in another way.
> >
> > 'Andy Burnelli' ('he') wants to use Gmail with email apps without
> > being forced to use OAuth2 and without having a Google Account *on the
> > device* on which he uses the email app(s).
> >
> > We have established that the only way to do this is use (Google) App
> > Passwords and that App Passwords require (Google) 2-Step Verification to
> > be turned on and probably a one-time 2SV login to create the App
> > Passwords. But he does not want to give out a phonenumber for 2SV.
> >
> > Using Gmail means he has a Google Account. He can access that Google
> > Account from any browser on any device, doesn't have to be the device(s)
> > on which he uses the email app(s).
> >
> > So he logs into his Google Account from some browser on some device,
> > enables 2-Step Verification, creates the (2SV) 'Backup codes', creates
> > the App Password(s) and Bob's his uncle.
> >
> > If he wants/needs to perform account-related actions at some later
> > points, he can either use the 'Backup codes' or - preferred - use the
> > same browser/device for those actions and check the "Don't ask again on
> > this computer" box.
> >
> > End result:
> >
> > - No need for OAuth2.
> > - No Google Account on devices with e-mail apps.
> > - No need to give a phonenumber for 2SV.
> > - No need for TOTP apps.
> >
> > Agreed?
>
> Close, but I don't think fully agreed ...
>
> If the user doesn't have a mothership-linked android device, then the
> step of *enabling* 2SV requires either a voice call, or an sms
> message, or a physical dongle and the account to have a recovery phone
> number ... so all of those options require giving google a phone
> number, which AIUI, Arlen is averse to doing?

You are - of course :-) - correct. I forgot about that step.

He probably could use a call to a 'landline', but maybe Google will
keep that number after use.

There's another option:

"Google Prompt
Get a Google Prompt on your phone and just tap Yes to sign in"

but that probably requires at least a *temporary* Google Account on the
phone, which is probably off-limits as well.

Oh well!

BTW, when checking this on one of my Google Accounts, I saw that that
account still has

"2-Step Verification (-) Off
App passwords 1 password"

So that App password was apparently created *before* 2-Step
Verification had to be On. (Same thing for another similar account.)

(For my main Google Account I had to enable 2-Step Verification, because
due to a suspected security breach, Google had removed the App Password
from that account. :-()

> Once 2SV is enabled, you can get/print/save the backup codes, which
> can be used either to login to gmail web interface on a 3rd party
> computer, or if you wipe out the 2SV cookies from your browser.

Frank Slootweg wrote:

> BTW, when checking this on one of my Google Accounts, I saw that that
> account still has
>
> "2-Step Verification (-) Off
> App passwords 1 password"
>
> So that App password was apparently created*before* 2-Step
> Verification had to be On. (Same thing for another similar account.)
>
> (For my main Google Account I had to enable 2-Step Verification, because
> due to a suspected security breach, Google had removed the App Password
> from that account. :-()

I think some time back, it was possible to create app-passwords without 2SV, or
at least to disable 2SV after creating an app password, but now you can't create
them without it and if you disable it, they get deleted.

I never did, because at that time I used "allow less secure" setting.

Andy Burns <usenet@andyburns.uk> wrote:
> Frank Slootweg wrote:
>
> > BTW, when checking this on one of my Google Accounts, I saw that that
> > account still has
> >
> > "2-Step Verification (-) Off
> > App passwords 1 password"
> >
> > So that App password was apparently created*before* 2-Step
> > Verification had to be On. (Same thing for another similar account.)
> >
> > (For my main Google Account I had to enable 2-Step Verification, because
> > due to a suspected security breach, Google had removed the App Password
> > from that account. :-()
>
> I think some time back, it was possible to create app-passwords
> without 2SV, or at least to disable 2SV after creating an app
> password, but now you can't create them without it and if you disable
> it, they get deleted.

Yeah, I created my App Passwords when it still was: Turn on 2SV,
create App Password(s), turn off 2SV.

> I never did, because at that time I used "allow less secure" setting.

I switched (in September 2018) from 'Less secure app access' to App
Passwords when Google was constantly blocking my (POP) access to my
Gmail accounts whenever my laptop was used on other IPs than my home IP,
i.e. for example when using Wi-Fi access points in caravan parks in
Australia. After every IP-switch, you had to use a web-browser to login
to the Google Account(s), to undo the blocking. Major annoyance. No such
problem with App Passwords.
>
>

Andy Burns <usenet@andyburns.uk> wrote:
> Frank Slootweg wrote:
>
>> I don't quite follow. So let me explain in another way.
>>
>> 'Andy Burnelli' ('he') wants to use Gmail with email apps without
>> being forced to use OAuth2 and without having a Google Account *on the
>> device* on which he uses the email app(s).
>>
>> We have established that the only way to do this is use (Google) App
>> Passwords and that App Passwords require (Google) 2-Step Verification to
>> be turned on and probably a one-time 2SV login to create the App
>> Passwords. But he does not want to give out a phonenumber for 2SV.
>>
>> Using Gmail means he has a Google Account. He can access that Google
>> Account from any browser on any device, doesn't have to be the device(s)
>> on which he uses the email app(s).
>>
>> So he logs into his Google Account from some browser on some device,
>> enables 2-Step Verification, creates the (2SV) 'Backup codes', creates
>> the App Password(s) and Bob's his uncle.
>>
>> If he wants/needs to perform account-related actions at some later
>> points, he can either use the 'Backup codes' or - preferred - use the
>> same browser/device for those actions and check the "Don't ask again on
>> this computer" box.
>>
>> End result:
>>
>> - No need for OAuth2.
>> - No Google Account on devices with e-mail apps.
>> - No need to give a phonenumber for 2SV.
>> - No need for TOTP apps.
>>
>> Agreed?
>
> Close, but I don't think fully agreed ...
>
> If the user doesn't have a mothership-linked android device, then the step of
> *enabling* 2SV requires either a voice call, or an sms message, or a physical
> dongle and the account to have a recovery phone number ... so all of those
> options require giving google a phone number, which AIUI, Arlen is averse to doing?
>
> Once 2SV is enabled, you can get/print/save the backup codes, which can be used
> either to login to gmail web interface on a 3rd party computer, or if you wipe
> out the 2SV cookies from your browser.

One has to wonder why he even has a gmail account if he hates the
"mothership" so much. No gmail; no OATH2 or mothership issues.

Chris wrote:

> One has to wonder why he even has a gmail account if he hates the
> "mothership" so much. No gmail; no OATH2 or mothership issues.

Tend to agree, hotmail.com aka outlook.com gives 15GB mailbox (similar size to
gmail) supports imap/pop/smtp, doesn't insist on oAuth

Andy Burns wrote:

> outlook.com gives 15GB mailbox (similar size to
> gmail) supports imap/pop/smtp, doesn't insist on oAuth

Actually from October microsoft is also going down the oAuth2 route for IMAP/POP
(they seem to be stopping shy of insisting on it for SMTP due to multi-function
devices not supporting it)

Unfortunately microsoft seem to have had a fuck up today, where they have
disabled deprecated authentication methods four months early!!