Update Contact Info - allow customer to use email with their own domain
At some point, cPanel began forcing customers to use an off-site email address for their contact email address, under "Update Contact Info" in cPanel.
If the customer attempts to enter in a locally hosted email account, they are given the error:
Please use an email address that is not at this domain
However, some customers (perhaps most?) do not have multiple email addresses. Their only email may be the email address that they have hosted with us. Thus, customers are frustrated by this requirement.
The argument for forcing customers to use an off-site address is for the situation where their mailbox or disk space quota has been exhausted... they would not get the notification. However, disk quota and mailbox warnings go out at 80% (cPanel default), 90% (cPanel default), and at 98% (cPanel default). So, the customer would get 3 notifications before their disk or mailbox quota is exhausted, even if their notification email address is a local account.
Therefore, I would like to request a new "Tweak Setting" under the "Notifications" section, to give server admins the option of enforcing the off-site email requirement, or not.
Require customer to use an off-site email address for Notifications _yes (default) _no
What do you think?
Original thread: http://forums.cpanel.net/f145/update-contact-info-allow-customer-use-email-their-own-domain-case-51861-a-193861.html
This is now public, and available in v66 in the CURRENT tier!
Get a quick overview of all the improvements on the version 66 Release Site, or read the full Version 66 Release Notes.
This is now public, and available in v66 in the CURRENT tier!
Get a quick overview of all the improvements on the version 66 Release Site, or read the full Version 66 Release Notes.
I second this request. Sometimes people don't want to give out external email addresses, which in turn results in resellers not completing the contact email for new accounts, which is not a required field... :(
I second this request. Sometimes people don't want to give out external email addresses, which in turn results in resellers not completing the contact email for new accounts, which is not a required field... :(
Sure hope this can be implemented. I really do understand why you might not want someone to enter in a local email... but please let us server admins decide. :-)
- Scott
Sure hope this can be implemented. I really do understand why you might not want someone to enter in a local email... but please let us server admins decide. :-)
- Scott
I think this is more than a "great" feature. This is a MUST HAVE feature! I (along with others) host my email with another provider and it has nothing to do with my webhost at all. Not having this as an option is crazy to me.
I think this is more than a "great" feature. This is a MUST HAVE feature! I (along with others) host my email with another provider and it has nothing to do with my webhost at all. Not having this as an option is crazy to me.
One problem with having a contact address on the same domain is that when the user does not remember the password for their account, they have no way of receiving notifications. I think the "not on same domain" rule came about as a result of needing an email address to send Reset Password and more recently New Sub-account Invitations to users. With a local email address, these emails would likely never get read since the user can't actually log in to these accounts.
One problem with having a contact address on the same domain is that when the user does not remember the password for their account, they have no way of receiving notifications. I think the "not on same domain" rule came about as a result of needing an email address to send Reset Password and more recently New Sub-account Invitations to users. With a local email address, these emails would likely never get read since the user can't actually log in to these accounts.
Tom, I think we all appreciate the reason(s) for forcing users to use a remote email. But, we have customers that do not have a remote email (they use US for email -- remember, that is part of what we sell them)... or, even if they have a remote email, it is not what they check regularly (remember, we sell them email, so they actually use OUR email service), thus their notifications are not being seen by forcing them to use a remote email. In any event, all that I am asking is that you give us the CHOICE. Make it a Tweak setting.
Tom, I think we all appreciate the reason(s) for forcing users to use a remote email. But, we have customers that do not have a remote email (they use US for email -- remember, that is part of what we sell them)... or, even if they have a remote email, it is not what they check regularly (remember, we sell them email, so they actually use OUR email service), thus their notifications are not being seen by forcing them to use a remote email. In any event, all that I am asking is that you give us the CHOICE. Make it a Tweak setting.
Another idea: If you sense the email is local, then pop up something that says "We recommend adding another email address that does not use the same domain as your hosted email..,.. " and perhaps explain why. Then force (or give them the option, based on a Tweak setting) to enter another remote email.
Another idea: If you sense the email is local, then pop up something that says "We recommend adding another email address that does not use the same domain as your hosted email..,.. " and perhaps explain why. Then force (or give them the option, based on a Tweak setting) to enter another remote email.
I agree with the previous suggestions. This has been a headache of mine for quite some time. Customers don't receive mailbox/storage/bandwidth alerts due to having no address or having an outdated (retired) mailbox and not being able to change it. While the intention of the idea is nice, it shouldn't be forced. I agree with the option to warn vs. completely restrict.
I agree with the previous suggestions. This has been a headache of mine for quite some time. Customers don't receive mailbox/storage/bandwidth alerts due to having no address or having an outdated (retired) mailbox and not being able to change it. While the intention of the idea is nice, it shouldn't be forced. I agree with the option to warn vs. completely restrict.
Here's another good reason to implement this: some clients are using Google Apps, so the domain email account is hosted externally, thus making no real reason to prevent them from using it as cPanel contact email.
I think it should be a switchable option at Tweak Settings level, as I stated above 4 months ago.
Here's another good reason to implement this: some clients are using Google Apps, so the domain email account is hosted externally, thus making no real reason to prevent them from using it as cPanel contact email.
I think it should be a switchable option at Tweak Settings level, as I stated above 4 months ago.
This is such a time waster, as a server admin. Customers can't understand this requirement and ask for help. I have to log in as root into WHM, then click Modify Account, where I can put in any email that I want. This should be the most simple thing to implement for cPanel, as a Tweak setting (could default to current behavior) -- surely this request must have just been lost?
This is such a time waster, as a server admin. Customers can't understand this requirement and ask for help. I have to log in as root into WHM, then click Modify Account, where I can put in any email that I want. This should be the most simple thing to implement for cPanel, as a Tweak setting (could default to current behavior) -- surely this request must have just been lost?
Hey folks! This request is on one of our development backlogs, and is definitely on our radar. As soon as we're able to get to it, I'll update here.
Hey folks! This request is on one of our development backlogs, and is definitely on our radar. As soon as we're able to get to it, I'll update here.
This is now being worked on by our development team, and is aimed at version 66!
This is now being worked on by our development team, and is aimed at version 66!
Yay, this is great news!! Although this feature credits "Nathan Lierbo" with sharing it, it's my request (I wrote this request word for word 4 years ago in the old forums). I've bent more than a few ears at various cPanel meetings about this, and I'm glad there is finally some traction. To this day, it's an incredibly frustrating limitation. Thanks for listening, cPanel!! :-)
Yay, this is great news!! Although this feature credits "Nathan Lierbo" with sharing it, it's my request (I wrote this request word for word 4 years ago in the old forums). I've bent more than a few ears at various cPanel meetings about this, and I'm glad there is finally some traction. To this day, it's an incredibly frustrating limitation. Thanks for listening, cPanel!! :-)
I understand why you want this but seriously, this makes sense. In the past we had the issue all the time, users not getting important emails because they were using the email account that was suspended for abuse, payment, etc.
While I understand some folks may require this. I don't. It should be an option and I like how it works today. I don't want users setting as contact information the same email account that they are hosting for obvious reasons.
I understand why you want this but seriously, this makes sense. In the past we had the issue all the time, users not getting important emails because they were using the email account that was suspended for abuse, payment, etc.
While I understand some folks may require this. I don't. It should be an option and I like how it works today. I don't want users setting as contact information the same email account that they are hosting for obvious reasons.
This feature is now in a development build of cPanel & WHM version 66: 65.9999.136 (66 devel build)
We currently anticipate version 66 going to the production CURRENT tier in late June or early July.
This feature is now in a development build of cPanel & WHM version 66: 65.9999.136 (66 devel build)
We currently anticipate version 66 going to the production CURRENT tier in late June or early July.
This is now public, and available in v66 in the CURRENT tier!
Get a quick overview of all the improvements on the version 66 Release Site, or read the full Version 66 Release Notes.
This is now public, and available in v66 in the CURRENT tier!
Get a quick overview of all the improvements on the version 66 Release Site, or read the full Version 66 Release Notes.
Replies have been locked on this page!