The end of the year is fast approaching and I would like to get some things done before the end of the year. I have a couple of items planned for the next couple of weeks, but then I should be in a better position to work on my to-do list. I hope to have a more comprehensive post within the next few days.

One thing that I am wanting to accomplish before the end of the year and something that is probably the easiest to do is to work on the control panel accessing issues. We have had a few users write in with complaints, especially with Internet Explorer, involving the self-signed certificate when you try to access your control panel or webmail.

The issue has to do with the nature of self-signed certificates. Self-signed certificates are free to create and use, the caveat being that a browser will never recognize a self-signed certificate as authoritative. A self-signed certificate is alright in a situation where you already trust the party that you are dealing with and you just want that connection encrypted. Control panel and webmail access is a perfect example of this. End users should already trust us (you are purchasing hosting from us) and you are not being asked to give any type of credit card or payment information. Yet, you also want your connection with between you and the control panel to be secure.

It seems that the new version of Internet Explorer throws a big fit when it comes across a self-signed certificate. I consider this to be more of a lack of understanding from Microsoft’s point of view regarding self-signed certificates. They are correct in that self-signed certificates should be given an extra set of scrutiny by the end user, but I’m not sure a full warning page is really necessary. This can scare off some users and its really not that much of an issue. Now if you were just starting a business relationship with a company (purchasing something from a company for the first time) you certainly wouldn’t want that company to use a self-signed certificate for their order form. But in a place where a relationship already exists between an individual and a company, a self-signed certificate will serve to encrypt the connection.

At any rate, we have made the decision to switch over the certificates on the control panels and webmail access to real, authoritative certificates. We don’t have authoritative certificates for all of our servers, but we do have them for most of our servers. We hope to be setting up the servers with authoritative certificates sometime this week.

What does this mean for you?

This means that if you have trouble accessing your control panel or accessing webmail then you may be accessing it incorrectly. In order to access your control panel you need to use a link of:

http://yourdomain.com/cpanel

To access webmail you need to be using a link of:

http://yourdomain.com/webmail

Obviously you should change yourdomain.com to reflect your real domain name. If you have trouble accessing your control panel or webmail, please try using the links as described above.

If you continue to have problems accessing your control panel or webmail after you try using these links, please submit a support request so that our staff can look into your issue.

We sent out notices yesterday to accounts that we found to be using weak and insecure mail passwords. Actually the subject of that message was incorrect, but this was not noticed until the message had already been sent out. I apologize for that, but I didn’t think it was worth the effort to resend the notice with an updated subject line.

Not every account received one of these notices, but its probably a good idea if all accounts take a look at their mail accounts and insure that they are using strong and secure passwords.

I suspect that a lot of accounts have mail accounts that are no longer being used. If you aren’t using a mail account for anything, it just makes better sense to remove it. It takes away a point where a hacker or malicious user can gain access to your account.

Lately we have been having a lot of problems with spammers gaining access to mail accounts on the servers and then using those accounts to send out spam. This causes our servers to get blacklisted. The best preventive measure that can be taken is to insure that all access points, points that require a login username and password, are using secure passwords. This includes your main FTP/cPanel password and all of the passwords for your mail accounts.

To help prevent further spamming problems on the servers, we are encouraging all of our users to check their mail account passwords and all of their passwords and insure that they are strong and secure. We have written a guide that details how to update passwords for mail accounts using the cPanel interface or the webmail interface.

The more accounts that are using strong and secure passwords the more difficult it will be for hackers and malicious users to gain access to those accounts and the less likely that our servers will become blacklisted due to this concern.

Scott

We have decided not to make the wholesale changes as described in the previous post concerning SpamAssassin and your default address. This decision was made because the servers have been responding much better ever since a lot of you changed your default address to discard messages. This has helped immensely and we appreciate everyone’s attention to this.

We are still at about 82% compliance in regards to accounts having their default address set to discard messages. Unfortunately, I don’t have any numbers before we started sending out these notices so I do not know how much of an increase this has been. I know that I don’t need numbers to see the remarkable increase in server performance since this change.

When we first started this project, I was thinking about 90% compliance would be a reasonable goal to shoot for. Obviously 90% was not needed to reach the goal we were looking for in terms of server performance, but I believe the closer we can get to 90% the increase in server performance will be just that much more dramatic.

An idea that I am tossing around right now, is to target those server that are below this 82% compliance and send out notices to those servers. The 82% is coming from the grand total of all of our servers. This means some servers are over this percentage and some are under. If we can get those servers that are under 82% compliance up to around 82% then this will help us to achieve our goal of 90% compliance. Another batch of reminders to those affected servers may be issued later this week.

I should quickly point out that we may be handling the SpamAssassin changes that were detailed previously on a case-by-case basis.  If we notice that SpamAssassin is eating up a significant portion of resources on your account and you have your default address set to deliver mail, we may have to disable SpamAssassin on your account.  This is something that we have to reserve the right to do as we try to keep the servers performing at an optimal level.

All-in-all I am extremely happy with the way this project went. I appreciate everyone’s willingness to make adjustments on their end to help the overall health of the servers.

Scott

As most of you are aware, we have been sending out notices to those clients that have their default address set to deliver mail. Throughout all of this, we have been considering some changes to make in the way the default address setup works. These changes have nothing but the best intentions in mind for all users as a whole. We believe the changes will benefit the server’s performance, which at the same time will benefit you as an end user. These changes are explained further below.

