Facebook
Twitter
W
Who-m3
Guest
With Plesk 8.0 came the push of the new "Domain Alias" feature. A new way to save your domains, but provide your clients a way to have more than one domain pointing to their website. Although many of the more advanced users have had ways of doing this already, it was something everyone was happy to see FINALLY put into play. Yet, with all things that are highly publicized, there are let downs...
First, you give us Domain Aliases with DNS Records that don't use the DNS Templates we've set up. This means we've got to go through and change any and all records that we need to be a certain way IF we want them to follow the standards on the box. Yeah, that's fun. That's why the DNS Templates were so nice. I could set up the stuff that needed to be prepared for the propogation, including the slave server setup, etc., and the client wouldn't ever have to confuse themselves with "what do you mean it doesn't work?". Now, when they mess it up, it's a click to fix. But, Domain Aliases don't follow this, which makes it 10 times harder when a client messes up the Domain Alias. Now, some of you are saying "Easy fix, just take away DNS Management from the Client.", which would do the job..but that'd also take options from the client, and overload my helpdesk should they need modifications. I prefer my clients to be able to access their domain, as it is THEIRS.
Second, you give us options on the primary domain to "Bounce", "Reject", or use a "Catch-All" address for e-mail to the domain. Yet with Domain Aliases, we don't have this option. We have no options. With a domain that's previously been used by a client (frequently, or if at all), but suddenly they move to a new domain, that leaves some issues. Example: One client switches to Domain2.Com, Domain1.Com is a Domain Alias. They don't want to receive e-mail from certain accounts on that domain, but want other e-mail to come through. They create the accounts on Domain2.Com that they want, set up Mail and Domain aliases. All of the rest...bounce to the originator (or in this case, no where, since it was a majority of spam, meaning it comes right back to my inbox..).
1. Domain Templates are a must. If they work for the Primary Domain, they have to be able to work for the Domain Aliases. It shouldn't be hard to do, seeing as it currently uses your original fixed "template" anyway.
2. Give us the option to modify, or mirror the settings from the primary domain for the Domain Alias's Mail Config. If "Bounce" is selected, let it bounce. If "Reject" is selected, add the domain to the list in /var/qmail/control/rejectnonexist so that it'll reject instead of bounce. If Catch-All, set up the Catch-All address on it. But please give us a way to manage it properly.
That's about all I have for now, that's my little rant for the 18th of July. Anyone feeling the same way, feel free to add your comments. Those of you who disagree, I welcome your responses as well. I just hope to get someone at SW-Soft to realize that this is an incomplete feature, and these seem like they'd be easy things to add to the next "hotfix" release...(Hopefully, anyway). (Side note: Please excuse any typos, etc. I'm too lazy to use spell-check.)
First, you give us Domain Aliases with DNS Records that don't use the DNS Templates we've set up. This means we've got to go through and change any and all records that we need to be a certain way IF we want them to follow the standards on the box. Yeah, that's fun. That's why the DNS Templates were so nice. I could set up the stuff that needed to be prepared for the propogation, including the slave server setup, etc., and the client wouldn't ever have to confuse themselves with "what do you mean it doesn't work?". Now, when they mess it up, it's a click to fix. But, Domain Aliases don't follow this, which makes it 10 times harder when a client messes up the Domain Alias. Now, some of you are saying "Easy fix, just take away DNS Management from the Client.", which would do the job..but that'd also take options from the client, and overload my helpdesk should they need modifications. I prefer my clients to be able to access their domain, as it is THEIRS.
Second, you give us options on the primary domain to "Bounce", "Reject", or use a "Catch-All" address for e-mail to the domain. Yet with Domain Aliases, we don't have this option. We have no options. With a domain that's previously been used by a client (frequently, or if at all), but suddenly they move to a new domain, that leaves some issues. Example: One client switches to Domain2.Com, Domain1.Com is a Domain Alias. They don't want to receive e-mail from certain accounts on that domain, but want other e-mail to come through. They create the accounts on Domain2.Com that they want, set up Mail and Domain aliases. All of the rest...bounce to the originator (or in this case, no where, since it was a majority of spam, meaning it comes right back to my inbox..).
1. Domain Templates are a must. If they work for the Primary Domain, they have to be able to work for the Domain Aliases. It shouldn't be hard to do, seeing as it currently uses your original fixed "template" anyway.
2. Give us the option to modify, or mirror the settings from the primary domain for the Domain Alias's Mail Config. If "Bounce" is selected, let it bounce. If "Reject" is selected, add the domain to the list in /var/qmail/control/rejectnonexist so that it'll reject instead of bounce. If Catch-All, set up the Catch-All address on it. But please give us a way to manage it properly.
That's about all I have for now, that's my little rant for the 18th of July. Anyone feeling the same way, feel free to add your comments. Those of you who disagree, I welcome your responses as well. I just hope to get someone at SW-Soft to realize that this is an incomplete feature, and these seem like they'd be easy things to add to the next "hotfix" release...(Hopefully, anyway). (Side note: Please excuse any typos, etc. I'm too lazy to use spell-check.)
