So this is a bit disturbing on multiple levels.
1 - who is request the password reset of my account and why? (though this is probably the least interesting or important question - my guess is it’s a script kiddie who found an email address from one of the public mailing lists and gave it a go for grins)
2 - the email says to let facebook know if i didn’t request this reset (which i did not), but doesn’t say how. why don’t they include that info?
2.1 - minor, but, so how do i actually let FB know? keep in mind that i don’t have an active account with FB right now and i don’t use any Meta products currently.
2.1.1 - and would FB actually care or do anything if i do tell them, or would i just be wasting my time?
3 - does Facebook still retain my account, in spite of the fact that I deleted it?
4 - if they do - how much? all of it?! is this more like LinkedIn’s hibernate, where the account is dormant and invisible but can be revived at any time?
So for what it’s worth, the email address in From: is [email protected] which makes it look legit. But I didn’t think this was worth pointing out because, as you and proofpoint dot com correctly state, most email headers are easy enough to forge, so that’s not a particularly reliable guideline.
However, that Received: header in particular is not. It’s the very last one in the email, and that one is written by the folks running my email service. See https://wordtothewise.com/2024/03/anatomy-of-a-received-header/ for an explanation on how these headers work. The short version is that my email service is telling me that they think that they really received this email from 69-171-232-139.mail-mail.facebook.com (though it’s possible that they were able to fool my email service via something else, like IP spoofing)
Worth nothing that the proofpoint dot com article doesn’t list the Received header as being one of the easy to spoof ones. (Of course, earlier Received headers can be suspect, say if one system in the chain is lying about where it received the email from - say to plant a false origin trail. But it must pass whatever forgeries it makes to a server that is beyond its control and (if it’s a good server) one that will faithfully record the next breadcrumb. So a spoofer doesn’t have that much control over the very last header.)
The other thing I should be doing is trying to verify the email via the DKIM signature as one was provided. This is also not so easy to forge because it uses cryptography. There are instructions on how to do this, see https://ediscoverychannel.com/2021/02/28/nothings-dkimpossible-manually-verifying-dkim-a-ctf-solution-and-implications/ and https://github.com/kmille/dkim-verify - but it’s quite complex and technical. (Also, never say never - see for example https://web.archive.org/web/20121026153703/http://www.hotforsecurity.com/blog/mathematician-impersonates-google-founder-to-point-out-dkim-flaw-4061.html and https://www.bitdefender.com/en-us/blog/hotforsecurity/google-apps-safe-from-dkim-vulnerability-says-google for a time when someone found a way past this. Edit: Here’s a more detailed link, https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ )
Ultimately, I can’t say with 100% certainty that it’s legit, so even though it passes more tests than the usual phish would, just in case I followed your advice to avoid clicking on any links directly and notified FB via a manually typed out URL.