[cpanel11] cPanel 11 changes

This is an overview of what changes you might see in regards to the cPanel 11 upgrade.

• SpamAssassin Subjects — All spam messages that are flagged by SpamAssassin will have their subjects rewritten to include the term ***SPAM*** in their subjects. Previously this was customizable in a user’s control panel, but this has been removed in cPanel 11. This is part of cPanel 11’s plan to be more efficient. If you are using the spam box function on your account, spam messages that go into your spam box will also be rewritten to use the ***SPAM*** subject. This cannot be changed as it is now a server-wide function.
• Password Strength Check — The new control panel theme includes a password strength checker that helps determine how good your password is. This is something that we have a lot of trouble with. Users want to use very simple and easy to remember passwords, but what they don’t realize is that those simple and easy to remember passwords are also easy for malicious users to guess and hack into your accounts. It is always a good idea to use a strong password.
• Video Tutorials — The new control panel includes a lot of Flash based tutorials that show you how to perform certain tasks on your account. It should be worth noting that not all of the tutorials apply to our offerings and the tutorials may not represent a complete replica of our offering. We have striped out some of the cPanel 11 offerings because we believe them to be ill-advised or not ready for production use.
• Improved File Manager — The File Manager in cPanel 11 has been completely rewritten to provide a cleaner interface. I have read reports of a few issues concerning the new File Manager, but I’m not sure if they are actually problems with coding or just with users having difficulty adjusting to the new set up. The older Legacy File Manager is also still provided.

As well as these included features in cPanel 11, I am also going to take this time to implement some changes to the mail server. A lot of these changes I have successfully implemented on some of our other servers and have gotten a lot of good use concerning these improvements.

• Reject mail when account is over quota — I have implemented a system that checks to see if your entire account is at or over its quota limit. If it is, the server will not accept new messages for your domain and the sending server will receive a message stating so. The sending server will then be responsible for sending a bounce message back to the original sender. We have a lot of problems with spammers writing e-mail addresses that exist on the server. If an account is over its quota, the server won’t be able to deliver that message and it just causes problems with our mail queue growing too large. The larger our server’s mail queue gets, the bigger the performance hit the server takes.
• Reject mail when a mail account is over quota — This is something new that I have developed. I will be the first to admit that I am not a big fan of setting mailbox quotas on e-mail accounts. In my opinion, when you set up a mail account you are going to do one of two things. You are either going to check the mailbox regularly or you are not. If you are not checking the mailbox regularly, then what’s the point of having the mailbox created in the first place? If you are checking the mailbox regularly then the mailbox should never go over its quota. Even if you are only checking mail via webmail or IMAP, where the messages stay on the server, you would not want to set a mailbox quota because the mailbox would eventually reach that quota. If someone can explain to me a good reason for using a mailbox quota, I would like to hear it, but I just don’t know of one. In the meantime, I am going to try this system where the server finds mailbox that are at or near their respective mailbox quota limits and then rejects messages to those addresses in the same manner that it rejects messages when an overall account is at or over its quota limit.
• Spam filtering for e-mail forwarders — We have had a ton of problems with users forwarding their e-mail off of the server and causing our servers to become blacklisted by various providers. I really wish there was some way I could convince our clients not to forward mail off of the server. If you have an @aol.com or @comcast.net or other e-mail address that you prefer to check, please just use that e-mail address when you are giving out your e-mail address. Granted it may not look as professional as giving out an @yourdomain.com e-mail address, but if you need to use @yourdomain.com e-mail addresses, please learn how to check those addresses directly from our server. When you forward mail off of the server, you also forward your spam. When these forwarded spam messages reach their final destination (for example, the AOL servers if you are forwarding mail to an @aol.com address) then those servers (the AOL servers) see those spam messages as being sent by our server and they will blacklist our server. This spam filtering system, grabs a snapshot of all the e-mail addresses that forward mail off of the server and subjects messages to those addresses to a SpamAssassin based spam scan, to determine if the message is a spam message. If the message is determined to be spam by SpamAssassin, the message will be rejected. If our SpamAssassin determines that a message is a spam message, then its a good bet that other services, such as AOL, will also determine the message is spam. We also have an information page that discusses this feature in more detail. We have had a few users complain about this feature, but the fact is, if you need someone to send you a message and you are giving them an address that forwards off of the server, then you either should be giving out the other e-mail address where the message is forwarded to or setting up that address as a mailbox on the server and removing the forwarder.

As well as these changes, some other options that I am considering making are listed below.

• Remove the Default Address link — The default address is really just more of a burden than anything. Basically all it does is collect spam, because spammers are either sending messages to asdf@yourdomain.com causing the default box to collect mail, or a spammer is sending out spam and faking their return address to be asdf@yourdomain.com causing your default box to fill up with undeliverable messages. If I can get most of our clients to set their default box to :fail: then this would open the door for better anti-spam measures on the server. I thought about removing the Default Address link in user’s control panel, but I wanted to give users the chance to set their default address to :fail: before I did away with it. There is an information page concerning the usage of the default box. If you have a lot of addresses (say 50 or so addresses) that you want to forward to one specific address, but do not want to manually set up internal forwarders for those addresses, submit a support request and our techs should be able to help you with this. If you need more forwarders so you can forward addresses internal within your domain, let us know and we can likely add more forwarders to your account at no charge. Any of these options is preferred over using your account’s default address.
• Mailbox quota removal — I did toy with the idea of removing mailbox quotas when we rolled out cPanel 11, but instead I developed a system to reject mail for mailboxes that are at or over their quotas. That system is still experimental, and I may yet decide to remove the mailbox quota option in your control panel. The reasons are explained in the above section.

This details some of the changes we are proposing with the cPanel 11 upgrade. I may try and get some screenshots of the new control panel interface a little later and post them. Let us know what you think. Give us feedback concerning the upgrade and the changes. We want to know what you think, as it helps us to make better informed decisions.