I need to look at the code and see were the email editing takes place.
But even if you do this (or even what Rick proposes) you still won't protect yourself on having invalid emails in your database. Example, I have a legitimate email address in my profile. It expires and is invalid. Its still in your system.
That is a good point Nick but the problem that I have found is that a lot of people will go in, once registered and then change their email to something bogus. The process that I outlined will prevent that. What is the purpose of having the CB registration validate a new registrant email if we then give them the capability to turn around and change it to something bogus. Just my opinion but with that hole in the system then the validation option is greatly diminished. Just my 2 cents...
That's the point - your method is justified in the sense that since initially you require email validation via confirmation you might as well implement a similar workflow for email changes.
But there is no stopping the other end from making an email invalid! I can do it in one minute!
If I can just prevent the user from changing the email address after they have signed up, that is good enough for me now.
I understand that the email the user uses to sign up could become invalid for a number of reasons, but thats better than them being able to change it straight off the bat to something bogus.
Rick's idea is perfect but as an immediate fix disabling it would be better for now for now.
I have developed the CB plugin (without hacking the CB core) which protects the Name and Surname from changing... Admins are allowed to change... I can easily modify it to protect email field as well...
It does not disable the field but it discards any changes the user makes to the field.