Hi folks,

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.
 

(a)
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.
(b)
- 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.

Cheers,
Christos

Mark,

I just added a confirmation dialog when changing your email address.
It displays the new email address and requires that you click the Ok
button to proceed. Please check it out and if you think an additional
step is needed after that, please let me know.

I think the confirmation dialog should test the address. That is, send a confirmation message to the address and display the SMTP result - success or failure. I'd go further and keep the Yes button disabled until there is a success code.

The intent is to head off the confusion that occurs when the member makes a typo in the address.

There are some complications, of course. One is the round-trip time for the SMTP response. So perhaps there should be an activity indicator showing that Groups.io is testing the address. Maybe there should be a third button that the user can use to confirm the address despite the lack of response (maybe even in the face of a failure response).

I'm not exactly sure why a user would ever click the "confirm anyway" button. Perhaps they know the address isn't ready for use yet but will be, or perhaps they know the address engages in greylisting or other spam-control protocol that interferes with the test. Of course, to me that would be a red-flag but I'm not going to rule out the possibility that the user actually does know what they're doing.

And also there is the false-positive problem: it /has/ happened to me that a typo in a Direct Add address was a good address belonging to someone else entirely. One could go the further step of requiring that the user verify receipt of the test message. Perhaps using a confirmation code in that message to by typed into a box in this dialog. I'm not sure I want to force that level of functionality at this point, but it may not be an unreasonable requirement and would head off the typo that is someone else's address case.

Shal

On Thu, Nov 19, 2020 at 12:48 PM, Sandi D wrote:

Maybe send a confirmation link to the new address, that they need to click on before before it is changed.

This is also an attractive suggestion, not least because it is consistent in concept to an applicant's need to respond to a Confirmation Message and possibly a Pending Subscription Message. It is also not hugely different to the "email me a log - in link".

Certainly worth considering.

Chris

Maybe send a confirmation link to the new address, that they need to click on before before it is changed.  I get irritated with two the field thing. I use software that auto fills my correct email. If typing is enforced, I tend to make a mistake. Sometimes the second field will not permit the software to autofill. That said, a second field would catch a number of people typing it incorrectly into one. 
By sending a confirmation change link to the new email address, if the wrong email was entered, then no change would be made. If they verified with a link that required them to log in then the changed email would stand. 

I do very much the suggestion to put up some confirmation notice before the changed email is committed. 
--
Sandi Dickenson
ASG Volunteers Group.

On Wed, Nov 18, 2020 at 09:11 PM, Christos G. Psarras wrote:

I agree, maybe put up some confirmation notice

Or (as an alternative) have a second "confirm new email address" box so that unless a typo is repeated in the second box the request is rejected. After all, this is a common enough method used widely to minimise the risks arising from people mistyping their address.

Chris

I agree, maybe put up some confirmation notice when the email address field has been changed and Save gets clicked, a last chance before committing.

Cheers,
Christos

As much as I dislike verification procedures, it might be worthwhile to have a second step to verify an email address that is entered when changing it.  On GMF, we've had at least 3 people make a typo in the new address, but proceed anyway (probably with an OhNoSecond delay ;>).  Two of them have been able to recover by using the typo address and their original password to get back in to change it to the correct address.

Thanks,
Duane