Outlook / Hotmail Account Issues

[Protocol]

It appears that Microsoft has made some changes. I'm getting OAuth2 errors.

It started with one Outlook / Hotmail, then progressed to more.
I've tried reauthorizing, and even opening a browser to see if there is a captcha blocking it, but no success.

[mjs]

Use the "password" method instead of "Oauth2" -- see the details here: https://www.esumsoft.com/news/outlook-s ... th2-error/.

You're not the only one - in the past few minutes (3-4 Microsoft account Oauth2 errors started cropping up in my case), in regards to one specific account, I had tried re-authorizing the same Microsoft Email account 3 times and each time the Oauth2 error returned.

So went with the "password" option (for this one problematic account) instead of using Oauth2 - problem solved (in my case the problem was not an SMTP issue as described in the link - but rather I was getting repeated Oauth2 errors after doing a reportedly "successful" re-authorization of the account each time - which sounds like your issue as well. Btw, this "password" method option is possible with Microsoft accounts because they do not currently require Oauth2. I might add in regards to a few other Microsoft accounts with recent Oauth2 errors, reauthorizing worked out OK [so the "password" option was not necessary] - it was just this one specific account that had persistent errors that required the use of the "password" method).

[maupassant2]

Same problem here, with my MSN and Hotmail accounts. The Oauth2 error returns even if it says it has been successful.

In addition, all my Hotmail messages are gone. When Pop Peeper tries to retrieve them, it shuts down after a few seconds.

[mjs]

Welcome to the forum maupassant2,

1. Please explain in more detail what is meant by "it shuts down".

2. What version of PP are you running?

3. What Operating System are you using?

4. To be clear, after getting an "Oauth2" error and then resetting "Oauth2 on your MSN account that are using "IMAP" protocol ("Server type" setting) you will then persistently get the same Oauth2 again for that account?

5. Does this involve all of your Microsoft account(s) and how many would that be?

6. Did this problem just start this morning?

7. Please post any more details involving this issue that you may think is relevant.

8. Please post the Error Overview you are getting (to give us more detailed information) --- you should see a yellow '!' button on the bottom-right of the main window (when errors occur) -- press that yellow button and then press the 'Copy' button and paste the information here in this topic in your reply and please be sure to remove personal (private) information in the Error, such as the account name.

[Jeff]

I have two (active) Outlook.com account and they have not shown any errors (using Oauth2). I've tried disconnecting several times, but it's always connected successfully.

Microsoft's status page does indicate an issue with outlook.com, but it doesn't have anything to do with this issue.

As mjs mentioned, switching to the password method is probably the best solution.

