Internal forwarding only option needed
I desperately want to stop dealing with ignorant users who think that email forwarding is cool but then want to report as spam everything (seemingly) that is forwarded to them.
I call for cPanel to implement an option to allow ONLY internal forwarding. This way we could allow clients to use internal role-based (i.e. support, sales, info) aliases that forward to domains that they are hosting on the same account with us, (keeping the forwarding all on the same server), but we could put an END to the myriad of problems caused by external forwarders.
Please help by voting for this feature request:
-
Hi, Reference to disable the external forwarding is mentioned in below link: and a feature request for same is also made, you can check below link: Similar thing has been implemented too in the below feature request. 0 -
The feature request is marked as needing more information. Hopefully my last post provides it, but if you need more please ask! I don"t see any sort of request for information on the feature request itself, so I figure maybe it"s just in limbo while you see where this discussion thread goes. I believe my request is different than the existing request to prevent forwarding to free email accounts, but if you want to combine the two into a more robust feature idea that provides these final forwarding options I think it would be awesome: 1. Full forwarding (as it exists now). 2. List of external domains to which forwarding IS NOT allowed. (Would satisfy those who want to disable forwarding to free email providers, internal forwarding unrestricted) 3. List of external domains to which forwarding IS allowed (i.e. ONLY those external domains will be allowed, internal forwarding unrestricted) 4. Option to disallow ALL external forwarding while allowing internal forwarding to any domain on the same server or same cPanel account (either would be okay by me.) 5. Optionally: No forwarding allowed at all (this can be done via feature list removal but it could legitimately be a forwarding option so that someone who changs from 1-4 to 5 could have the option to trigger a cleanup that would remove all existing forwarders.) 0 -
Hi @MediaServe, You bring up a valid concern. I've reached out to one of our Community Managers to update the information on the following feature request so that it reflects the need to restrict forwarding to any or all remote mail servers (as opposed to just free email account providers): option to prevent forwarders to free email accounts This way we won't lose out on the existing votes. I'll update this thread once the above feature request is updated. In the meantime, feel free to copy/paste your feedback on this thread as a comment on the above feature request. I encourage anyone reading this thread and seeking the same feature to vote and add your comments to the above request. Thanks! 0 -
Great, I"ve added my comments to that feature request. I hope people will realize how useful this would be a vote for it. That other feature request has been collecting dust for 4 years now! 0 -
I agree with you on this, but there is a logistical concern. Basically, you're wanting it so that if the domain name of the forwardee being set up isn't in /etc/localdomains then don't allow it to be set up. Or I suppose you could take it a bit further, if the forwardee isn't a domain name owned by that cPanel account, then don't allow it to be set up. The problem comes up, what happens if that domain moves? Say [plain]example1.tld[/plain] decides to set up a forwarder such that [plain]tom@example1.tld[/plain] forwards to [plain]jerry@example2.tld[/plain]. In this example, [plain]example1.tld[/plain] and [plain]example2.tld[/plain] exist on the same server at the time of this forwarder creation. Now what happens if [plain]example2.tld[/plain] cancels or otherwise gets deleted from that server and now resolves to another server or uses Google Apps for mail? How do you combat the existing [plain]tom@example1.tld[/plain] -> [plain]jerry@example2.tld[/plain] forwarding? 0 -
I agree with you on this, but there is a logistical concern. Basically, you're wanting it so that if the domain name of the forwardee being set up isn't in /etc/localdomains then don't allow it to be set up. Or I suppose you could take it a bit further, if the forwardee isn't a domain name owned by that cPanel account, then don't allow it to be set up. The problem comes up, what happens if that domain moves? Say [plain]example1.tld[/plain] decides to set up a forwarder such that [plain]tom@example1.tld[/plain] forwards to [plain]jerry@example2.tld[/plain]. In this example, [plain]example1.tld[/plain] and [plain]example2.tld[/plain] exist on the same server at the time of this forwarder creation. Now what happens if [plain]example2.tld[/plain] cancels or otherwise gets deleted from that server and now resolves to another server or uses Google Apps for mail? How do you combat the existing [plain]tom@example1.tld[/plain] -> [plain]jerry@example2.tld[/plain] forwarding?
I actually addressed that in my feature request but that may never see the light of day. Basically removing a domain would simply have to clear out any forwarding it"s involved in if the option to NOT allow external forwarding is enabled. So, you have d1.com and d2.com on a cPanel account, with a mixture of fowards from d1 > d2 and d2 > d1. When you delete d2, no matter what side of the forward it"s on, any forward from or to d2 must go also. It"s shouldn"t be terribly complicated. If the MX record gets changed and a domain is moved from /etc/localdomains to /etc/remotedomains that same logic will also have to remove any forwarders for the domain. I think with proper planning it can be done in a manner where everything is properly synchronized as changes happen. Off the top of my head there would be code changes necessary to modifying accounts (if the domain is changed), deleting parked or addon domains, changing of MX records that triggers a domain to be moved from /etc/localdomains to /etc/remotedomains, the transfer tool possibly (although as long as the account remains on the original server in an unsuspended state the forwarder could remain, but with the express option which disables the account on the original server the forwarder should be removed/disabled somehow) There would still be cases where the dns servers for a domain could point it somewhere else, but if the account is still on the server and active, and the domain is in /etc/localdomains, just leave the forwarder and have Exim route it locally which is usually what happens in such a case. In fact all of the code could probably be centralized in the code that adds/removes domains from /etc/localdomains, actions that I suspect are triggered by all the cases where forwarding deletion might need to be done.0 -
I think you have some robust ambitions and high expectations that a) cPanel will be able to do all of this and b) that end-users will understand it. An alternative solution, and this is what we have been doing for several years (although, admittedly through a very cludgy design... but it works), would be to force spam detection for any email address that forwards off of the server or has an autoresponder set up. Do the spam scanning during SMTP time, and reject the message from ever being handled by the server if it is determined to be spam. I have since added the ability to customize spam scores for email addresses that tend to be forwarding a lot of spam (sometimes setting the required_score for those email addresses into the negative). The downside here is that if the email address exists as both a real email account (POP3 or IMAP account) and as a forwarder that forwards off of the server, then neither gets the message if it is determined to be spam. But this is a write off I'm willing to accept (if the end-user doesn't like it, then they should probably rethink their need to forward mail off of the server). I also added in default address checks. If the user sets their default address to forward off of the server (which is beyond stupid) then mail for the entire domain name is subjected to SMTP time spam scanning. The difficult part was dealing with daisy chained forwarders, i.e. [plain]email1@example1.tld[/plain] forwards to [plain]email2@example1.tld[/plain] which forwards to [plain]email3@example1.tld[/plain] which forwards to [plain]email4@hotmail.tld[/plain]. Keep in mind also, some end-users will also use filters to forward mail off of the server. That is yet another avenue you would have to go down and address. I like your idea in principle. And I even agree with it. But there are a ton of hurdles that have to be overcome. 0
Please sign in to leave a comment.
Comments
8 comments