When you’ve been actively in business in an industry for over 23 years, things can change. But when that industry is about 23 years old and is one of the fastest changing and evolving industries in the world, you are guaranteed change – a lot of it!
In that 23 years, I’ve come to understand that there are a few things that will never change:
- People don’t often like change. This is most apparent when things seem to work already. Sadly, innovation and security fuel the machine and set the pace. As much as you might like your current mobile device, operating system, computer or applications, they are going to change and they won’t ask you your opinion first.
- The more you try to protect your customers from change by allowing legacy setups and installations to function, the bigger and more painful the mess will be when there is no choice but to flick the switch and make the change.
- No matter how important the change or obvious the reasons for it, people will complain about it (and in many cases with good reason).
- It doesn’t matter how much more sense your system makes and how much good intention is involved in creating your system. If the industry says they’re going this way, you need to be ready to adapt or you will be forced to make sudden and drastic changes. (see #2 and then #3)
There’s a reason I’m going here with all of this and a reason that some of you may have been sent here to read it. That’s the introduction to the reasons and solutions to a problem you may be having sending email. You might not even be a V3 customer — it seems that we’re not alone in this one.
Here’s a short cut to the end for our clients that will give you the shortened version with just the answers and no explanations.
SSL Issues
A long time ago, encryption wasn’t as important because people’s home and office computers were typically safer from prying eyes and data sniffers. However, the bad guys got smarter, WIFI became more prevalent, and more people were doing things outside of their “safe” environment. Hence, the growing demand to turn on SSL for things like email came into play.
At the same time, we were looking to make sure that customers always had access to the email and websites. Part of that was to ensure that if a server began to fail or become overloaded, we could quickly migrate clients to other servers to offset things. That’s just something that I learned that people appreciated back in the 90s when we were able to do it. Old habits die hard.
The biggest problem with SSL is that there are some costs for clients to have their own SSL certificates and dedicated IP addresses. Few are willing to accept the extra cost. So, there are two solutions:
- You use the server SSL certificate that we install by using the V3 server name as your mail servers. Problem: if you are using this method, you aren’t using your domain name as the server name and you are hooped if we have move you to another server for whatever reason
- If you use your own server name and don’t have an SSL certificate, you will have a security exception to have to deal with. Not all software plays well when this happens and most users have no idea what do with this. This also becomes an annual problem when the server certificates are renewed and the process starts all over again.
We’ve long had the policy that you need to use your own server name to ensure that we could move your account if needed. Of course, we have no way to police this and it’s not mandatory – it’s just been the only way we’ve supported. Recently, we discovered just how many people are doing it the first way (and that most server auto configuration scripts force it that way). So much for trying to make it easier for people.
POP before SMTP
Chances are, that header just made you stop, re-read it, and then your eyes glazed over. There’s a good reason for that – it’s the old method (we’re talking back to the dialup modem days) of how people were able to send out email through their mail servers without leaving everything wide open for spammers. Essentially, once you logged in to pick up your email, the server would note your IP address and allow mail to be sent from it for a short period of time without further authentication. That was great until everyone started roaming around and sending email from coffee shops, airports, and malls. Now, with cellular networks and public WIFI, chances are that if you use this system to send mail, once you have done it, a lot of the people around you will have access to send it to. We don’t really want that.
So, SMTP authentication was born. The mail server, before accepting your outgoing mail, will authenticate you with your email address and password. If you don’t supply one, you will likely get some sort of complaint from the server about trying to relay email.
Recently, the control panel that is widely used by many hosting companies started remind the system administrators that this long gone, archaic and insecure POP before SMTP thing might still be enabled on the servers. So, as a good sysadmin does, they turn off that setting because nobody should be using it any more and it hasn’t technically been supported since just after the previous millennium started.
Guess what… It’s amazing how many people accidentally used this because they never bothered to turn on SMTP authentication and almost always picked up mail just before they sent it. Flick the switch and suddenly people can’t send mail.
The Right Way and the Solution
To say this has been a humbling situation over the past few weeks would be an understatement. We’ve been migrating clients to some newer, more powerful and faster servers under the assumption that people heeded our advice, followed our instructions and wouldn’t notice anything but things being faster and more stable. After all, we’ve been able to move dozens in the past with very little issues. Surprise!!!
We concede. I realize now that people will do whatever works whether or not it’s the right way, the supported way, or the secure way. If it worked their way, then why do they have to change it? I realize that there is no way to answer this question for some people that will satisfy them. For this, we apologize and ask for your patience, understanding and trust.
We will always need to keep things secure and up to date and sometimes change is inevitable. If you are one of the unfortunate folks that suddenly had things stop working for you when we migrated you to the new server, believe me when I say that we will try to make the future more smooth for you. The fixes are hopefully quite easy for you.
Go to http://webmail.yourdomain.com (yes, please replace “yourdomain.com” with your actual domain) and log in with your email address and email password. (you’d be surprised at how many people don’t think they have one). Depending on your particular setup, you will either see the “Configure Mail Client” icon or you will have to use the dropdown menu in the upper right to get to that option. There, you will find setup instructions that are tailored specifically to your actual email account. Those are the official ones – the ones that work and the ones we support.
Here’s the important bit – if you see burbank.v3.ca or ventura.v3.ca as the mail server to use for SSL, it IS going to change. If it’s ventura.v3.ca, it’s going to change soon – so be prepared to change it again. But at least you know how to do it, right?
It’s all a day in the life of a sysadmin – except this day is like one of those Mondays and has been going on for a few weeks. There’s light at the end of the tunnel though! I should be finished my humble pie about the same time I get there.