Please reply back if the issue seems to be lessening or is fixed (if you're still using Oauth2).

[Jeff]

I've gotten some reports back that the problem seems to be resolved now.

[mjs]

Over the last 8 hours - out of a total of my 19 Microsoft accounts there have been around 7 that have produced "Oauth2" errors (leaving around 12 accounts w/out any issues) - 2 of the 7 accounts with "Oauth2" errors continued to produce errors and therefore required my switching to the "Password" method for these two specific problematic accounts (a run-down provided below).

Breakdown:
19 total MSN accounts.
7 of those 19 have recently produced "Oauth2" errors in the past 8 hours.
2 of those 7 produced persistent "Oauth2" errors (at least 3 persistent "Oauth2" errors) resulting in my using the "Password" method (instead of "Oauth2").
12 MSN accounts have so far continued to perform successfully w/out any errors.
No errors for any accounts over the past 80 minutes (a perspective worth noting; in my case - during the entire 8 hour time-frame, while a relatively small number of MSN accounts had an "Oauth2" issue of some kind, ~63% of MSN accounts had no issues of any kind at all).

[largo]

Hello,

Beware Microsoft has updated its security
for Oauth2 you have to log in manually and it will then work with your credentials to confirm your identity. I just did it and all my accounts are OK with Oauth2 and PopPeeper.

@+

[mjs]

For the record, it appears the persistent "Oauth2" error issue (I was getting for two of my MSN accounts) has been resolved. That is, I have tried switching back to using "Oauth2" for my two previously referenced problematic MSN accounts (using the same "Oauth2" drop-down method as usual via POP Peeper to do this) and found have that both accounts are not having any more issues using the "Oauth2" method.

So, in as much as it would appear the flurry of "Oauth2" issues that occurred earlier today has now been resolved -- any accounts that previously needed to use the "Password" method should once again presumably work using the "Oauth2" method.

[Protocol]

I've gotten some reports back that the problem seems to be resolved now.

The problem seems to have resolved itself.
I didn't make any changes, and stuck with Oauth2, and my accounts are all working now.

[dallas77us]

Aside to Jeff: Your reply to my email said "updates will be posted to this thread," so I thought I'd just go straight to the forum. And, yup, still using POP Peeper for my eight email accounts.

I have an Outlook account which started out as a MyUserName@oem.microsoft.com when I got MS certified in 2000. Which went to @Hotmail.com, then @Outlook.com. As of this posting, there's never been problem with that at all using server imap.outlook.com and whenever OAuth2 needed updating. I've always used a browser and login is done at login.live.com.

(OAuth2 works with four gmail accounts and one yahoo.)

However, my OAuth2 issue is with my GoDaddy domain and MS365. My email address is like MyUserName@myDomainName.com. I use a browser for "Outlook on the web" (formerly Outlook Web Access, OWA) exclusively and login at sso.godaddy.com which opens my www.microsoft365.com home page where I can open my email page at outlook.office.com.

However, the couple of times I just for "what happens if," when I used the Windows Mail app or login at login.live.com in the browser, there is a redirect to sso.godaddy.com and that opens to my outlook.office.com account in the app or the email page in the browser.

I've had that domain since November 2021 and up until the other day, never any problems with OAuth2. And whether or not I use "password" OR "Oauth2" for this POP Peeper account, it opens this same modal window having no fields to edit:

Apparently, it's GoDaddy that's done away with this and it could be I can't use POP Peeper for this account any more. Not the end of the world and I don't expect Jeff to scrape through this one.

Anyone using a personal GoDaddy domain (or other domain service) having resolved or worked around that, please post up.

Cheers.

[mjs]

Try clicking on the "Alternate (web browser)" button in the bottom-left area of the above interface (as seen in your posted screen-shot) to see if you are able to complete the Oauth2 process (the remaining dialogs should open in your default browser).

[mjs]

Followup FYI - I will actually get an empty (Microsoft) dialog as well (see screen-shot below) from time to time exclusively on MSN accounts (Hotmail/Outlook.com etc.) however, others don't seem to get this same result (that I do) for some reason.

That said, I am always able to complete the Oauth2 process via the button (I've referenced in previous post) at the bottom-left area of the dialog.

As a work-around, I am always able to complete the "Oauth2" process when I get this empty dialog by using the "Alternate (web browser)" button.

[Jeff]

dallas77us -- I've replied via email.

[dallas77us]

Try clicking on the "Alternate (web browser)" button

Thanks mjs. Jeff, more detail in the email. Hey, that rhymes.

I failed to mention above I tried that and it failed, though I can't remember well enough the sequence of errors I encountered to post up precisely about that experience.

However, Edge is my default browser but I use Firefox exclusively with Edge blocked in the firewall. This is old-school but still valid strategy so that while browsing willy nilly in Firefox (or doing anything, for that matter), should Edge suddenly pop open, one would know something nefarious is going on.

While I did allow Edge in the firewall for the Alternate (web browser) attempt, I also have enabled several group policies targeting security/privacy which border on the paranoid. I loosened up the policies and got me a OAuth2! Some of those policies are enterprise centric and offer no error dialogues to the client. My Bad. But in my defense, this is the first time ever that the policies got ugly considering the all the very occasional in-app About or Help features which open the default browser wherein I allow temporary Edge in the firewall. Like POP Peeper's Help > "Make a donation."

Given that there was never an issue with that default OAuth2 method since I set up that GoDaddy/MS365 account in POP Peeper in September 2021, something has become amiss as evidenced in my and mjs's blank modal windows.

What an adventure...

[Jeff]

Dallas -- one thing that isn't clear from your message is which method ultimately succeeded? ie. did you use the default Oauth2 method (which uses an internal/embedded browser), or did you use the "alternate (web browser)" method?

If the latter, then based along with mjs' strategy, I may have to consider making that the default. I have mixed feelings about which is better because the "web browser" method can cause confusion since it requires the user to allow the webbrowser to link back to POP Peeper. On the other hand, the internal browser method forces the user to enter the password, which can be an annoyance (whereas the webbrowser method may have it saved, if the user so chooses). The 'web browser' method would also be more consistent with how POP Peeper works with other oauth2 services, so...



Yeah, kinda leaning toward making 'web browser' the default for Outlook-type accounts.

[dallas77us]

Hi Jeff.

I'm sorry I failed to notice your inquiry as to which method I used. It was the alternate web browser method as I was getting that blank GoDaddy screen I posted up on Sun Jun 25, 2023 1:49 pm.

Today I had to repeat the process for my live dot com account which I got ages ago for the Windows Insider program. Using the embedded threw a wrong password back at me. Though there's no "show" for the password, I'm certain for the three attempts I did type in the nine characters correctly.

I did get to reauthorize OAuth2 using the alternate web method.

On another note, I don't recall that "Email code to" ever being involved. Did that just show up recently? That said, pushing 73, my recollections sometimes don't actually recall well.

If I login directly to live dot com from a browser, I see the same but the site opens without any code intervention or anything sent to that alternate email.

Hope you're doing well; keep up the great work.

Cheers.

[mjs]

EDIT: Disregard the comments below as this is not what you were asking about. And yes, it is a relatively new thing for MS to be sending codes to the respective alternate email account on record to confirm the account is really yours. I've unfortunately experienced this inconvenience far too often over the past few months.

... On another note, I don't recall that "Email code to" ever being involved. Did that just show up recently? That said, pushing 73, my recollections sometimes don't actually recall well.

Web Browser (code) method to set Oauth2

If you're referring to the method pointed out (above), actually no, that is not a new option as it's been an available method to set Oauth2 for a number of years if I'm not mistaken (going back to PPv4 sometime as I recall, i.e. at least as far back as 2017 and perhaps before - of course it's all a blur at this point ).

[Jeff]

I can't say that I've noticed the "email code" thing either, but it's one of those things you probably don't notice until something else isn't working correctly

But, as of the next version (v5.4.7/v5.5), POP Peeper will default to using the "web browser" method for Outlook accounts instead of the embedded browser, which should work better overall.

[mjs]

Vent time -- on the subject of MS codes.
Here's the scenario:
1) I have an MS account (I'll call acct-1) that requires Oauth2 to be reset to work in PP.
2) Starting the process I need a code to be sent to an alternate account (acct-2) to enter into the account (acct-1) that needs Oauth2 reset.
3) Logging into the alternate account (acct-2) needs a code to successfully login to get the code for the that acct-1 needs.
4) PP cannot be used to get any codes at all because it is tied up in the process of setting Oauth2 (thus there's no way to get the messages with codes via PP).
5) If I login on the web each acct (acct-1 and acct-2) will both be requiring codes to confirm the accounts belong to me.
6) So I end up with PP waiting on a code to reset Oauth2.
7) And I have multiple browsers waiting on codes for the two MS accounts (acct-1 that needs to set Outh2 in PP and acct-2 that needs to get the code to enter into acct-1).

