I had to resurrect this, I think I may have come up with a fast and simple code-wise solution (he says, hopefully) for this that will cover and self-correct the resulting problems. In short, change the current process into a timed self-expiring process which, if it doesn't get the expected confirmation link click within the time limit, it reverts back to the previous email address value.
In long, a research & testing by-product of this GMF thread of mine, namely whether on premium+ groups an admin can help a user recover from a typo-ed address change, (yes it can because of (a) below), helped me understand the current process flow. There are two underlying problems which cause this issue, (a) the timing of the new address database write, and (b), no undo/Plan B when things go wrong.
Right now, the new address database write (and in effect site-wide change) takes place right away pretty-much after OK is clicked, before the member has a chance to click on the emailed confirmation link sent to the new address. The write probably takes place when the confirmation email goes out or thereabouts. Then, I guess the account goes to NotConfirmed by default and ...
- if the new address is legit and the member clicks on the emailed confirmation link (or if a premium+ admin confirms them) it removes the NC status and all is fine.
- if it was a typo/non-existent new address, when the Dave's-not-here reply to the confirmation email comes back, the account then changes to blue Bouncing and it will stay there since nobody will ever click anything on the other end.
- if a false positive, and more than likely the wrong recipient probably knows it is a mistake and will never click on the link, the account again "stays in limbo". (if they do click on the confirmation link, then at least a group admin can sort it out with the member)
OK, IMO the (a) database write should be moved and take place when the user clicks on the emailed confirmation link as that process should really determine (confirm) if the new account is legit, hence the change should commensurately happen at that point; until then, we continue operating with the old credentials until we prove who we claim to be, or we continue using the existing credit card until we get the new one in our hands. But this fix would still not cover the other cases in (b). That's where adding Plan-B comes in handy, as it can take care of both (a) and (b) cases, meaning no code change (et al) is needed to move the db write part as Plan-B will compensate for it regardless.
Here's the thing, when one changes their email address anywhere, it is more or less expected that they are already in front of a internet-connected device and that at the very least they have access to the new email account. So I personally think that it's a reasonable expectation that the user will complete this changeover (including clicking on the emailed confirmation link) within a reasonable amount of time; 15 min? 30 min? 45? So with this -do it in a reasonable timeframe- presumption then, for Plan-B, when someone initiates an address change, a user-specific "ChangedEmail" timer/timed process/thread/whatever is started which remembers the previous email address value and will revert back to it by default if not stopped in time.
-If the user clicks on the emailed confirmation link in the meantime before the timer expires, that click kills the timer and does everything else normally as it does now, and all if fine.
-If it was a typo/bad address/false positive but they won't click/whatnot, or no confirmation link click takes place, the timer will expire, at which point it will write back the previous (good) address, and all is again fine.
This will cover pretty-much everything that can go wrong, because the only thing that will stop the rollback from automatically taking place, is the user clicking on the emailed confirmation link. (OK, also a false-positive and the (wrong) recipient clicked on the confirmation link would also prevent the rollback, but that would happen/happens now regardless, a group admin and the user have to sort it out)
So when a bad-address happens, the account will stay in limbo for only the timer duration then revert back, so all an affected member has to do is nothing but wait a bit and things go back to the way they were. But even if it's a good address but part of a (forgotten) test, a false-positive address which the recipient is ignoring, a (premium+) admin member email address change gone wrong, etc, unless if the new email address recipient clicks on the confirmation link, things self-correct back to what they were.