Question: I don't know how to write this without it sounding like a plug (lol), but it's not. So please don't close-vote it, even if you really want your editor badge. Here goes:

There's this site called av-comparatives that I use and trust to provide me independent antivirus reviews. You probably do, too, actually. While I keep myself somewhat knowledgeable about infosec, my specialties lay elsewhere and it's so useful for me to have something like that as a resource.

I don't know of anything like that for firewalls, and when I go out to find one, I'm accosted with millions, all claiming that one product or another is the best. Cross-referencing them often leads to one or two that I've never heard of. The (I think) fairly obvious conclusion there is that these are all just fake third party review sites set up for marketing purposes.

Unfortunately, I don't have the resilience to wade through such murky waters for so many more hours :P

> 
> IMPORTANT: This is **NOT** an open invitation to fake firewall review sites to post
>  their crap. I will respond appropriately to spam. 
> 
> 
> 

I'm looking for legit review sites that you, as security professionals, trust (ie: on par with av-comparatives, which you probably trust too)

Answer: 
Possibly. It's not immediately clear if you are relying on the email address as the sole identifier (i.e. you're using it as the username) or if a separate username is in play. If the latter case, then the obvious flaw is that an attacker can supply the username of someone else, but provide their own email address as the destination for the recovery password.

Assuming the email address is the only identifier for a user, obviously it will need to be supplied by them in order to reset their password. I would suggest that regardless of whether an account associated with that email address actually exists, the system should respond similarly. (E.g. saying "Your password recovery information has been sent.") However, you would obviously only want to send the recovery email if there is a corresponding account; if no such account exists there is nothing to recover. This prevents an attacker from trying multiple addresses to see which succeed and which fail, and thus building a list of valid accounts on the system. (If your application is faster to respond if it doesn't need to send the email, you may wish to intentionally add a random bit of time delay to hide that.)
I think it's important to check that entered email addresses actually belong to one of your users before you send the recovery email. Assuming that your sign-up form already collects email addresses, it would be silly not to make use of them to perform this simple check.

Without verification, one major concern would be spammers/hackers entering tons of made-up, invalid email addresses. This would cause your server to send many messages that bounce, and draw attention from spam filters and spammer databases. Eventually, your server could get blacklisted, and no emails from your site would go through anymore.

Plus, mistyped email addresses are quite common, so you could have instances where a user accidentally sends a recovery email to someone else's inbox.

Without additional information about your implementation I can't really point out any other issues, but in phase 3, there are some additional security measures you can consider. For example, you need to make sure that the recovery URLs are long and random, so that they cannot easily be guessed or brute-forced. You also probably don't want the URLs to be active forever; it's a good idea to expire them after an hour or two if a user generates a recovery URL but never actually visits it, or if the user visits it but never provides a new password. To further reduce the chance of a hack, you can completely disable the password recovery feature if the account was used within the past few days, or if the IP-based location is atypical for that user (though these measures may inconvenience users).