Accidentally Set Email To POP3

We have a self hosted setup in our office that I have been using to learn ERPNEXT. I was setting up the email domain and account and wasn’t having any success sending emails no matter what setting I used. I followed the documentation and the account added without any errors, but would not send out any emails. I tried several different configuration settings trying to get it to work but had no success.
During this I guess I set it to POP3 at some point and now all the emails (3+GB) got deleted from our main business email account’s inbox on our hosting provider.
How can I restore all the emails back to the Inbox on our hosting provider?

If I change it to IMAP will it return the email back to the server, will it delete it altogether or will it simply stay put in ERPNEXT? I can’t afford to loose all the email. TIA

No, they won’t be returned back to the server if you set it to IMAP. The behavior you’re describing isn’t a result of ERPNext but just how POP3 works.

I don’t know of an easy way to get these back, unless your email service provider has a backup or a temporary hold for cleared emails.

Are emails not stored somewhere in ERPNEXT as .eml files?
Going into the communications under the email account it only shows 110 emails total (not even close to the amount that were on the server) and they’re not even in order either (goes from today, yesterday and then jumps to 7 years ago skipping everything in between), all after clicking on show 500 per page. Strangely it somehow deleted every single email from the server though.

Hmm…I’m concerned by this line:

POP3 mail is fetched in a raw format via the poplib library. I don’t believe it gets reencoded as .eml archives anywhere before it gets written to the Communication doctype. If Frappe can’t handle the email for some reason, it will dump the raw code to a Unhandled Email doc.

The bit I’ve highlighted above, however, seems to suggest that emails past 100 are just getting dropped. If that’s what’s happening, it’s a pretty egregious design flaw, which appears to have been unchanged in the code for almost a decade now.

Unfortunately, I don’t think there’s much hope of recovering this from the ERPNext side.