It should be noted that if you have not already adjusted your default address setting and you have no use for your default address, then you should consider making these adjustments. The last blog post provides a good detail of how to go about accomplishing this. There is also a guide available that tells you how to disable your default address.

Please note, we are not removing the function of the default address. We have received a few e-mails with this concern. I know there are is a slight minority out there that wishes to continue using their default address. This is fine, we are not going to take this functionality away from you. You will just have to compromise with us as we try to increase overall server performance, while continuing to support your needs.

The following changes are what we are proposing to make and from the looks of it, it looks like these changes may be adopted early next week, baring any further concerns.

Proposal 1 – Disabling SpamAssassin on accounts that utilize their default address. This is part of a compromise. We believe that your default address is going to receive a lot of spam. If you really think about it, this is not a far-fetched belief. Your default address represents an infinite number of e-mail addresses. Whereas if you create a mail account or a mail forwarder, those addresses only receive e-mail if a sender explicitly sends a message to it. With the default address, a spammer can send out a spam message to literally thousands of bogus e-mail addresses at your domain name and they would all be picked up by your default address. This just makes filtering those messages with SpamAssassin all the more wasteful. Everytime SpamAssassin is invoked, it takes up server resources. If the server is invoking SpamAssassin every time a spam message is sent to a bogus e-mail address on the server, this is taking up server resources that could be used somewhere else on the server. By disabling SpamAssassin on accounts that use their default address, we are still allowing access and functionality to the default address for those clients that want this, but they won’t be able to use SpamAssassin filtering. For those users, it just becomes a case of what is more important to you, server-side spam filtering or a server-side default address?

Proposal 2 – Disallow the default address to forward off of the server. Again, this issue goes back to the default address receiving a high percentage of spam messages. Any time you forward mail off of the server you run the risk of getting the server blacklisted or blocked. When you forward mail off of the server, if the destination server thinks the message is spam, they will see the message as being sent by our server and may block or blacklist our server. When our server becomes blacklisted or blocked, then nobody on the server can send out mail from our server. We have seen instances in the past where a blacklist of our server has been traced back to someone forwarding their default address off of the server. We do have other preventive measures in place that aims to prevent spam messages from being forwarded off of our server, but these measures are not 100% reliable. Couple that with the fact that the default address is likely going to receive a lot of spam and it is easy to see why you should not forward your default address off of the server.

While this proposal will prevent you from using your default address in some manner, it won’t directly stop you from using your default address. If you feel that you must use your default address, then you need to set it to deliver mail locally on the server instead of forwarding it off of the server. This proposed change would only affect those clients that are forwarding their default address off of the server.

Barring any other unforeseen circumstances, we will likely begin rolling out these changes early next week. If you have any comments concerning these changes, you should let us know, so that we can deal with those concerns or push back these changes.

I really do not think these changes will affect the vast majority of our clients. You will just notice better server performance due to increase server resources.

Scott Mutter

Director of Administration

I think there has been some confusion over the recent default address notices we have been sending out. We are trying to send these notices out in a somewhat weekly manner at least for a period of time, so that our clients are aware of this. We will probably be sending out another notice next week and I hope to clarify the problems in that message, but I thought I would go ahead and try to clarify some questions in this post.

When you receive the notice concerning your default address in your e-mail, you will see a section saying something like:

Obviously the domain names listed will be different for each client. Some clients may have more than this listed, others may have less. This is just an example, don’t take it too literally.

I created a flowchart to display this better:

See how there are three accounts listed here, yourdomain.net, subdomain.yourdomain.net, and anotherdomain.com. For each of these domains listed ask yourself the following question:

What e-mail addresses at this domain name do I expect to receive e-mail at?

Its really that simple. Basically you are going to answer this question with one of two answers. The first answer, None, at this point you know it is completely safe to set your default address to discard messages as SMTP time. If this is your response, simply set the default address for that domain to discard messages and repeat this question for the next domain listed.

The other answer is:

I expect to receive e-mail at …, …, …

How many e-mail addresses you list is completely up to you. You may list one. You may list two, you may list 200. It doesn’t matter.

Now for each address that you just listed, ask yourself:

Is this e-mail address set up as a mail account or as a mail forwarder in my control panel?

You will have to log into your control panel and check this for each address. If each e-mail address you have listed is set up either as a mail account or as an e-mail forwarder, then it is safe to set your default address to discard messages at SMTP time.

If some or all of those e-mail addresses you mentioned are not set up as mail account or mail forwarders, then consider setting them up as such. You may need to reconfigure your e-mail program to use a new mail username and password, but the benefit is that you will greatly reduce the amount of spam that you are receiving.

If you have a lot of e-mail addresses that you expect to receive e-mail at and you want all of those messages to collect into a single mail account on your account, just contact support and we will be glad to set up those forwarders for you. We can do a mass forwarder set up so that you don’t have to use the control panel interface to set up each and every one of them. Remember, forwarding mail off of the server is a bad idea that will lead to our server becoming blacklisted. It is really preferred that you use forwarders internally, within your domain.

For information on setting your default address to discard message at SMTP time, see our guide which gives great details on how to set this up.