How far should be the generalization of a class name and aggregation of similar behaviors?

The question may seem a little basic or entry level, but it is making me wonder a lot about how far should the generalization and function aggregation should go. Today I was reviewing code on my daily work and faced the following situation. Two classes named respectively EmailCancellationController and EmailConfirmationController were having their methods moved to a new class named UserAdministrationController. The last one end up with some methods and attributes which I think doesn't completely follows the SOLID principles.

Am I wrong on thinking that it doesn't fit the single responsibility principle? This class would need to handle Cancellation and Confirmation responsibilities. Or is it right, because it is handling only the user confirmation and cancellation, not another entity such as employee or student.

Apart from that, I think that someone else handling changes on this class could create a bad coupling while adding a method and using in both cancel and confirmation methods, or the class could grow more and more with more responsibilities such as EmailUpdateSomethingController.

My points here are:

• Shouldn't class name be more specific than ?
• Is there an approach on how classes should be named?
• Should we generalize classes maintaining the SOLID principles?
• When should we aggregate similar behaviors in a class?