Wouldn't you think that MS should know that they've set up a security (confirmation) system that has the very real possibility of reaching a potential Catch-22 scenario where nothing can be accomplished because all the accounts involved in confirming who I am would be waiting on codes from each other to allow access to either of the two accounts. (that last thing any software company would want in their code is to have the potential to end up with a conundrum of this kind).

At this point, the only way out of this is to have another Email Client (more browsers won't help and PP is tied up in the Oauth2 process) and hope that alternate Email Client will provide access to the MS accounts with the needed codes w/out the Email Clients accounts requiring their own codes for the two accounts. And if this is not possible then what to do??????

This is frankly laughable where I found myself - I just gave up finally (I can presumably get the codes off of another computer assuming it won't need codes for the accounts - otherwise I'm basically done)....

This all occurs because of using a Desktop (Win7) machine in this case that I use rarely thus triggering all of these "code" requirements. What MS is requiring for the most part is for users to have access to more than one computer (one of which will not be requiring codes) whenever these kinds of situations occur.

I'd say, not a very good plan if you ask me!!.... (I've found Gmail has been good at this kind of overbearing stuff in the past, losing a number of accounts as a result; I guess MS has decided to do them one better!!)

Screen-shots below (as a visual aid) - this scenario of sending a code to an alternate account (acct-2) to be entered into the account (acct-1) that has to confirm the account is mine is duplicated in the opposite direction using the same accounts in my case (because each of the accounts are using the other account as an alternate) further explanation below (I'm not going to post more screen-shots for this - but just think of the same scenario (for example screen-shots) all over again (in the opposite direction) for the alternate account acct-2, that is needing a code from it's alternate account, in this case acct-1, thus reversed). There is no way to resolve this scenario using one computer (every time I open another browser to login on the web I get the same situation) and I'm not sure it's any better on the web with another computer - however access to another computer at the same time that has an Email Client installed is hopefully a way to presumably resolve the situation ( to get the necessary codes for the computer that has the catch-22 situation, hmm - I'd say, clearly not a well thought out process to require a second computer in this specific case, imho).

The glaring question is: What are you going to potentially have (in some cases) based on the approach MS uses to confirm users accounts?

One of two possibilities (in my case essentially Scenario "B"):
Scenario A) a never ending string of more accounts and more accounts (alternate after alternate) needing codes for the next account that needs to be confirmed hence ultimately "dead-in-the-water" as a result of this "catch-22" scenario.
or
Scenario B) if the two accounts use the other accounts alternate (i.e. acct-1 uses acct-2 as an alternate and acct-2 uses acct-1 as an alternate) you have a "deadlock" situation where you're once again faced with a "catch-22" scenario because each account is needing a code from it's alternative account that amount to the same accounts in the opposite direction (which was the the most part my situation).

Code required for Acct-1 confirmation

Code sent to alternative account (acct-2) to be entered into acct-1 to confirm

Ironically the browser "tab" to get the required codes are entitled "Help us protect your account". A better label for the browser tab would be "Help make it impossible to use your account".