It's been like this as long as I can remember... but there is a way to get around it.
Create a new email with any email address you want.
Since they are the same account though you could then copy the email address in the db from the working one into the other one at the database level.
Error: Email already exists (but it doesn't)
KevinTheJedi
Hi Kevin,
The first version I ever used was 1.15.x, which we've since updated to 1.16.3. No problem on either version. For the deployment in question on this ticket, I started it on 1.16.1, and used it for a year with no problem. Always using different e-mails with the same account authentication. I definitely didn't need to modify it at the database level to accomplish this, as I'm really not a database person, I just created the accounts in the WUI. If you want to check into it further, I can give you screenshots or whatever information you wish, if there's a way I can share that with you privately.
I'll try to duplicate the current account at the database level, per ntozier's suggestion, to see if that can at least get the account created. But how can I get around the "too many failed login attempts" error that still seems to persist?
Thank you!
You probably have modern authentication enabled in which you can either setup 2FA + App Paasword or re-instate basic authentication. There are other threads with these instructions.
If all else fails you’ll have to contact your mail admin/mail provider for further assistance.
Cheers.
Hi Kevin,
Good suggestion, but 2FA has always been turned off for this account. And, I mentioned in my original post, Microsoft 365 actually shows all the authentication attempts coming from osTicket as successful, even though osTicket thinks it failed. The "too many failed login attempts" seems to have been totally on the local osTicket system's end. Nothing with the Microsoft 365 was changed, or has been changed since. It was spontaneous on osTicket's part.
Things are working fine now. I was able to add the account without needing to do anything in the database. I just removed both e-mail accounts, and re-added them, and it worked. Both using the same account for authentication, no problem.
So, it's still a mystery as to where the failed login attempts came from, and where the record of those failures was being cached in osTicket to prevent me from modifying the account and troubleshoot it. But removing all e-mail accounts and re-adding them fixed it.
Curious if you have any thoughts as to what may have happened. But I guess if it doesn't happen again, we should be good here. You said it's not supposed to allow two e-mail addresses to have the same authentication. Clearly, it does for me, could this be contributing to some problem?
- Edited
That error does not exist in osTicket. You can search the code and you will not find it. So it definitely came from MS end.
Not sure why it's letting you do that as the code I referenced earlier clearly says no-no. 
I see now, it's only passing the email value so you are correct as long as the email is different you should be fine.
Cheers.
Hi Kevin,
Thanks for the updates! Are you sure the error does not exist in osTicket? This is the exact e-mail alert we receive, which is also recorded in osTicket's system log:
-----Original Message-----
From: [redacted] Tickets <tickets@[redacted]>
Sent: Thursday, July 28, 2022 1:23 PM
To: [redacted]
Subject: Mail Fetch Failure AlertosTicket is having trouble fetching emails from the following mail account:
User: tickets@[redacted]
Host: outlook.office365.com
Error: Too many login failures105 consecutive errors. Maximum of 5 allowed
This could be connection issues related to the mail server. Next delayed login attempt in aprox. 10 minutes
I can tell you that the "maximum of 5 allowed" is not imposed by Microsoft 365, as well as the delay of 10 minutes. And, even if Microsoft 365 does keep a count of consecutive errors, it's not something osTicket would be able to access to read. So these "105 consecutive errors" must be counted and recorded somewhere within osTicket, and that must have been saved somewhere that didn't get cleared out until I deleted all e-mail addresses that involved the tickets@ account.
When I was trying to re-add the email address, osTicket was flagging the account as having "too many consecutive errors" before it even allowed me to save it. And I think it wasn't even trying to authenticate at that time, it was just preventing the attempt to authenticate, which prevented me from creating the account. Removing all e-mail addresses that used the account allowed me to finally create it, using the exact same authentication information as previous attempts. So, it really does seem that the error was within osTicket, not Microsoft 365. Again, I made no changes to Microsoft 365 at any point during this whole process, neither before the failures were introduced, nor as part of solving the problem.
To clarify the maximum errors/attempts restrictions is on osTicket's side but not the Too many login failures error.
Cheers.
Okay... Did you see the screenshot in my original post that shows the WUI giving the "too many login failures" error? Are you saying the WUI is pulling in and displaying error information from an external source?
I wouldn't know how to search the code. Just trying to understand what the problem was and get to the bottom of it.
Yes the error will be pulled from the connection. So whatever error MS returns we display it so you know what their response was.
At this point it seems like you need to contact your mail admin and/or mail provider for further assistance.
Cheers.
Okay, if it's pulling that from the connection, that makes sense. What doesn't make sense is why the account needed to be deleted and re-added before the authentication could be successful, since nothing else changed before or after osTicket began having problems.
To clarify the maximum errors/attempts restrictions is on osTicket's side but not the Too many login failures error.
This is more what I was trying to say earlier. Perhaps, if osTicket was somehow stuck on a limit of max errors, it was necessary to delete all e-mail addresses that use the account, to clear that max error limit out, before it could be allowed to try authenticating again as required when re-adding the account.
- Edited
If it reaches the max errors (5) then you have to wait at least 10 minutes to try again. Or you can clear the mail_lasterror and mail_errors columns in the db.
Cheers.
Ok, if it happens again, we'll look at what's there in the DB. It seems to have been "stuck", somehow, since the authentication info we were using was the same before the error, during the error, and after the error was fixed by deleting and recreating all accounts.
Anyway, thanks, both, for your help looking at these issues!
3 months later
I know this is a somewhat old thread, but our exact same initial problem has recurred:
We suddenly started getting error alerts stating "Mail Fetch Failure Alert" and "Too many login failures." Despite receiving this alert, the system continued receiving e-mail tickets for a few more hours, but then stopped. We confirmed the account is not locked. It is an Microsoft 365 account, and we can successfully log into the mailbox using the same password as is configured in osTicket. Also, the Microsoft 365 logs shows all of osTicket's login attempts, and it shows that they are successful! We are also able to send outgoing e-mail successfully using this account from the osTicket Diagnostic tool.
Last time, the solution was to completely delete the e-mail account and re-add it. Though that process ran into several snags due to confusion in how osTicket thought the e-mails were configured, it did work once we were actually able to re-add it. This time, however, we avoided that snag but still cannot re-add the e-mail due to the "too many login failures" error.
Why does this seem to reoccur every few months, and why does osTicket think there is a login failure when we know the settings and credentials are correct, and haven't changed at all throughout any of these failures? What can we check into?
Thanks!
You can reach out to your systems administrator and MS for further assistance. If there is a login failure then there could be network issues, dns issues, etc. It could be anything so without logs we’d be blind.
Cheers.
6 days later
Just an update for anyone who comes across this thread: this time, the issue was that OAuth is now required for osTicket to connect to M365.